分佈式系統中惟一 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