在分布式高併發的情況下，分布式主鍵生成策略可參考mongodb的objectid實現。
objectid是一種輕量的，不同的機器不同的程序都能用全域性唯一的同種方法生成它，而不是採用傳統的自增的主鍵策略，因為在多台伺服器上同步自動增加主鍵既費力又費時。objectid
是乙個24位的字串，
它是由一組十六進製制的字元構成，每個位元組兩位的十六進製制數字，總共用了12位元組的儲存空間。mongodb的這種設計，體現著空間換時間的思想。官網中對objectid的規範，如圖所示。
圖官網對objectid的規範
1) time
時間戳。將剛才生成的objectid的前4位進行提取「4e7020cb」，然後按照十六進製制轉為十進位制，變為「1315971275」，這個數字就是乙個時間戳。通過時間戳的轉換，就成了易看清的時間格式，如圖3所示。
2) machine
機器。接下來的三個位元組就是「7cac81」，這三個位元組是所在主機的唯一識別符號，一般是機器主機名的雜湊值，這樣就確保了不同主機生成不同的機器hash值，確保在分布式中不造成衝突，這也就是在同一臺機器生成的objectid中間的字串都是一模一樣的原因。
3) pid
程序id。上面的machine是為了確保在不同機器產生的objectid不衝突，而pid就是為了在同一臺機器不同的mongodb程序產生了objectid不衝突，接下來的「af71」兩位就是產生objectid的程序識別符號。
4) inc
自增計數器。前面的九個位元組是保證了一秒內不同機器不同程序生成objectid不衝突，這後面的三個位元組「36236b」是乙個自動增加的計數器，用來確保在同一秒內產生的objectid也不會發現衝突，允許256的3次方等於16777216條記錄的唯一性。
總的來看，objectid的前4個位元組時間戳，記錄了文件建立的時間；接下來3個位元組代表了所在主機的唯一識別符號，確定了不同主機間產生不同的objectid；後2個位元組的程序id，決定了在同一臺機器下，不同mongodb程序產生不同的objectid；最後通過3個位元組的自增計數器，確保同一秒內產生objectid的唯一性。objectid的這個主鍵生成策略，很好地解決了在分布式環境下高併發情況主鍵唯一性問題，值得學習借鑑。
參考：
分布式主鍵生成策略
參考鏈結 自增主鍵和uuid 自增長uuid 優點 很小的資料儲存空間 效能最好 容易記憶 獨一無二的，出現重複的機會少 跨伺服器資料合併非常方便 安全性高 缺點 如果存在大量的資料，可能會超出自增長的範圍 很難處理分布式儲存的資料表，尤其是在合併表的情況下 安全性低，有規律，容易被非法獲得資料 儲...
基於redis分布式主鍵生成
idgenerator idgenerator idgenerator.builder addhost 127.0.0.1 6379,fce3758b2e0af6cbf8fea4d42b379cd0dc374418 addhost 127.0.0.1 7379,1abc55928f37176cb93...
分布式系統全域性id生成策略
1 不能有單點故障 2 全域性id生成服務不能成為整個系統效能瓶頸 3 全域性id要和shardingid有對映關係，根據全域性主鍵id能算出資料在哪個分片 4 不能太長，否則，作為主鍵建立索引查詢效率低 flickr開發團隊在2010年撰文介紹了flickr使用的一種主鍵生成策略，flickr這一...