分佈式服務接口請求的順序性如何保證？

問題

　　其實分佈式系統接口的調用順序，也是個問題，通常來講是不用保證順序的。可是有時候可能確實是須要嚴格的順序保證。給你們舉個例子，你服務 A 調用服務 B，先插入再刪除。好，結果倆請求過去了，落在不一樣機器上，可能插入請求由於某些緣由執行慢了一些，致使刪除請求先執行了，此時由於沒數據因此啥效果也沒有；結果這個時候插入請求過來了，好，數據插入進去了，那就尷尬了。

　　原本應該是 「先插入 -> 再刪除」，這條數據應該沒了，結果如今 「先刪除 -> 再插入」，數據還存在，最後你死都想不明白是怎麼回事。

　　因此這都是分佈式系統一些很常見的問題。

剖析

　　首先，通常來講，我的建議是，大家從業務邏輯上設計的這個系統最好是不須要這種順序性的保證，由於一旦引入順序性保障，好比使用分佈式鎖，會致使系統複雜度上升，並且會帶來效率低下，熱點數據壓力過大等問題。

　　下面我給個咱們用過的方案吧，簡單來講，首先你得用 dubbo 的一致性 hash 負載均衡策略，將好比某一個訂單 id 對應的請求都給分發到某個機器上去（及須要保證順序性的操做請求放到一個機器去處理），接着就是在那個機器上由於可能仍是多線程併發執行的，你可能得當即將某個訂單 id 對應的請求扔一個內存隊列裏去，強制排隊，這樣來確保他們的順序性。

　　可是這樣引起的後續問題就不少，好比說要是某個訂單對應的請求特別多，形成某臺機器成熱點怎麼辦？解決這些問題又要開啓後續一連串的複雜技術方案......曾經這類問題弄的咱們頭疼不已，因此，仍是建議什麼呢？

　　最好是好比說剛纔那種，一個訂單的插入和刪除操做，能不能合併成一個操做，就是一個刪除，或者是什麼，避免這種問題的產生。

 

 出處：https://github.com/doocs/advanced-java/blob/master/docs/distributed-system/distributed-system-request-sequence.md