問題引入

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

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

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

這，就是分布式系統(tǒng)中一個(gè)很常見的問題，那我們?cè)撊绾伪ＷC接口的調(diào)用順序呢？

解決方案分析

1、盡量避免引入順序性

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

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

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

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

如下圖所示：

3、分布式鎖

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

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

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

如下圖所示：