服務端/后臺開發中如何生成id是每個開發者都會遇到的問題，在電商、游戲領域尤其突出。
如何保證生成id的唯一性、可靠性、高可用性，如何組織id的格式，在不同的應用場景和限制下實現方式也不盡相同。
我們的應用場景類似電商，在一個訂單的生命周期內，有多個邏輯需要生成各自的id，還要考慮到可讀性和靈活性，我們決定實現一個獨立的id服務。
首先，id服務必須具有高可用性，業務邏輯處理中創建id失敗是不可接受的，所以id服務必須分布式部署，有多個節點同時對外服務，一個節點失敗則重試其他節點，保證成功創建id。
在分布式系統中保證數據的一致性成本是很高的，為了簡化設計和實現，每個節點都設計成對等的、獨立的，不需要保持數據同步。
其次，id服務必須可靠，數據不能丟失，因此數據的存儲放在獨立的mysql數據庫中，使用replace方式更新數據，id服務本身記錄更新日志。
最后，id服務必須靈活，可以自定義id格式，可以高效靈活的實現客戶端，因此通訊協議使用json over udp方式，在id服務端使用lua實現id格式的靈活定義。
ID規則
具體規則有lua腳本定義，修改腳本后需要reload生效，需要實現4個函數
min_counter : 計數器最小值
max_counter : 計數器最大值
reset_seconds : 計數器重置周期
create_id : 根據計數器、自定義參數和時間參數創建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協議，數據格式為json ，字段定義：
action: 請求類型 get： 創建ID ， monitor：監控
rule_name: 規則名字， 由服務端定義
app_name : 應用名或命名空間 ， 客戶端自定義，rule_name和app_name一起決定生成ID的唯一性
salt : 自定義參數 ，可選項 ，
seq : 自定義參數，可選項，原樣返回
例如:
創建ID請求: {"action":"get","rule_name":"o2o","app_name":"test"}
響應：{"code":0,"message":"success","data":"505140001"}
監控請求：{"action":"monitor","rule_name":"o2o","app_name":"test"}
響應：{"code":0,"message":"ok","data":{"counter":3,"node_offset":1}}
性能
id服務器使用c++實現，性能測試做的比較簡單，因為性能不是id服務的主要關注點， 簡單以php為客戶端進行測試。
4個php并發進程，每個進程不停發送20萬個請求，測試結果：
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 : 平均耗時(秒)
服務器TPS達到近1萬/秒時，平均延遲在0.3毫秒。
經過在生產環境使用，運行穩定，現在將整個系統開源出來，歡迎試用，有任何意見和建議歡迎反饋到lxyfirst＠163.com 。
項目源代碼位置 : https://github.com/lxyfirst/id_server
版本更新9.19
1.增加數據落地的預保存和批量保存機制，一方面減少數據庫壓力，一方面增加異步保存的可靠性。
2.由于主線程和數據庫線程只需要傳遞sql語句，將線程間通信由pipe方式改為eventfd + lockfree queue方式。