分布式系统中惟一 ID 的生成方法

1.可使用Redis集群来获取更高的吞吐量。一台吞吐量不够可使用多台，假如一个集群中有5台Redis。

能够初始化每台Redis的值分别是1,2,3,4,5，而后步长都是5。各个Redis生成的ID为：

A：1,6,11,16,21

B：2,7,12,17,22

C：3,8,13,18,23

D：4,9,14,19,24

E：5,10,15,20,25

2.twitter开源的Snowflake 算法，但它强依赖时钟,若是主机时间回拨,则会形成重复ID。

3.类snowflake算法

百度的uid-generator：

https://github.com/baidu/uid-generator

美团Leaf：

https://github.com/zhuzhong/idleaf

基本是对snowflake的进一步优化，好比解决时钟 回拨问题！

 

关于分布式ID的一些思考

https://mp.weixin.qq.com/s/CeQpB3uVhN7qnaTm7KiERw

 

整体而言，分布式惟一ID须要知足如下条件：

• 高可用性：不能有单点故障。

• 全局惟一性：不能出现重复的ID号，既然是惟一标识，这是最基本的要求。

• 趋势递增：在MySQL InnoDB引擎中使用的是汇集索引，因为多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面咱们应该尽可能使用有序的主键保证写入性能。

• 时间有序：以时间为序，或者ID里包含时间。这样一是能够少一个索引，二是冷热数据容易分离。

• 分片支持：能够控制ShardingId。好比某一个用户的文章要放在同一个分片内，这样查询效率高，修改也容易。

• 单调递增：保证下一个ID必定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。

• 长度适中：不要太长，最好64bit。使用long比较好操做，若是是96bit，那就要各类移位至关的不方便，还有可能有些组件不能支持这么大的ID。

• 信息安全：若是ID是连续的，恶意用户的扒取工做就很是容易作了，直接按照顺序下载指定URL便可；若是是订单号就更危险了，竞争对手能够直接知道咱们一天的单量。因此在一些应用场景下，会须要ID无规则、不规则。

http://mp.weixin.qq.com/s/cqIK5Bv1U0mT97C7EOxmnA

 

https://mp.weixin.qq.com/s?__biz=MzA5ODM5MDU3MA==&mid=2650863118&idx=1&sn=fa6dfd64d967a0c402897028052ce524&chksm=8b66114bbc11985d1cd5043222d51a79dd21b8ea06bd287d5aa45fe0467d6fab180f6fc17adc&scene=21#wechat_redirect