【Spring Cloud系列】- 分布式系統(tǒng)中實現(xiàn)冪等性的幾種方式

一、概述

在開發(fā)訂單系統(tǒng)時，我們常遇見支付問題，既用戶購買商品后支付，支付扣款成功，但是返回結(jié)果的時候網(wǎng)絡異常，此時錢已經(jīng)扣了，用戶再次點擊按鈕，此時會進行第二次扣款，返回結(jié)果成功，用戶查詢余額發(fā)現(xiàn)多扣錢了，流水記錄也變成了兩條。在以前的單應用系統(tǒng)中，我們只需要把數(shù)據(jù)操作放入事務中即可，發(fā)生錯誤立即回滾，但是再響應客戶端的時候也有可能出現(xiàn)網(wǎng)絡中斷或者異常問題。如果保證一個訂單從創(chuàng)建到支付成功整個訂單生命周期中，數(shù)據(jù)是一致，不因異常而改變。這種機制就需要用到冪等性。

二、什么是冪等性

冪等是一個數(shù)學與計算機的概念，常見于常見于抽象代數(shù)中。

冪等函數(shù)，或冪等方法，是指可以使用相同參數(shù)重復執(zhí)行，并能獲得相同結(jié)果的函數(shù)。這些函數(shù)不會影響系統(tǒng)狀態(tài)，也不用擔心重復執(zhí)行會對系統(tǒng)造成改變。

冪等性：任意多次執(zhí)行對資源本身所產(chǎn)生的影響均與一次執(zhí)行的影響相同

接口的冪等性實際上就是接口可重復調(diào)用，在調(diào)用方多次調(diào)用的情況下，接口最終得到的結(jié)果是一致的，有些接口可以天然的冪等性，比如查詢接口，調(diào)用一次和調(diào)用多次，對系統(tǒng)得到的結(jié)果，是一樣的。并不會因為調(diào)用的次數(shù)改變查詢的結(jié)果。

插入（INSERT）和修改（UPDATE）方法是非冪等性的，需要通過機制在需要的場景處理以確保多次執(zhí)行無副作用。

刪除（delete）執(zhí)行一次或多次都是結(jié)果為空（即結(jié)果一致），并且無副作用，所以在根據(jù)主鍵ID刪除可以認為是（偽）冪等性的，根據(jù)非主鍵刪除的如果多次執(zhí)行無副作用（都是把數(shù)據(jù)刪除），也可以認為是（偽）冪等性。

三、冪等性需關(guān)注幾個重點

1. 冪等不僅僅只是一次（或多次）請求對資源沒有副作用（比如查詢數(shù)據(jù)庫操作，沒有增刪改，因此沒有對數(shù)據(jù)庫有任何影響）
2. 冪等還包括第一次請求的時候?qū)Y源產(chǎn)生了副作用，但是以后的多次請求都不會再對資源產(chǎn)生副作用。
3. 冪等關(guān)注的是以后的多次請求是否對資源產(chǎn)生的副作用，而不關(guān)注結(jié)果。
4. 網(wǎng)絡超時等問題，不是冪等性的討論范圍。

冪等性是系統(tǒng)服務對外一種承諾（而不是實現(xiàn)），承諾只要調(diào)用接口成功，外部多次調(diào)用對系統(tǒng)的影響是一致的。聲明為冪等的服務會認為外部調(diào)用失敗是常態(tài)，并且失敗之后必然會有重試。

四、冪等性有什么用

業(yè)務開發(fā)中，經(jīng)常會遇到重復提交的情況，無論是由于網(wǎng)絡問題無法收到請求結(jié)果而重新發(fā)起請求，或是前端的操作抖動而造成重復提交情況。 在交易系統(tǒng)，支付系統(tǒng)這種重復提交造成的問題有尤其明顯，比如：

1. 用戶在APP上連續(xù)點擊了多次提交訂單，后臺應該只產(chǎn)生一個訂單；
2. 向支付寶發(fā)起支付請求，由于網(wǎng)絡問題或系統(tǒng)BUG重發(fā)，支付寶應該只扣一次錢。 很顯然，聲明冪等的服務認為，外部調(diào)用者會存在多次調(diào)用的情況，為了防止外部多次調(diào)用對系統(tǒng)數(shù)據(jù)狀態(tài)的發(fā)生多次改變，將服務設(shè)計成冪等。
3. 出庫單反復請求產(chǎn)生多個出庫單信息。

五、常見用來保證冪等的手段

5.1 MVCC方案

多版本并發(fā)控制，該策略主要使用update with condition（更新帶條件來防止）來保證多次外部請求調(diào)用對系統(tǒng)的影響是一致的。在系統(tǒng)設(shè)計的過程中，合理的使用樂觀鎖，通過version或者updateTime（timestamp）等其他條件，來做樂觀鎖的判斷條件，這樣保證更新操作即使在并發(fā)的情況下，也不會有太大的問題。例如

select * from tablename where condition=#condition# //取出要跟新的對象，帶有版本versoin
update tableName set name=#name#,version=version+1 where version=#version#

在更新的過程中利用version來防止，其他操作對對象的并發(fā)更新，導致更新丟失。為了避免失敗，通常需要一定的重試機制。

5.2 去重表

在插入數(shù)據(jù)的時候，插入去重表，利用數(shù)據(jù)庫的唯一索引特性，保證唯一的邏輯。

這種方法適用于在業(yè)務中有唯一標的插入場景中，比如在以上的支付場景中，如果一個訂單只會支付一次，所以訂單ID可以作為唯一標識。這時，我們就可以建一張去重表，并且把唯一標識作為唯一索引，在我們實現(xiàn)時，把創(chuàng)建支付單據(jù)和寫入去去重表，放在一個事務中，如果重復創(chuàng)建，數(shù)據(jù)庫會拋出唯一約束異常，操作就會回滾。

