服務(wù)端/后臺開發(fā)中如何生成id是每個開發(fā)者都會遇到的問題，在電商、游戲領(lǐng)域尤其突出。
如何保證生成id的唯一性、可靠性、高可用性，如何組織id的格式，在不同的應(yīng)用場景和限制下實(shí)現(xiàn)方式也不盡相同。
我們的應(yīng)用場景類似電商，在一個訂單的生命周期內(nèi)，有多個邏輯需要生成各自的id，還要考慮到可讀性和靈活性，我們決定實(shí)現(xiàn)一個獨(dú)立的id服務(wù)。
首先，id服務(wù)必須具有高可用性，業(yè)務(wù)邏輯處理中創(chuàng)建id失敗是不可接受的，所以id服務(wù)必須分布式部署，有多個節(jié)點(diǎn)同時對外服務(wù)，一個節(jié)點(diǎn)失敗則重試其他節(jié)點(diǎn)，保證成功創(chuàng)建id。
在分布式系統(tǒng)中保證數(shù)據(jù)的一致性成本是很高的，為了簡化設(shè)計和實(shí)現(xiàn)，每個節(jié)點(diǎn)都設(shè)計成對等的、獨(dú)立的，不需要保持?jǐn)?shù)據(jù)同步。
其次，id服務(wù)必須可靠，數(shù)據(jù)不能丟失，因此數(shù)據(jù)的存儲放在獨(dú)立的mysql數(shù)據(jù)庫中，使用replace方式更新數(shù)據(jù)，id服務(wù)本身記錄更新日志。
最后，id服務(wù)必須靈活，可以自定義id格式，可以高效靈活的實(shí)現(xiàn)客戶端，因此通訊協(xié)議使用json over udp方式，在id服務(wù)端使用lua實(shí)現(xiàn)id格式的靈活定義。
ID規(guī)則
具體規(guī)則有l(wèi)ua腳本定義，修改腳本后需要reload生效，需要實(shí)現(xiàn)4個函數(shù)
min_counter : 計數(shù)器最小值
max_counter : 計數(shù)器最大值
reset_seconds : 計數(shù)器重置周期
create_id : 根據(jù)計數(shù)器、自定義參數(shù)和時間參數(shù)創(chuàng)建ID。
例如：
function min_counter()
return 0
end
function max_counter()
return 9999
end
function reset_seconds()
return 86400
end
function create_id(counter,now,salt)
local seq = counter:generate_counter()
local new_id = string.format("%01d%02d%02d%04d",now:year()%10 ,now:month(),now:day(),seq)
return new_id
end
接口
采用udp協(xié)議，數(shù)據(jù)格式為json ，字段定義：
action: 請求類型 get： 創(chuàng)建ID ， monitor：監(jiān)控
rule_name: 規(guī)則名字， 由服務(wù)端定義
app_name : 應(yīng)用名或命名空間 ， 客戶端自定義，rule_name和app_name一起決定生成ID的唯一性
salt : 自定義參數(shù) ，可選項(xiàng) ，
seq : 自定義參數(shù)，可選項(xiàng)，原樣返回
例如:
創(chuàng)建ID請求: {"action":"get","rule_name":"o2o","app_name":"test"}
響應(yīng)：{"code":0,"message":"success","data":"505140001"}
監(jiān)控請求：{"action":"monitor","rule_name":"o2o","app_name":"test"}
響應(yīng)：{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}
性能
id服務(wù)器使用c++實(shí)現(xiàn)，性能測試做的比較簡單，因?yàn)樾阅懿皇莍d服務(wù)的主要關(guān)注點(diǎn)， 簡單以php為客戶端進(jìn)行測試。
4個php并發(fā)進(jìn)程，每個進(jìn)程不停發(fā)送20萬個請求，測試結(jié)果：
total:200000 fail:0 min:0.000214 max:0.087330 avg:0.000393
total:200000 fail:0 min:0.000215 max:0.087129 avg:0.000391
total:200000 fail:0 min:0.000221 max:0.087252 avg:0.000391
total:200000 fail:0 min:0.000218 max:0.087484 avg:0.000391
說明 min : 最小耗時(秒) max : 最大耗時(秒) avg : 平均耗時(秒)
服務(wù)器TPS達(dá)到近1萬/秒時，平均延遲在0.3毫秒。
經(jīng)過在生產(chǎn)環(huán)境使用，運(yùn)行穩(wěn)定，現(xiàn)在將整個系統(tǒng)開源出來，歡迎試用，有任何意見和建議歡迎反饋到lxyfirst＠163.com 。
項(xiàng)目源代碼位置 : https://github.com/lxyfirst/id_server
版本更新9.19
1.增加數(shù)據(jù)落地的預(yù)保存和批量保存機(jī)制，一方面減少數(shù)據(jù)庫壓力，一方面增加異步保存的可靠性。
2.由于主線程和數(shù)據(jù)庫線程只需要傳遞sql語句，將線程間通信由pipe方式改為eventfd + lockfree queue方式。