小說：白話冪等性設計

(以下故事純屬虛構，如有雷同純屬巧合！)

一月的深圳，一如既往的炎熱！

某天，煙哥正一邊喝著 芝芝芒芒 ，一邊愉快的裝13！

突然，小劉滿臉愁容的找到了我，對我說:"煙哥，自從我們的單體應用拆成微服務架構後，不知為啥，老是出現數據不一致的問題！已經都快被客戶罵死了，人家客戶明明只點了一次，我們這邊卻有了兩條資料！"

其實煙哥在裝13的時候，被人打擾，這是大忌！大忌！然而，看在小劉是個妹紙的份上，我就不計較了！沒錯，我就是這麼沒原則的人！其實我本來可以直接告訴人家怎麼解決的，然而無恥的煙哥，為了多和妹紙說會話，決定多囉嗦一會！

只見煙哥嘴角嘿嘿一笑，問到:"你知道 為什麼拆成微服務架構後，會出現資料不一致問題麼？ "

接下來的情形，無法用言語形容，各位看官請看下面這張圖

煙哥解釋到:"因為在傳統應用中，呼叫介面，只有兩種狀態 成功 和 失敗 。但是呢，在微服務的架構下，還有第三種情況，那就是 超時 ！小劉啊，你們的服務，呼叫另一個服務，如果超時了，你們是怎麼處理的呢？"

小劉說:"重試啊！呼叫超時了，重試一下唄！"

這時，煙哥的表情突然變成了這樣

煙哥回答到:"對的！小劉真聰明！然而， 重試只是一種方法！ 還有一種就是，呼叫方在超時後，去查詢一次被呼叫方。如果能查到資料，就代表呼叫過了，不繼續執行，如果查不到資料，走失敗流程！因為你們在呼叫超時的情況下，進行重試呼叫，就給系統帶來了不一致問題了！因此我們必須給呼叫介面提供 冪等性 保證，防止重複調用出現不一致的情形！"

這個時候，小劉表情變成了這樣

"哦，小劉，你懂？來來來，說說 什麼是介面冪等性？ "

說時遲，那時快，只見小劉揮舞著她的小手，說道：“介面的冪等性實際上就是介面可重複呼叫,在呼叫方多次呼叫的情況下,介面最終得到的結果是一致的。”

這種時候，煙哥痛心疾首，

只見煙哥眉毛微微一皺，開始裝13的解釋道：“如果按這麼解釋，比如一個查詢介面。假設SQL是下面的這樣的

select * from table；

這個時候，有一個執行緒，一直往這個 table 插入資料，那你每次呼叫查詢介面的返回值肯定不一樣啊！你能說查詢操作不是冪等性操作？

應該要這麼理解， 冪等性強調的是外界通過介面對系統內部的影響, 外界怎麼看系統和冪等性沒有關係，只要一次或多次呼叫對某一個資源應該具有同樣的副作用就行。注意了，是對資源造成的副作用必須是一樣的，但是返回值允許不同！ ”

說到這裡，小劉一臉懵逼的看著我。。。

煙哥說道：“就用，增、刪、改、查來舉例一下吧！”

(1)查詢操作

查詢操作並不會產生或變更新的資料，因此查詢是天然具備冪等性。

(2)刪除操作

這裡分為 物理刪除 和 邏輯刪除

• 物理刪除:刪除只會進行一次，無論執行幾次 delete 操作，造成的效果是一樣的！是冪等性操作

• 邏輯刪除:這類刪除，是用 update 修改欄位而已，這種操作無論 update 幾次，造成的效果是一樣的！是冪等性操作

(3)增加操作

這裡要看這張表是否帶唯一索引。

• 帶唯一索引Insert:此時如果重複插入操作，是會插入失敗的！該操作是冪等性操作

• 不帶唯一索引Insert: 這種情況是非冪等性操作。

(4)修改操作

要看修改了啥

• 計算式Update:這類操作是指 UPDATE table SET number=number-1 WHERE id=1 ，這類SQL的操作，是非冪等性操作！

• 非計算式Update:這類操作是指 UPDATE table SET number=3 WHERE id=1 ，這類SQL操作，這種修改是屬於冪等性的操作！

小劉:"煙哥，你可以先說說網上說的什麼 on DUPLICATE KEY UPDATE 是什麼東西麼,就像下面這個SQL這樣！"

