分布式ID系統(tǒng)設(shè)計第三集
id-service-SnowFlake方案
第二集說了id-service-Segment-DB可以生成趨勢遞增的ID,但是ID號是可以計算的。不太適用于一些訂單ID生成的場景。因為存在數(shù)據(jù)暴露的風(fēng)險
比如我可以對比兩天的訂單ID號來大致計算出公司一天的訂單量。這個有點危險。
所以我們需要id-serviceSnowFlake方案。
id-service-snowFlake完全沿用snowFlake方案的bit位設(shè)計。即"1+41+10+12"的方式組裝id。對于workid的分配 基本上可以用手動配置。也可以借助Zk或者etcd CP實現(xiàn)的分布式協(xié)調(diào)者來配置。id-service-SnowFlake按照下面幾個步驟啟動:
1 啟動id-servicesnowFlake。連接zk或者etcd。在id-service-snowflake父節(jié)點下檢查自己是否已注冊。
2 如果有就直接拿到自己的workId zk/etcd 生成的id 啟動。
3 如果沒有就在根下面生成一個節(jié)點id 當(dāng)作自己的workId
4 start-service
弱依賴zk
如果想做到這一步就在本地osFile上。當(dāng)zk出現(xiàn)問題的時候，而服務(wù)又要重啟。這個時候這一步就能提高SLA.
解決時鐘問題
因為這種方案依賴時間。如果機(jī)器的時鐘發(fā)生了回?fù)?。那么有可能生成重?fù)的ID.那就需要解決這個問題。
1 首先服務(wù)注冊到zk 檢查自己是否寫如果zk
2 如果寫過 則用自己的系統(tǒng)時間與id-service-forever/{id}節(jié)點記錄時間做比較 如果小于則認(rèn)為機(jī)器時間發(fā)生了回?fù)?，這個時候可以選擇等待也可以選擇失敗退出。
3 如未寫過 則直接注冊進(jìn)去。然后對比其他節(jié)點的系統(tǒng)時間判斷自己系統(tǒng)時間是否正確?？梢赃x擇輪訓(xùn)對比 也可以選擇相加/節(jié)點數(shù)對比
4 若時間正確就啟動 寫入zk
5 否則認(rèn)為有回?fù)堋?br> 6 每隔一段時間上報自己的系統(tǒng)時間寫入zk
由于強(qiáng)依賴時鐘，對時鐘要求很敏感。如果機(jī)器上有NTP時間服務(wù)同步的話。在他同步的時候會造成秒級的回?fù)堋?不過一般的公司也不會有這種業(yè)務(wù)量 除了大廠)。解決方案就是在回?fù)艿臅r候等待一段時間(1s 2s 這樣)或者直接重試.再或者直接摘除節(jié)點 告警。
代碼實現(xiàn)也很簡單
/發(fā)生了回?fù)?，此刻時間小于上次發(fā)號時間
if (timestamp < lastTimestamp) {
long offset = lastTimestamp - timestamp;
if (offset <= 5) {
try {
//時間偏差大小小于5ms，則等待兩倍時間
wait(offset << 1);//wait
timestamp = timeGen();
if (timestamp < lastTimestamp) {
//還是小于，拋異常并上報
throwClockBackwardsEx(timestamp);
}
} catch (InterruptedException e) {
throw e;
}
} else {
//throw
throwClockBackwardsEx(timestamp);
}
}
從使用情況來看 基本沒有出現(xiàn)過問題。文章來源：http://www.zghlxwxcb.cn/news/detail-741258.html
id-service 情況
作為一個基架服務(wù)。性能應(yīng)該是最關(guān)心的 能在4C8G機(jī)器上跑出4w QPS.可用性也能保證9999.提供給6個BU 一天有個幾百萬的使用量。作為基架。高SLA和高性能是必須要保證的。文章來源地址http://www.zghlxwxcb.cn/news/detail-741258.html
到了這里，關(guān)于分布式ID系統(tǒng)設(shè)計(3)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
