冪等性的概念

用戶同一操作請求了一次或者多次，最終的結(jié)果應(yīng)該是一致的，并不會(huì)因?yàn)槎啻握埱螽a(chǎn)生副作用；冪等操作的特點(diǎn)是“多次執(zhí)行所產(chǎn)生的結(jié)果與一次執(zhí)行的結(jié)果相同”。比如：

• 付款操作的時(shí)候，請求已經(jīng)發(fā)送給服務(wù)端，但是由于網(wǎng)絡(luò)原因未收到付款結(jié)果（實(shí)際上已成功），再次操作付款的時(shí)候，不應(yīng)該成功；

• 在頁面做新建操作的時(shí)候，手抖連點(diǎn)了新增按鈕，那么應(yīng)該只會(huì)創(chuàng)建出一條數(shù)據(jù)；

查詢和刪除

查詢和刪除操作，天然具有冪等性；也就是多次執(zhí)行查詢或刪除操作的時(shí)候，結(jié)果和執(zhí)行一次查詢或刪除的結(jié)果是一樣的。

但是要注意，多次執(zhí)行刪除的返回內(nèi)容可能不同，比如第一次刪除成功，后面再執(zhí)行刪除的話，會(huì)顯示數(shù)據(jù)不存在。

保證冪等性的方案

新增和修改，如果不做冪等性處理，可能就會(huì)產(chǎn)生問題（如果修改只是把某些字段更新成固定的值，不會(huì)有冪等性問題，但是如果新值要在舊值上做處理做計(jì)算，如增加多少、減少多少，那么多次執(zhí)行的結(jié)果就會(huì)有差異）；那么保證冪等性有哪些方案呢？（給出我知道的方案，方案有好有壞）

• 悲觀鎖：獲取數(shù)據(jù)的時(shí)候加鎖獲取；select*fromtablewherecol='xxx'forupdate;只能說是一種實(shí)現(xiàn)方案，但是不是特別好；
  

• 樂觀鎖：在更新數(shù)據(jù)那一刻鎖表，可以通過條件限制，也可以通過版本號來實(shí)現(xiàn)，比如：數(shù)據(jù)中增加版本號的概念，那么在做數(shù)據(jù)修改，把當(dāng)前數(shù)據(jù)的版本號帶上，修改的時(shí)候要按照版本號判斷數(shù)據(jù)是否發(fā)生過更改。如果沒有發(fā)生過更改，則執(zhí)行業(yè)務(wù)操作，并更新版本號。
  

• 分布式鎖：在業(yè)務(wù)系統(tǒng)執(zhí)行插入或更新操作的時(shí)候，先要獲取分布式鎖，然后做操作，之后釋放鎖；分布式鎖保證在一個(gè)時(shí)間內(nèi)，只會(huì)有一個(gè)線程對數(shù)據(jù)進(jìn)行操作；
  

• 全局唯一請求ID：每一次的請求，都帶有一個(gè)全局唯一的請求ID，這個(gè)請求ID只要執(zhí)行過一次就失效了：
  

• 狀態(tài)冪等：如果業(yè)務(wù)流程中的每個(gè)階段，數(shù)據(jù)都有不同的狀態(tài)，那么當(dāng)數(shù)據(jù)已經(jīng)處于下一個(gè)狀態(tài)的時(shí)候，這時(shí)候又來了上一個(gè)狀態(tài)的變更，是不會(huì)執(zhí)行成功的（其實(shí)有些類似于版本號的概念，不過這個(gè)狀態(tài)是有業(yè)務(wù)含義的）。
  

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。