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

2019独角兽企业重金招聘Python工程师标准>>>

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

转载于:https://my.oschina.net/u/3705388/blog/1555781