惟一ID生成器-發號器實踐-企業實例--內存buffer方式

緩存模式

基於內存buffer的發號器架構如圖，這也是目前我在維護的發號器之一

優勢：
1.水平擴展方便
2.對高併發支持良好
3.數據庫依賴較低，只在buffer耗盡時需請求數據庫，鏈接失敗狀況下仍可實現較長時間發號
4.該服務目前支持step發號返回的id格式符合 id=startID+idStep*n
5.該服務支持一次獲取多號，性能與單個發號相近
缺點：
1.集羣狀況下，發號爲趨勢遞增而非嚴格遞增（趨勢遞增指ID總體上是增長且惟一的，但不是嚴格兩次發號都差1，好比兩臺服務器A持有1001-2000 B持有2001-3000 兩次發號請求分別到了AB兩個機器，獲得1001 和2001）
2.重啓服務後未用完的號段做廢

實現：

服務以worker方式工做，一個serviceID對應一個worker，以服務A爲例

服務A初始化，建立worker ，訪問數據庫根據max_id獲取2個號段填入內存buffer

獲取的號段segment駐留內存，號段數據結構【startID，currentID，MAXID】，以後每次取號只訪存修改currentID，有鎖機制保證線程安全

一個號段用完後利用go信道獲取buffer中的新號段，同時服務會生成並填充新號段入buffer保證buffer中一直保有2個號段（可配置），服務期間除初次啓動，請求發號不依賴數據庫，數據庫鏈接失敗後仍可持續發號較長時間（取決於號段長度step_size及服務請求量）
服務週期內，全部請求只經歷訪存延遲，buffer抹除了數據庫延遲