snowflake時間回退問題思考

算法比較簡單，每一個id-generator負責生成的ID由3部分組成，41位時間戳能夠表示到毫秒，10bit worker-id內部可自行劃分，好比3位表示IDC，7位表示機器。最後12位是在一毫秒的遞增id，也就是每毫秒算法能夠產生2^12 = 4096個id，QPS 400多萬；

snowflake保證1）產生的id分佈式系統內全局惟一，2）id趨勢遞增；不是嚴格遞增，由於集羣的機器時間不一樣步問題

 

該算法存在一個最嚴重的問題，是時間回退。好比一臺機器A，在t產生一個id，但時鐘被調回了t-15，則再次生成的id存在重複的可能。

思考了一個解決這個問題的方法，

在單一id-generator服務上，每ms生成id時，檢測current_ms，或<= last_ms則等待last_ms-current_ms後，再開始正常服務。這樣若id-generator重啓後依然有問題，由於沒有地方記錄last_ms。而且由於400w的高qps，也沒法將其持久化。

咱們引入一個第3方，如zookeeper或redis，id-generator服務啓動時atomic increase一個key，並將結果用做worker-id。。。

 

 

oops！貌似不行，只支持重啓1024次