怎么保證web分布式系統(tǒng)中接口調(diào)用的順序性

問題引入

一般來說，我們多個接口的調(diào)用是不用保證順序的，但是有的時候，有的業(yè)務(wù)場景可能確實是需要嚴格的順序來保證系統(tǒng)的準確性。

舉個例子，分布式架構(gòu)中的服務(wù)A調(diào)用服務(wù)B，發(fā)了兩個請求，一個插入操作一個刪除操作，本來是先插入再刪除。但是很可能倆請求過去了，集群部署的情況下落在了不同機器上，可能插入請求因為某些原因執(zhí)行慢了一些，導致刪除請求先執(zhí)行了，此時因為沒數(shù)據(jù)所以沒有啥效果沒有啥影響；接著這個時候插入執(zhí)行完了，好，把數(shù)據(jù)插入進去了，這不就完全錯了嘛。

本來應(yīng)該是插入 -> 刪除，最終這條數(shù)據(jù)應(yīng)該沒了，結(jié)果現(xiàn)在是刪除 -> 插入，導致最后數(shù)據(jù)還存在，然后你死都想不明白是怎么回事。你只能通過不同機器上的日志去看，費半天勁去查，最后比對倆操作的執(zhí)行時間，可能最后也能查出來問題所在。

這，就是分布式系統(tǒng)中一個很常見的問題，那我們該如何保證接口的調(diào)用順序呢？

解決方案分析

1、盡量避免引入順序性

首先，一般來說，我個人給你的建議是，你們從業(yè)務(wù)邏輯上最好設(shè)計的這個系統(tǒng)不需要這種順序性的保證，因為一旦引入順序性保障，我們就需要引入一些的別的、復雜的技術(shù)（如分布式鎖）來保證，這樣會導致系統(tǒng)的復雜度上升，而且會導致系統(tǒng)性能下降，吞吐量降低，熱點數(shù)據(jù)壓力過大等問題。

2、一致性hash+內(nèi)存隊列

其次，如果不得不保證順序性的話，下面給個我們用過的方案吧。

簡單來說，首先你得用一致性hash負載均衡策略，將比如同一個訂單id對應(yīng)的請求都給分發(fā)到同一個機器上去。接著就是在那個機器上，因為可能還是多線程并發(fā)執(zhí)行的，你就得將這個訂單id對應(yīng)的請求扔進一個內(nèi)存隊列里去，強制排隊，這樣來確保他們的順序性。

如下圖所示：

3、分布式鎖

復雜點的，使用基于zookeeper的分布式鎖來實現(xiàn)接口調(diào)用的強順序性。

首先服務(wù)A發(fā)送的三個有序請求請求1、2、3，依次發(fā)送到消息對列，然后服務(wù)B的多個實例從消息對列消費。假如分別是三個實例拿到了1/2/3三個請求，那么當請求執(zhí)行時需要小從zookeeper獲取鎖，才能執(zhí)行。所以此時我們的服務(wù)A還要指明這三個請求的執(zhí)行順序，即seq=1/2/3，服務(wù)B才能知道執(zhí)行順序。

這時候三個請求都來獲取鎖，假如請求3先獲取到鎖，然后看Redis這個list是不是有比自己小的序號，有則釋放鎖。然后如果請求1拿到了鎖，也去Redis判斷是不是有比自己小的序號，一看沒有，就執(zhí)行請求1，然后從Redis的list里刪掉這個序號。。。依次這樣來獲取鎖->判斷->刪除redis里的序號。。。來保證接口的順序性。

如下圖所示：