所有的業務系統，都有生成ID的需求，如訂單id，商品id等
這個ID會是數據庫中的唯一主鍵，在它上面會建立聚集索引
ID生成的核心需求：
（1）全局唯一
（2）趨勢有序
1.使用數據庫的 auto_increment 來生成全局唯一遞增ID
優點：
（1）簡單
（2）能夠保證唯一性
（3）能夠保證遞增性
（4）步長固定
缺點：
（1）可用性難以保證：數據庫架構是一主多從+讀寫分離，生成自增ID是寫請求，主庫掛了就玩不轉了
（2）擴展性差，性能有上限：因為寫入是單點，數據庫主庫的寫性能決定ID的生成性能上限，並且難以擴展
改進方法：
（1）增加主庫，避免寫入單點
（2）數據水平切分，保證各主庫生成的ID不重復
改進后保證了可用性，但缺點是：
（1）喪失了ID生成的“絕對遞增性”
（2）數據庫的寫壓力依然很大，每次生成ID都要訪問數據庫
2.單點批量ID生成服務
每次生成ID都訪問了數據庫，使用批量的方式降低數據庫寫壓力
數據庫中只存儲當前ID的最大值，
如果當前為0，
ID生成服務每次批量拉取6個ID，服務訪問數據庫，將當前ID的最大值修改為5，應用訪問ID生成服務索要ID，ID生成服務不需要每次訪問數據庫，就能依次派發0,1,2,3,4,5
當ID發完后，再將ID的最大值修改為11，就能再次派發6,7,8,9,10,11
優點：
（1）保證了ID生成的絕對遞增有序
（2）大大的降低了數據庫的壓力
缺點：
（1）服務仍然是單點
（2）如果服務掛了，服務重啟起來之后，繼續生成ID可能會不連續，中間出現空洞
（3）雖然每秒可以生成幾萬幾十萬個ID，但還是有性能上限，無法進行水平擴展
改進方法：
單點服務高可用優化方案是“備用服務”
對外提供的服務是主服務，備用服務時刻處於備用狀態，當主服務掛了的時候備用服務頂上。
這個切換的過程對調用方是透明的，可以自動完成，常用的技術是vip+keepalived
3.uuid
string ID =GenUUID();
優點：
（1）本地生成ID，不需要進行遠程調用，時延低
（2）擴展性好，基本可以認為沒有性能上限
缺點：
（1）無法保證趨勢遞增
（2）uuid過長，往往用字符串表示，作為主鍵建立索引查詢效率低
優化方案為“轉化為兩個uint64整數存儲”或者“折半存儲”（折半后不能保證唯一性）
4.取當前毫秒數
uint64 ID = GenTimeMS();
優點：
（1）本地生成ID，不需要進行遠程調用，時延低
（2）生成的ID趨勢遞增
（3）生成的ID是整數，建立索引后查詢效率高
缺點：
（1）如果並發量超過1000，會生成重復的ID
5.類snowflake算法
snowflake是twitter開源的分布式ID生成算法
核心思想是：一個long型的ID，使用其中41bit作為毫秒數，10bit作為機器編號，12bit作為毫秒內序列號