在一次公開課上，聽別人講過全域性分散式uuid的設計，聽過twitter的snowflake的設計。也聽過，如果使用單獨的計數器服務，不可能每次都儲存當前計數器到文字，自己想到應該可以每隔一些數，例如1萬次，10萬次，反正64位的空間比較大，然後儲存起來，那麼就沒有每次儲存，對硬碟的寫入壓力。當出現故障的時候，跳過這麼多數就可以了。只是，這個據說也是微信的uuid設計方案。我如果拿這個來講，豈不是抄襲很嚴重。下面先給出uuid服務的圖：

對於snowflake和微信的計數儲存方案，各個各的優點，在我看來，可以考慮聯合這兩種方案。方案大致如下：

1. 對於不同的uuid server，給予不同的字首，那麼不同的uuid伺服器的計數互不干擾，這個依賴於運維來實現，當然，如果開發打算自己做，我覺得也沒有問題。

2. 對於每個uuid伺服器，啟動的時候，從當前電腦獲取出當前的時間，在這裡，可以考慮從epoch開始的秒數，然後有一個次數計數器，從0開始計數，假設這個計數器為32位，每次來一個請求，次數計數器+1，可以考慮當這個計數器達到最大值時，檢查一下當前秒數，是不是和上一次獲取秒數不同，如果相同（對於當前例子來說，基本不可能），則休眠若干毫秒，然後再次獲取當前時間，如果不同，則將次數計數器重新置為0，繼續進行計數。你們應該不難看出，我這裡的計數器是

uuid server 的字首 + 當前秒數 + 次數計數器值

3. 對於程式崩潰的處理，並不困難，只需要在程式啟動的地方新增一個sleep（休眠），讓程式1s後啟動就可以了，那麼就可以保證新的計數器，之前不會出現過。

4. 引數說明：上面所說的引數，可能不是最優的，例如，可以考慮，將時間改為從epoch開始的毫秒數，0.1s，或者其他的，這個看各自的需求，計數器，也可以考慮使用30個bit，24個bit，那麼對應的最大值也需要根據這個進行調整，可能使總的計數器位數更少，或者更多。總之，這些東西有賴於各自測試，達到自己的目的就好。調整時間的精度，例如精度調整為0.1s，那麼程式再次啟動，sleep的時間可以更短，這個對某些專案可能有所幫助。

5. 需要處理的問題，這裡主要是時間。有一點需要說明，這種實現方式，不同電腦儲存的uuid之間沒有嚴格的時間關係，沒辦法比較先後，同一臺電腦的uuid可以區分先後。對於同一臺電腦，重啟之後執行正常，依賴於本地時間沒有被改動，如果本地時間向前調整，那麼可能會出現uuid重複的問題，先後順序也不能被保證。只是，如果次數計數器值空間很大，那麼出現重複的機率應該不大。如果打算將當前的字首給另外一臺電腦使用，那麼需要那臺電腦的時間不低於當前電腦，否則也可能出現重複。只是，如果那臺電腦的時間在這臺電腦時間之後，應該沒有問題。

6. 如果擔心時間問題，可以在程式中改變時間的時候，進行一次列印，打印出當前的時間，再次啟動的時候可以進行檢視。

7. 順序的額外說明：不同電腦的時間同步對uuid跨電腦排序用處不大，因為uuid中的時間，只能說明記錄的uuid發生在這個時間或者之後，並不一定是這個時間。

8. 對於計數器的實現來說，可以考慮使用atomic，也可以考慮使用中介軟體一類的，看實現方便，以及各自喜好。

關於這個問題，就簡單說到這裡，如果文中有什麼問題，希望能夠指出來。