insert into table (goods_id,update_time)
values(#{goodsId},now())
on DUPLICATE KEY UPDATE
update_time=now()

煙哥:"好，你還記得我剛說的，在表有唯一索引的情況下，此時如果有重複插入操作，是會插入失敗的麼！"

小劉:"嗯嗯。記得！"

煙哥:"OK,這種插入失敗，從嚴格意義上來說是分為兩種情況的！"

第一種就是 報唯一鍵衝突異常 ！例如常規的 INSERT INTO tablename(列名) VALUES(列值) 這樣的語句！

第二種就是 不報異常 ，Mysql提供了三組這樣防止重複插入的語句，必須要有唯一索引才能用的

• insert ignore into :若有導致 unique key 衝突的記錄，則該條記錄不會被插入到資料庫中.

• replace :若插入時如發現 unique key 已存在，則替換原記錄，即先刪除原記錄，後 insert 新記錄。

• on duplicate key update :若插入時如果發現 unique key 已存在，則執行 update 更新操作

小劉:"可是這些語句畢竟是Mysql的方言，換了資料庫就不能用了啊！通用性太差，而且還規定一定要有唯一索引才能用!麻煩!"

此時煙哥的反應是這樣的

煙哥捋了捋自己的思緒，說道:"回到我們剛才的話題，現在只有 不帶唯一索引Insert 和 計算式Update 會引起冪等性問題的，懂了嘛？"

小劉抹了抹自己的眼淚，像下面這樣

煙哥淡然的解釋道:"現在網上大多數文章推薦全域性token的方案，就是這樣的。生成一個全域性性唯一的token，然後請求過來的時候，查一下token存在麼，存在代表做過了，就丟棄。不存在，就執行正常業務流程，把token丟到某個儲存介質裡！"

小劉聽了聽，搖了搖頭:"煙哥啊，這個方案乍聽之下很完美！但是細想一下還是有一點不大好。你看啊，假設有1000個請求，重複請求一般不到10個。為了這不到10個請求的正確性，讓剩下990個正常的請求都多一個查詢流程，這似乎不大妥吧！"

煙哥突然驚呆了，此刻感覺如下

煙哥補充道：“嗯，是的，所以我個人還是主張在資料庫的操作上解決這個問題！就插入操作來說，建議還是建一個唯一索引，來防止重複插入！”

小劉:"可是我們的資料量很小，就是不想建索引怎麼辦？"

煙哥說道：“那你的插入語句可以像下面這麼修改

INSERT INTO table(field1, field2, fieldn) SELECT 'field1', 
'field2', 'fieldn' FROM DUAL WHERE NOT EXISTS(SELECT field
 FROM table WHERE field = ?)

採 用這種寫法，就可以防止重複插入，而且不需要建立唯一索引！SQL可以判斷field欄位有值，則不insert。如果無值，則會執行insert操作！這種方法其實就是使用了mysql的一個臨時表的方式，但是裡面使用到了子查詢，效率也會有一點點影響。但是很重要的一點，這種寫法在oracle裡也能跑的通，通用性之強，無與倫比。如果真的達到了影響效能那個級別了，估計資料量夠大，可以用上索引了。這會資料量太小，先這麼寫吧！”

小劉:"那針對修改場景怎麼辦？"

煙哥說道：“也很簡單，加一個版本欄位就行！比如，原來的sql為

UPDATE table SET number=number-1 WHERE id=1

,你加一個版本號欄位就好啦，變成

UPDATE table SET number=number-1，_version=_version+1
WHERE id=1 AND _version= last_version

唯一的缺點，就是執行前，需要去資料查一下當前版本是啥！當然啦，如果你的表有唯一索引，用的又是 mysql ，又能保證將來不換其他資料庫。可以試試 mysql 的 on duplicate key update 語句，該操作插入時如果發現 unique key 已存在，則執行 update 更新操作”

煙哥補充道:"在資料庫層面的改變是最方便的，所以我一直主張，改sql，改表結構來解決冪等性問題。不要引入一堆七七八八的東東，徒增系統複雜度。好啦，小劉快回去改sql吧！"

於是，小劉就愉快的回去的改sql了！！

各位看官一定發現了，本來改個SQL就能解決的問題，煙哥硬是扯了半個多小時！當然，最後的結局就是下面這樣