前言
在網際網路的業務系統中，涉及到各種各樣的id，如在支付系統中就會有支付id、退款id等。
那一般生成id都有哪些解決方案呢？特別是在複雜的分布式系統業務場景中，我們應該採用哪種適合自己的解決方案是十分重要的。下面我們一一來列舉一下，不一定全部適合，這些解決方案僅供你參考，或許對你有用。
使用資料庫的id自增策略，如 mysql 的 auto_increment。並且可以使用兩台資料庫分別設定不同步長，生成不重複id的策略來實現高可用。
優點：
（1）簡單，使用資料庫已有的功能
（2）能夠保證唯一性
（3）資料庫生成的id能夠保證遞增性
（4）步長固定
缺點：
（1）可用性難以保證：資料庫常見架構是一主多從+讀寫分離，生成自增id是寫請求，主庫掛了就玩不轉了
（2）擴充套件性差，效能有上限：因為寫入是單點，資料庫主庫的寫效能決定id的生成效能上限，並且難以擴充套件
改進方法：
（1）增加主庫，避免寫入單點
（2）資料水平切分，保證各主庫生成的id不重複
如上圖所述，由1個寫庫變成3個寫庫，每個寫庫設定不同的auto_increment初始值，以及相同的增長步長，以保證每個資料庫生成的id是不同的（上圖中庫0生成0,3,6,9…，庫1生成1,4,7,10，庫2生成2,5,8,11…）
改進後的架構保證了可用性，但缺點是：
（1）喪失了id生成的「絕對遞增性」：先訪問庫0生成0,3，再訪問庫1生成1，可能導致在非常短的時間內，id生成不是絕對遞增的（這個問題不大，我們的目標是趨勢遞增，不是絕對遞增）
（2）資料庫的寫壓力依然很大，每次生成id都要訪問資料庫
為了解決上述兩個問題，引出了下面的常見的方案
一次按需批量生成多個id，每次生成都需要訪問資料庫，將資料庫修改為最大的id值，並在記憶體中記錄當前值及最大值。
分布式系統之所以難，很重要的原因之一是「沒有乙個全域性時鐘，難以保證絕對的時序」，要想保證絕對的時序，還是只能使用單點服務，用本地時鐘保證「絕對時序」。資料庫寫壓力大，是因為每次生成id都訪問了資料庫，可以使用批量的方式降低資料庫寫壓力。
如上圖所述，資料庫使用雙master保證可用性，資料庫中只儲存當前id的最大值，例如0。id生成服務假設每次批量拉取6個id，服務訪問資料庫，將當前id的最大值修改為5，這樣應用訪問id生成服務索要id，id生成服務不需要每次訪問資料庫，就能依次派發0,1,2,3,4,5這些id了，當id發完後，再將id的最大值修改為11，就能再次派發6,7,8,9,10,11這些id了，於是資料庫的壓力就降低到原來的1/6了。
優點：
（1）保證了id生成的絕對遞增有序
（2）大大的降低了資料庫的壓力，id生成可以做到每秒生成幾萬幾十萬個
缺點：
（1）服務仍然是單點
（2）如果服務掛了，服務重啟起來之後，繼續生成id可能會不連續，中間出現空洞（服務記憶體是儲存著0,1,2,3,4,5，資料庫中max-id是5，分配到3時，服務重啟了，下次會從6開始分配，4和5就成了空洞，不過這個問題也不大）
（3）雖然每秒可以生成幾萬幾十萬個id，但畢竟還是有效能上限，無法進行水平擴充套件
改進方法：
單點服務的常用高可用優化方案是「備用服務」，也叫「影子服務」，所以我們能用以下方法優化上述缺點（1）：
如上圖，對外提供的服務是主服務，有乙個影子服務時刻處於備用狀態，當主服務掛了的時候影子服務頂上。這個切換的過程對呼叫方是透明的，可以自動完成，常用的技術是vip+keepalived，具體就不在這裡展開。
演算法的核心思想是結合機器的網絡卡、當地時間、乙個隨記數來生成uuid。
優點：
（1）本地生成id，不需要進行遠端呼叫，時延低，沒有高可用風險
（2）擴充套件性好，基本可以認為沒有效能上限
缺點：
（1）無法保證趨勢遞增
（2）uuid過長，往往用字串表示，作為主鍵建立索引查詢效率低，常見優化方案為「轉化為兩個uint64整數儲存」或者「折半儲存」（折半後不能保證唯一性）
4.取當前毫秒數
uuid是乙個本地演算法，生成效能高，但無法保證趨勢遞增，且作為字串id檢索效率低，有沒有一種能保證遞增的本地演算法呢？
取當前毫秒數是一種常見方案：uint64 id = gentimems();
優點：
（1）本地生成id，不需要進行遠端呼叫，時延低
（2）生成的id趨勢遞增
（3）生成的id是整數，建立索引後查詢效率高
缺點：
（1）如果併發量超過1000，會生成重複的id
我去，這個缺點要了命了，不能保證id的唯一性。當然，使用微秒可以降低衝突概率，但每秒最多只能生成1000000個id，再多的話就一定會衝突了，所以使用微秒並不從根本上解決問題。
redis的所有命令操作都是單執行緒的，本身提供像 incr 和 increby 這樣的自增原子命令，所以能保證生成的 id 肯定是唯一有序的。
考慮到單節點的效能瓶頸，可以使用 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
複製**
另外，比較適合使用 redis 來生成每天從0開始的流水號。比如訂單號 = 日期 + 當日自增長號。可以每天在 redis 中生成乙個 key ，使用 incr 進行累加。
6.類snowflake演算法
snowflake是twitter開源的分布式id生成演算法，其核心思想是：乙個long型的id，使用其中41bit作為毫秒數，10bit作為機器編號，12bit作為毫秒內序列號。這個演算法單機每秒內理論上最多可以生成1000*(2^12)，也就是400w的id，完全能滿足業務的需求。
借鑑snowflake的思想，結合各公司的業務邏輯和併發量，可以實現自己的分布式id生成演算法。
舉例，假設某公司id生成器服務的需求如下：
（1）單機高峰併發量小於1w，預計未來5年單機高峰併發量小於10w
（2）有2個機房，預計未來5年機房數量小於4個
（3）每個機房機器數小於100臺
（4）目前有5個業務線有id生成需求，預計未來業務線數量小於10個
（5）…
分析過程如下：
（1）高位取從2023年1月1日到現在的毫秒數（假設系統id生成器服務在這個時間之後上線），假設系統至少執行10年，那至少需要10年*365天*24小時*3600秒*1000毫秒=320*10^9，差不多預留39bit給毫秒數
（2）每秒的單機高峰併發量小於10w，即平均每毫秒的單機高峰併發量小於100，差不多預留7bit給每毫秒內序列號
（3）5年內機房數小於4個，預留2bit給機房標識
（4）每個機房小於100臺機器，預留7bit給每個機房內的伺服器標識
（5）業務線小於10個，預留4bit給業務線標識
這樣設計的64bit標識，可以保證：
（1）每個業務線、每個機房、每個機器生成的id都是不同的
（2）同乙個機器，每個毫秒內生成的id都是不同的
（3）同乙個機器，同乙個毫秒內，以序列號區區分保證生成的id是不同的
（4）將毫秒數放在最高位，保證生成的id是趨勢遞增的
缺點：
（1）由於「沒有乙個全域性時鐘」，每台伺服器分配的id是絕對遞增的，但從全域性看，生成的id只是趨勢遞增的（有些伺服器的時間早，有些伺服器的時間晚）
最後乙個容易忽略的問題：
生成的id，例如message-id/ order-id/ tiezi-id，在資料量大時往往需要分庫分表，這些id經常作為取模分庫分表的依據，為了分庫分表後資料均勻，id生成往往有「取模隨機性」的需求，所以我們通常把每秒內的序列號放在id的最末位，保證生成的id是隨機的。
又如果，我們在跨毫秒時，序列號總是歸0，會使得序列號為0的id比較多，導致生成的id取模後不均勻。解決方法是，序列號不是每次都歸0，而是歸乙個0到9的隨機數，這個地方。
refer：
分布式唯一id的幾種生成方案
細聊分布式id生成方法
分布式全域性ID生成方案
1 背景 分布式架構下，唯一序列號生成是我們在設計乙個系統，尤其是資料庫使用分庫分表的時候常常會遇見的問題。當分成若干sharding表後，如何能夠快速拿到乙個唯一序列號，是經常遇到的問題。在網際網路的業務系統中，涉及到各種各樣的id，如在支付系統中就會有支付id 退款id等。那一般生成id都有哪些...
分布式ID生成方案
系統唯一id是設計乙個系統的時候常常會遇到的問題，也常常為這個問題而糾結。生成id的方法有很多，適應不同的場景 需求以及效能要求。所以有些比較複雜的系統會有多個id生成的策略。1 全域性唯一性 不能出現重複的id號，既然是唯一標識，這是最基本的要求 2 粗略有序 如果在分布式環境中做到完全有序，需要...
分布式唯一ID的生成方案
不能出現重複的id，這是最基本的要求。有利於關聯式資料庫索引效能。既然是服務於分布式系統，為多個服務提供id服務，訪問壓力一定很大，所以需要保證高可用。如果id是有規律的，就容易被惡意操作，在一些場景下需要id無規則。核心思想是結合機器的網絡卡 當地時間 乙個隨機數來生成。優點 缺點 利用資料庫自增...