數(shù)據(jù)庫方式實現(xiàn)方案？有什么缺陷？

　　MySQL為例

　　我們將分布式系統(tǒng)中數(shù)據(jù)庫的同一個業(yè)務表的自增ID設計成不一樣的起始值，然后設置固定的步長，步長的值即為分庫的數(shù)量或分表的數(shù)量。

　　以MySQL舉例，利用給字段設置auto_increment_increment和auto_increment_offset來保證ID自增。

　　auto_increment_offset：表示自增長字段從那個數(shù)開始，他的取值范圍是1 .. 65535。

　　auto_increment_increment：表示自增長字段每次遞增的量，其默認值是1，取值范圍是1 .. 65535。

　　缺點也很明顯，首先它強依賴DB，當DB異常時整個系統(tǒng)不可用。雖然配置主從復制可以盡可能的增加可用性，但是數(shù)據(jù)一致性在特殊情況下難以保證。主從切換時的不一致可能會導致重復發(fā)號。還有就是ID發(fā)號性能瓶頸限制在單臺MySQL的讀寫性能。

　　使用redis實現(xiàn)

　　Redis實現(xiàn)分布式唯一ID主要是通過提供像 INCR 和 INCRBY 這樣的自增原子命令，由于Redis自身的單線程的特點所以能保證生成的 ID 肯定是唯一有序的。

　　但是單機存在性能瓶頸，無法滿足高并發(fā)的業(yè)務需求，所以可以采用集群的方式來實現(xiàn)。集群的方式又會涉及到和數(shù)據(jù)庫集群同樣的問題，所以也需要設置分段和步長來實現(xiàn)。

　　為了避免長期自增后數(shù)字過大可以通過與當前時間戳組合起來使用，另外為了保證并發(fā)和業(yè)務多線程的問題可以采用 Redis + Lua的方式進行編碼，保證安全。

　　Redis 實現(xiàn)分布式全局唯一ID，它的性能比較高，生成的數(shù)據(jù)是有序的，對排序業(yè)務有利，但是同樣它依賴于redis，需要系統(tǒng)引進redis組件，增加了系統(tǒng)的配置復雜性。

　　當然現(xiàn)在Redis的使用性很普遍，所以如果其他業(yè)務已經(jīng)引進了Redis集群，則可以資源利用考慮使用Redis來實現(xiàn)。