2018-07-18
先佔個坑，回頭再來完善下這篇文章，有思路想法的歡迎大家留言交流
爲什麼把這個問題拋出來的，因爲瞭解到有公司的訂單號ID本身是隨機的，也是雜亂無序的，但是訂單號ID的最後1位隨機性不強，在一次大促期間引發了嚴重的事故。
舉個例子：
訂單號ID的最後1位只會有1，2，3，4這4種可能性，考慮到單位時間內訂單量的不確定性，我們通常會寫入到一個臨時表（訂單緩衝表）。
然後會由另外一個程序編寫週期性任務處理訂單，這個程序通常也是支持分佈式的，多機部署的，假若部署了10臺，採用tbschedule框架進行訂單分片，讓每一臺機器只處理其中一部分訂單，研發小哥們會怎麼做呢，由於自己投入了10臺機器來幹這件事，所以就簡單的將訂單號按10求餘數，根據餘數來決定由哪臺機器來處理。
問題就來了，按10求餘的話，按照上面說的，最後只會有1，2，3，4這4種餘數，投入的10臺機器最終只會有4機器被分配到訂單，另外6臺就由於空轉，一直閒着。當訂單量不高的時，靠4臺幹活的機器支撐平時系統一直也都還OK的。
大家都知道大促期間系統產生的訂單可能是平時的十倍甚至幾十倍，就這樣在一次大促中，那4臺苦命幹活的機器終於支撐不住，訂單處理的速度遠遠達不到訂單生產的速度，嚴重的影響了訂單履約的時效，一時間用戶、商家/司機、客服、運營的壓力，最關鍵的是影響到大家對公司品牌的認可。
暴露出來的問題：
6臺機器雖然部署了程序，但是本身處於空轉不幹活，硬件成本造成了一定程序的浪費。
4臺機器在大促期間之所以抗不住，是因爲我們對系統處理能力的預估不足，壓力測試的模型不夠合理
歷史上常見的分佈式ID方案：
大家可以參見我之前轉發的一篇文章，我們依次來尋找解決方案
https://blog.csdn.net/hl_java/article/details/78462283
如何解決：
- ID最後一位採用隨機數
- ID最後一位採用機器ID號（機器ID號命名要保證後期取餘均勻性）
- ID生成規則不變，在進行任務分片時作爲字符串對待先計算出hashcode，再利用hashcode進行求餘也是可以的