分布式系统中生成全局唯一ID的3个思路

分布式系统中生成全局唯一ID的3个思路

      本文根据http://chuansong.me/n/950274251672总结而来!

1.  基于数据库的生成
     

标识的生成方法有很多，有集中式的，分布式的；有后端的，前端的，当然还有人工的。 并没有一种通用的生成方法来适应各种应用场景。

人工生成的确是一种方式，比如电子邮箱，微信ID，各种论坛的账号。在人想出标识的那一刻，是无法判断是否是唯一的，对这种生成方式的结果，显然在录入时都需要进行唯一性校验。所以，下面描述的几种生成方式，是在生成的那一刻就在一个命名空间内唯一，而不再需要进行唯一性校验。

而基于数据库生成，一般包含以下几种：

MySQL(5.6) AUTO_INCREMENT 特性

Postgres(REL 9.6 Stable) SEQUENCE 特性

Oracle 数据库的 SEQUENCE 特性，有知道这一特性如何实现的，可以在 知乎 做一下解答。

Flickr Ticket Servers ，同时支持Sharding (文章发表于2010年2月8日，算法上线于2006年1月13日)。

一般地，这种类型的生成方案，都可以设置其实初始值，以及增量步长。

2.  基于分布式集群协调器生成
      

在不使用数据库的情况下，通过一个后台服务对外提供高可用的、固定步长标识生成，则需要分布式的集群协调器进行。

一般的，主流协调器有两类：

以强一致性为目标的：ZooKeeper为代表

以最终一致性为目标的：Consul为代表

ZooKeeper的强一致性，是由Paxos协议保证的；Consul的最终一致性，是由Gossip协议保证的。

在步长累计型生成算法中，最核心的就是保持一个累计值在整个集群中的「强一致性」。同时，这也会为唯一性标识的生成带来新的形成瓶颈。

3.  划分命名空间并行生成

     似乎对于分布式的ID生成，以Twitter Snowflake为代表的， Flake 系列算法，经常可以被搜索引擎找到，但似乎MongoDB的ObjectId算法，更早地采用了这种思路。MongoDB 1.0 是在2009年8月27日 发布 的，并且0.9.10(2009年8月24日发布)和1.0两个版本没有差异。

      这个很多系统中的实现可以参考。