一、介紹

冪等性就是針對(duì)同一個(gè)請(qǐng)求，不管該請(qǐng)求被提交了多少次，該請(qǐng)求都將被視為同一個(gè)請(qǐng)求，服務(wù)端不應(yīng)該將同一個(gè)請(qǐng)求進(jìn)行多次處理，以確認(rèn)處理邏輯的正確性，針對(duì)交易性系統(tǒng)冪等性的設(shè)計(jì)尤為重要，否則由于網(wǎng)絡(luò)或服務(wù)器處理超時(shí)等問題，就會(huì)造成交易混亂，最嚴(yán)重的后果就是亂扣用戶的錢，造成投訴満天飛。

?

二、客戶端設(shè)計(jì)原則

系統(tǒng)設(shè)計(jì)時(shí)，一定是要從最壞的角度上去考慮，如網(wǎng)絡(luò)問題、服務(wù)器問題，甚至于包括人為的攻擊行為，如果純粹從服務(wù)端的角度去做實(shí)現(xiàn)保證，一個(gè)是系統(tǒng)的復(fù)雜度會(huì)加大，二個(gè)也會(huì)對(duì)系統(tǒng)產(chǎn)生更大的并發(fā)壓力，因而客戶端的合理設(shè)計(jì)也非常重要，舉一個(gè)示例：

用戶在網(wǎng)頁端或APP端（統(tǒng)稱為客戶端）上購(gòu)買一個(gè)商品，通常都是以觸發(fā)按鈕的行為提交該請(qǐng)求，如果客戶端沒有做請(qǐng)求提交控制，那么由于網(wǎng)絡(luò)原因或者系統(tǒng)繁忙等原因（這是非常常見的場(chǎng)景），沒有在用戶期望的時(shí)間之內(nèi)響應(yīng)，那么用戶就會(huì)再次點(diǎn)擊，那么這個(gè)請(qǐng)求又會(huì)發(fā)往服務(wù)端，那么服務(wù)端又會(huì)再次對(duì)這個(gè)請(qǐng)求進(jìn)行處理。

針對(duì)這種場(chǎng)景，服務(wù)端就會(huì)接收處理到多個(gè)訂單請(qǐng)求，從而產(chǎn)生多條不合理的用戶訂單。此時(shí)在客戶端稍微優(yōu)化一下，當(dāng)用戶的請(qǐng)求提交以后，將訂單提交的請(qǐng)求按鈕置為不可用的狀態(tài)，待請(qǐng)求成功響應(yīng)后跳轉(zhuǎn)到下一步處理邏輯，或者是提單請(qǐng)求超時(shí)后再將訂單提交按鈕置為可用，提示用戶上一次的提交可能已經(jīng)失敗，并允許用戶再次提交。

當(dāng)然客戶端這樣設(shè)計(jì)并不能完全做到冪等性原則，因?yàn)橛脩敉瑯涌梢葬槍?duì)相同的訂單執(zhí)行多次提交，服務(wù)端如果沒有做控制，還是會(huì)產(chǎn)生多個(gè)訂單，只是讓錯(cuò)誤變得優(yōu)雅了一點(diǎn)。這個(gè)時(shí)候需增加令牌策略，在下單之間，針對(duì)當(dāng)前訂單從服務(wù)端獲取一個(gè)Token，每次提交的時(shí)候都從把該Token帶上，針對(duì)同一個(gè)訂單帶上相同的值，這樣服務(wù)端就可以根據(jù)該Token來判斷是不是一個(gè)已經(jīng)處理的了訂單。

說了那么多，看文字太累，還是看圖方便，來一個(gè)：

?三、服務(wù)端設(shè)計(jì)原則

根據(jù)不同的應(yīng)用場(chǎng)景，服務(wù)端可以使用不同的解決方式，如：

1、數(shù)據(jù)庫(kù)的樂觀鎖； 2、防重表； 3、token令牌； 4、分布式鎖； 5、異步處理支付；

其中數(shù)據(jù)庫(kù)的樂觀鎖和防重表的使用，都是涉及到數(shù)據(jù)的參與，在高并發(fā)的應(yīng)用場(chǎng)景中，業(yè)務(wù)的判斷邏輯盡量不要使用數(shù)據(jù)庫(kù)參與，特別是RDBMS的參與，因?yàn)镽DBMS天生具有不易擴(kuò)展及事務(wù)處理屬性，吞吐量上都會(huì)有相應(yīng)的瓶頸，因而用數(shù)據(jù)庫(kù)做業(yè)務(wù)邏輯的控制不是我的菜，這里就不會(huì)重點(diǎn)說這兩種方式。

1、Token令牌+分布式鎖的方式

Token是用于確定交易的唯一屬性，也是服務(wù)端用于檢驗(yàn)當(dāng)前交易是否合法交易的依據(jù)，但是在分布式的復(fù)雜環(huán)境中，如果沒有分布式鎖的控制，同一筆交易就可能會(huì)被處理多次，因而為了確認(rèn)交易的冪等性，Token令牌和分布式鎖必須要一起使用。

實(shí)現(xiàn)邏輯步驟如下：

1、服務(wù)端根據(jù)交易前請(qǐng)求生成對(duì)應(yīng)的Token，保存于服務(wù)端的Token庫(kù)中，通常是緩存集群中，并將生成好的Token庫(kù)下發(fā)給客戶端； 2、客戶端在每次請(qǐng)求的時(shí)候，都帶上對(duì)應(yīng)的Token； 3、服務(wù)端獲取該Token對(duì)應(yīng)的鎖，如果獲取成功，則繼續(xù)下面的步驟； 4、判斷是否該Token是否合法，如果合法則繼續(xù)下一步； 5、處理真實(shí)的業(yè)務(wù)邏輯； 6、業(yè)務(wù)處理成功后，從緩存中刪除該Token； 7、刪除獲取的分布式鎖；

實(shí)現(xiàn)邏輯參見下圖：

?

其中分布式鎖的獲取，可以通過Redis和Zookeeper實(shí)現(xiàn)，請(qǐng)參看筆者的另外兩篇分別介紹通過Redis和Zookeeper實(shí)現(xiàn)分布式的文章：

集群環(huán)境中使用Redis實(shí)現(xiàn)分布式鎖兩種方式

集群環(huán)境中使用Zookeeper實(shí)現(xiàn)分布式冪等控制

2、異步處理

異步處理，通常的做法是將認(rèn)為需要消費(fèi)的交易，提交到消息隊(duì)列中，并注冊(cè)監(jiān)聽事件，待交易被處理完后，再由處理交易的應(yīng)用回調(diào)注冊(cè)的監(jiān)聽事件反饋處理的結(jié)果。交易處理的調(diào)度應(yīng)用，需要負(fù)責(zé)對(duì)交易的處理符合冪等性的原則，將重復(fù)請(qǐng)求的交易請(qǐng)求做去重處理。

實(shí)現(xiàn)邏輯見下圖：

?

從邏輯處理上可以看到，只要交易處理器足夠多，處理速度也不一定會(huì)受到多少的影響，交易生產(chǎn)者和交易接收者甚至可以同步返回結(jié)果，當(dāng)交易接收者接收處理結(jié)果超時(shí)后，再提示用戶過一會(huì)兒查看交易的處理結(jié)果。

轉(zhuǎn)載于:https://www.cnblogs.com/fenglibing/p/11026287.html

總結(jié)

以上是生活随笔為你收集整理的交易系统高并发下的幂等性设计原则的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。