如何保證分布式系統中介面呼叫的順序性？
分布式是當下比較流行的乙個話題，很多大型的網際網路公司都是分布式系統，將乙個大而全的系統拆分成多個小而精的乙個個的功能單
一、職責集中的子系統，系統之間通過約定好的協議、規則進行呼叫，降低系統之間的耦合度，避免牽一髮而動全身。
雖然分布式系統的架構有很多的好處，但不得不說它也存在很多需要特別注意的問題。我們今天要講的分布式系統中介面的呼叫順序，就是其中乙個很常見的問題。
一般來說，我們多個介面的呼叫是不用保證順序的，但是有的時候，有的業務場景可能確實是需要嚴格的順序來保證系統的準確性。
舉個例子，分布式架構中的服務a呼叫服務b，發了兩個請求，乙個插入操作乙個刪除操作，本來是先插入再刪除。但是很可能倆請求過去了，集群部署的情況下落在了不同機器上，可能插入請求因為某些原因執行慢了一些，導致刪除請求先執行了，此時因為沒資料所以沒有啥效果沒有啥影響；接著這個時候插入執行完了，好，把資料插入進去了，這不就完全錯了嘛。
本來應該是插入 -> 刪除，最終這條資料應該沒了，結果現在是刪除 -> 插入，導致最後資料還存在，然後你死都想不明白是怎麼回事。你只能通過不同機器上的日誌去看，費半天勁去查，最後比對倆操作的執行時間，可能最後也能查出來問題所在。
這，就是分布式系統中乙個很常見的問題，那我們該如何保證介面的呼叫順序呢？
首先，一般來說，我個人給你的建議是，你們從業務邏輯上最好設計的這個系統不需要這種順序性的保證，因為一旦引入順序性保障，我們就需要引入一些的別的、複雜的技術（如分布式鎖）來保證，這樣會導致系統的複雜度上公升，而且會導致系統效能下降，吞吐量降低，熱點資料壓力過大等問題。
其次，如果不得不保證順序性的話，下面給個我們用過的方案吧。
簡單來說，首先你得用一致性hash負載均衡策略，將比如同乙個訂單id對應的請求都給分發到同乙個機器上去。接著就是在那個機器上，因為可能還是多執行緒併發執行的，你就得將這個訂單id對應的請求扔進乙個記憶體佇列裡去，強制排隊，這樣來確保他們的順序性。
如下圖所示：
複雜點的，使用基於zookeeper的分布式鎖來實現介面呼叫的強順序性。
首先服務a傳送的三個有序請求請求1、2、3，依次傳送到訊息對列，然後服務b的多個例項從訊息對列消費。假如分別是三個例項拿到了1/2/3三個請求，那麼當請求執行時需要小從zookeeper獲取鎖，才能執行。所以此時我們的服務a還要指明這三個請求的執行順序，即seq=1/2/3，服務b才能知道執行順序。
這時候三個請求都來獲取鎖，假如請求3先獲取到鎖，然後看redis這個list是不是有比自己小的序號，有則釋放鎖。然後如果請求1拿到了鎖，也去redis判斷是不是有比自己小的序號，一看沒有，就執行請求1，然後從redis的list裡刪掉這個序號。。。依次這樣來獲取鎖->判斷->刪除redis裡的序號。。。來保證介面的順序性。
如下圖所示：
你看看，上面為了保證介面呼叫的順序性是不是又引入了很多複雜的技術，所以這樣後續就會引發很多問題。比如說要是某個訂單對應的請求特別多，造成某台機器成熱點怎麼辦？這樣系統的增加了系統的複雜度，同時系統的效能、吞吐量也會明顯降低，引入zookeeper分布式鎖這種很重的機制，勢必會帶來這些***。而解決這些問題又要開啟後續一連串的複雜技術方案。。。
曾經這類問題弄的我們頭疼不已，所以，還是建議什麼呢？建議盡量避免引入順序性，在系統設計時就避免這個問題，或者最好是像剛才那樣乙個訂單的插入和刪除操作，能不能合併成乙個操作，就是乙個刪除，或者是什麼，避免這種問題的產生。
如何保證分布式系統介面冪等？
這是實戰經常遇到的乙個問題，舉個例子 我們系統的開票介面受理對方系統的報文 結算單號settleno 開票單號ticketno 由於網路抖動或者前端提交多次導致同一筆重複請求，如果不設定冪等，我們系統就會受理多筆相同的請求，最終可能導致多次重複開票的問題。所以我們要保證介面冪等，使得重複請求只會成功...
40 分布式系統中的介面呼叫如何保證順序性？
目錄 1 面試題 2 面試官心裡分析 3 面試題剖析 分布式服務介面請求的順序性如何保證？其實分布式系統介面的呼叫順序，也是個問題，一般來說是不用保證順序的。但是有的時候可能確實是需要嚴格的順序保證。給大家舉個例子，你服務a呼叫服務b，先插入再刪除。好，結果倆請求過去了，落在不同機器上，可能插入請求...
如何保證分布式服務介面請求的順序
分布式系統介面的呼叫順序一般無需保證的，但有時候確實需要嚴格的順序保證。服務 a 呼叫服務 b，先插入再刪除。倆請求過去了，落在不同機器，可能插入請求因某些原因執行慢了一些，導致刪除請求先執行了，此時因為沒資料所以啥效果也沒。結果這時候插入請求過來了，資料插進去了！本該 先插入 再刪除 這條資料應該...