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，也可以考慮使用中介軟體一類的，看實現方便，以及各自喜好。
9. 如果次數計數器為64位,或者類似的長度,可以考慮不進行檢查,只在每次重啟的時候,sleep例如1s,然後從0開始計數,因為按照當前甚至未來一段時間,64位的數字也很難在比較短的時間內耗盡,這樣可以使處理邏輯更加簡單,不過,可能會增加總的計數器的位數.
關於這個問題，就簡單說到這裡，如果文中有什麼問題，希望能夠指出來。
分布式鎖的一點看法
基於zookeeper zookeepr的鎖其實和資料庫是一樣的問題。如果有臨時節點的機器沒有正確處理 邏輯。那麼，整個鎖就會被卡死。解決的辦法也和redis鎖一樣。本質上zk的znode也是乙個key value格式嘛 機器會迴圈遍歷，一旦發現自己的前序臨時節點的前序臨時節點已經刪除。就在本地計時...
分布式session共享的一點理解
session由tomcat管理，session可以理解為乙個物件，我們可以通過request.getsession 獲取session物件。可以呼叫setattribute和getattribute設定session的屬性，例如cookie就是通過setattribute放入session中的。s...
關於使用wcf架構分布式系統的一點想法
使用iis host wcf，可以很方便的做負載均衡。利用這個特點，可以在架構的時候把邏輯層，資料層等部分以wcf的形式發布。並且，對乙個大型系統來說，總是有若干不同的模組，這些模組有些使用量大，有些使用量小，對每個模組都以wcf的形式發布，那麼我們可以給使用量大的模組多負載幾個，而使用量小的則少負...