分布式高可用 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 。