以前的訂單服務和代付服務都是自己生成訂單id，這樣是很不好的。先不說設計的耦和，乙個很大的問題是多機器多程序部署的時候造成訂單號重複，那麼就必須重試，造成訂單服務流程的混亂。如果需要其他格式或者長度的單號又得在**中重新生成一次，很不利於後期維護。於是就由我來做乙個專門生成唯一id的服務。
可以多機器多程序部署
這樣可以保證通過多程序和擴充套件機器的方式來提高qps。可以通過ha或者lvs來對外提供唯一的ip和埠，方便訪問。
保證不產生重複id
這個是最基本的要求。因為是基於時間加隨機數的方式生成的id，在多程序和多機器部署的情況下就必須加入其它的資料來保證唯一性。我想到兩種辦法：
通過加入網絡卡號來區分機器，加入程序號來區分程序。不過這種方式雖然可以滿足這個要求，但是會讓訂單號變得特別長。
為每個程序配置乙個work_id，在訂單號中加入這個work_id，就可以區分不同的機器和程序產生的id了。
效能上要求：單程序1000qps
因為訂單服務可以做到1000tps，這樣可以保證即使單程序也可以滿足需求。
80020170628180306247
94834688
0501
固定的頭部
年月日時分秒毫秒
隨機數表標識
庫標識庫標識和表標識
因為我們的資料庫是多庫多表的，所以需要乙個標記一下，方便後期通過訂單號查詢資料。
隨機數的生成 隨機數的生成採用snowflake演算法，下面是我寫的詳細注釋。
//注意：bit、byte和數字的移動位數的不一樣的
uint64_t get_unique_id()
//在乙個毫秒內
if (nowtime ==g_info.last_stamp)
} else
g_info.last_stamp =nowtime;
//或操作後uniqueid的低12位變成seqid，其他位不變。
uniqueid |=g_info.seqid;
return
uniqueid;
}
返回的這個uint_64型別的uniqueid的資料如下
42bit
10bit
12bit
當前時間的毫秒數，多餘的高位資料被截斷
work_id
每一毫秒都從一開始遞增
那麼我們可以計算出該演算法單程序每秒產生的隨機數最大個數是：1000*4095=409.5萬。
我只取後9位也就是乙個int型別的長度（大約），完全滿足一毫秒內不重複的要求。
當然限於cpu和網路頻寬，極限效能是不可能達到的。本地單程序測試可以達到2000qps，完全滿足設計要求。
分布式ID生成服務
在幾乎所有的分布式系統或者採用了分庫 分表設計的系統中,幾乎都會需要生成資料的唯一標識id的需求,常規做法,是使用資料庫中的自動增長列來做系統主鍵,但是這樣的做法無法保證id全域性唯一.那麼乙個分布式id生成器應該滿足那些需求呢 本文將基於snowflake的演算法來進行以下的討論,當然,分布式id...
分布式id生成系統 總結
簡單易用,但是做資料庫分片的時候,uuid不太適合作為分片鍵 詳見leaf 美團點評分布式id生成系統 效能非常高,缺點是如果時間回撥或者各個例項節點時間不一致,容易出錯 詳見leaf 美團點評分布式id生成系統 支援多種不同模式的生成策略 號段模式 該模式需要建db表,需要有專門的服務來提供獲取i...
分布式id生成系統 總結
簡單易用,但是做資料庫分片的時候,uuid不太適合作為分片鍵 效能非常高,缺點是如果時間回撥或者各個例項節點時間不一致,容易出錯 支援多種不同模式的生成策略 號段模式該模式需要建db表,需要有專門的服務來提供獲取id的介面,存在網路延遲 snowflake模式 為了追求更高的效能，需要通過rpc s...