溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“怎么保證web分布式系統中接口調用的順序性”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
一般來說，我們多個接口的調用是不用保證順序的，但是有的時候，有的業務場景可能確實是需要嚴格的順序來保證系統的準確性。
舉個例子，分布式架構中的服務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里的序號。。。來保證接口的順序性。
如下圖所示：
“怎么保證web分布式系統中接口調用的順序性”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
