前言
最近想自己嘗試從頭做一個短域名系統，短域名系統中比較關鍵一環的技術就是一個較長的網址會有一到多個唯一ID去標識，最終達到短域名的效果。
如果是以實際情況來說，流量不大的話這個很容易實現效果，無論是數據庫的自增ID還是利用Redis這種單機的發號，都可以解決問題。但是如果自己玩還這樣做的話，那就很沒意思了，所以，我會意淫一個較大的流量場景，然后不斷調整方案解決思路直到達到滿足假設流量場景的要求為止(意味著解決思路如果被打臉后還會回來更新這篇博客，hhhhhhhh)。
常見的ID生成
一般來說，數據庫的自增ID是我們最常用的，又或者是使用Redis的incr去自增得到一個遞增的唯一序號。在一般情況下這都是夠用的。但如果有一天，訪問的量級超出了單機的承受范圍，我們需要擴容時，這些單機的自增ID基本上是沒辦法很好的水平擴容。
針對這種情況，在之前在美團技術團隊分享的一篇文章中看到過一種方式，Redis同樣也可以應用該思路，比如分布式下的MySQL自增ID，通過調整每臺MySQL的增長步長來解決，其中增長步長和MySQL的機器數量相等，比如有兩臺MySQL機器，那么設置第一臺MySQL的初始值為1，接下來的自增結果是:1，3，5，7，9...，第二臺MySQL機器的初始值設置為2，接下來的自增結果是:2，4，6，8，10...。
這樣雖然能很好的解決多臺MySQL的ID自增問題，但是水平擴容卻很麻煩，當你往里面新增一臺機器的時候，新機器的初始值設置會變得很困難，需要很多額外的處理。比如最開始只有一臺機器，按照上面的邏輯來說，會得到:1，2，3，4，5...這樣往后的遞增。但當新添一個機器時，機器總數變了，步長也會改變，所以如果沒有任何處理直接添加第二臺機器，就會得到:2，4，6，8，10...往后的遞增，是不是發現其中序號4在沒加機器前已經生成過了，這樣會導很多致重復。
我的思路
我的這個思路不一定正確，只是我自己思考的一個嘗試，所以，如果解決思路有問題請用力打我的臉。
一個理想的ID生成服務，每個服務都是無狀態，互相沒有依賴和通信，并且每個節點都可以生成全局唯一的ID，這樣一來擴容起來就只需要考慮堆機器，而不用考慮任何其它因素。
而對于全局唯一的ID生成，則可以考慮snowflake的方案，該方案利用系統時間去遞增ID，不依賴任何存儲系統，該ID的結構如下:
這個唯一ID的構成不依賴其它任何系統如MySQL、Redis等，只依賴系統的時間，可以說天然無狀態。除了ID是順序遞增外(對有些業務來說，順序遞增的ID不太友好)，對于我想要構建的無狀態ID生成服務，是很好的選擇。
但是如果依賴時間去構造ID，就還需要解決一個問題，就是系統時間的回退。比如在系統NTP同步時間的時候，系統時間就可能會出現短暫的回退，這對于依賴系統時間生成ID的服務來說，就意味著生成的ID可能會重復，這是不能接受的。
而對于時間回退的解決方式，網上的解決方案非常多，但是實現起來都比較復雜，所以我選擇改動一下snowflake的結構，換種方式解決一下，我的結構如下:
其中，時間戳部分改為由程序自己在內存中維護的自增值，并且最后10bit留給機器作為編號來確保ID的唯一。而如何確保這部分自增序號不回退，就可以沿用一下微信團隊分享的一個簡單的處理思路。
如果我們能夠接受序號不是連續遞增的，回退這個問題就很好解決，比如現在生成的ID是1、2、3，可能后面就會變成4、10、11、12這樣。而具體實現的邏輯則是，內存中維護一個自增序號和一個自增序號的上限(max seq)，獲取自增序號時先檢查當前序號+1是否>=自增序號上限，如果>=自增序號上限，則將這個自增序號上限擴大:自增序號上限(max seq)+=擴大步長(step)，然后持久化這個值到磁盤文件中，下次重新啟動時則從該文件中獲取到該自增序號上限并同時賦值給當前程序維護的自增序號。
最后也順便分享一個我的原型實現:
ZhiyangLeeCN/SeqSrv