5.3 去重表

select for update，整個執(zhí)行過程中鎖定該訂單對應的記錄。注意：這種在DB讀大于寫的情況下盡量少用。

5.4 select + insert

并發(fā)不高的后臺系統(tǒng)，或者一些任務JOB，為了支持冪等，支持重復執(zhí)行，簡單的處理方法是，先查詢下一些關(guān)鍵數(shù)據(jù)，判斷是否已經(jīng)執(zhí)行過，在進行業(yè)務處理，就可以了。注意：核心高并發(fā)流程不要用這種方法。

5.5 狀態(tài)機冪等

在設(shè)計單據(jù)相關(guān)的業(yè)務，或者是任務相關(guān)的業(yè)務，肯定會涉及到狀態(tài)機，就是業(yè)務單據(jù)上面有個狀態(tài)，狀態(tài)在不同的情況下會發(fā)生變更，一般情況下存在有限狀態(tài)機，這時候，如果狀態(tài)機已經(jīng)處于下一個狀態(tài)，這時候來了一個上一個狀態(tài)的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態(tài)機的冪等。

這種方法適合在有狀態(tài)機流轉(zhuǎn)的情況下，比如就會訂單的創(chuàng)建和付款，訂單的付款肯定是在之前，這時我們可以通過在設(shè)計狀態(tài)字段時，使用int類型，并且通過值類型的大小來做冪等，比如訂單的創(chuàng)建為1000，付款成功為1。付款失敗為999。

5.6 token機制，防止頁面重復提交

業(yè)務要求：頁面的數(shù)據(jù)只能被點擊提交一次，

發(fā)生原因：由于重復點擊或者網(wǎng)絡重發(fā)，或者nginx重發(fā)等情況會導致數(shù)據(jù)被重復提交

解決辦法：

• 集群環(huán)境：采用token加redis（redis單線程的，處理需要排隊）
• 單JVM環(huán)境：采用token加redis或token加jvm內(nèi)存

處理流程：

• 數(shù)據(jù)提交前要向服務的申請token，token放到redis或jvm內(nèi)存，token有效時間
• 提交后后臺校驗token，同時刪除token，生成新的token返回
• token特點:要申請，一次有效性，可以限流

5.7 對外提供接口的api如何保證冪等

如微信提供的付款接口：需要接入商戶提交付款請求時附帶：source來源，seq序列號。source+seq在數(shù)據(jù)庫里面做唯一索引，防止多次付款，(并發(fā)時，只能處理一個請求)

**總結(jié)：**冪等性應該是合格程序員的一個基因，在設(shè)計系統(tǒng)時，是首要考慮的問題，尤其是在像支付寶，銀行，互聯(lián)網(wǎng)金融公司等涉及的都是錢的系統(tǒng)，既要高效，數(shù)據(jù)也要準確，所以不能出現(xiàn)多扣款，多打款等問題，這樣會很難處理，用戶體驗也不好 。

5.7 全局唯一ID

如果使用全局唯一ID，就是根據(jù)業(yè)務的操作和內(nèi)容生成一個全局ID，在執(zhí)行操作前先根據(jù)這個全局唯一ID是否存在，來判斷這個操作是否已經(jīng)執(zhí)行。如果不存在則把全局ID，存儲到存儲系統(tǒng)中，比如數(shù)據(jù)庫、redis等。如果存在則表示該方法已經(jīng)執(zhí)行。

從工程的角度來說，使用全局ID做冪等可以作為一個業(yè)務的基礎(chǔ)的微服務存在，在很多的微服務中都會用到這樣的服務，在每個微服務中都完成這樣的功能，會存在工作量重復。另外打造一個高可靠的冪等服務還需要考慮很多問題，比如一臺機器雖然把全局ID先寫入了存儲，但是在寫入之后掛了，這就需要引入全局ID的超時機制。

使用全局唯一ID是一個通用方案，可以支持插入、更新、刪除業(yè)務操作。但是這個方案看起來很美但是實現(xiàn)起來比較麻煩，下面的方案適用于特定的場景，但是實現(xiàn)起來比較簡單。

5.8 分布式鎖

在進入方法時，先去獲取鎖，假如獲取到鎖，就繼續(xù)后面的流程。假如沒有獲取到鎖，就等待鎖的釋放直到獲取到鎖。當執(zhí)行完方法時，釋放鎖。當然，鎖要設(shè)個超時時間，防止意外沒有釋放到鎖。它用來解決分布式系統(tǒng)的冪等性，常用的實現(xiàn)方案是 redis 和 zookeeper 等工具。

六、總結(jié)

冪等性增加了額外控制冪等的業(yè)務邏輯，復雜化了業(yè)務功能，把并行執(zhí)行的功能改為串行執(zhí)行，降低了執(zhí)行效率。

冪等性雖然復雜化了業(yè)務功能和降低了執(zhí)行效率，但為了保證系統(tǒng)的正確性，是必要的。就上面更新 X 的例子，在單臺服務器上，給那段代碼加上鎖，并給 X 設(shè)為 volatile，就保證來數(shù)據(jù)的正確性了。在分布式環(huán)境下并且 X 是從數(shù)據(jù)庫或者文件里查詢出來的，用上面加鎖的方式實現(xiàn)就不能保證數(shù)據(jù)的正確性了，這時候就需要用到分布式鎖了。所以，保證方法或接口的冪等性是非常有必要的，因為數(shù)據(jù)是不能出現(xiàn)任何問題的。