目錄使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了***。
舉個最簡單的例子，那就是支付，使用者購買商品後支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，使用者再次點選按鈕，此時會進行第二次扣款，返回結果成功，使用者查詢餘額發現多扣錢了，流水記錄也變成了兩條。在以前的單應用系統中，我們只需要把資料操作放入事務中即可，發生錯誤立即回滾，但是再響應客戶端的時候也有可能出現網路中斷或者異常等等9.1.2.
消費者在消費 mq 中的訊息時，mq 已把訊息傳送給消費者，消費者在給 mq 返回 ack 時網路中斷，故 mq 未收到確認資訊，該條訊息會重新發給其他的消費者，或者在網路重連後再次傳送給該消費者，但實際上該消費者已成功消費了該條訊息，造成消費者消費了重複的訊息。
mq 消費者的冪等性的解決一般使用全域性 id 或者寫個唯一標識比如時間戳 或者 uuid 或者訂單消費者消費 mq 中的訊息也可利用 mq 的該 id 來判斷，或者可按自己的規則生成乙個全域性唯一 id，每次消費訊息時用該 id 先判斷該訊息是否已消費過。
在海量訂單生成的業務高峰期，生產端有可能就會重**生了訊息，這時候消費端就要實現冪等性，這就意味著我們的訊息永遠不會被消費多次，即使我們收到了一樣的訊息。業界主流的冪等性有兩種操作:a.唯一 id+指紋碼機制,利用資料庫主鍵去重, b.利用 redis 的原子性去實現
指紋碼:我們的一些規則或者時間戳加別的服務給到的唯一資訊碼,它並不一定是我們系統生成的，基本都是由我們的業務規則拼接而來，但是一定要保證唯一性，然後就利用查詢語句進行判斷這個 id 是否存在資料庫中,優勢就是實現簡單就乙個拼接，然後查詢判斷是否重複；劣勢就是在高併發時，如果是單個資料庫就會有寫入效能瓶頸當然也可以採用分庫分表提公升效能，但也不是我們最推薦的方式。
利用 redis 執行 setnx 命令，天然具有冪等性。從而實現不重複消費
RabbitMQ 冪等性概念及業界主流解決方案
可以參考資料庫樂觀鎖機制，比如執行一條更新庫存的 sql 語句，在併發場景，為了效能和資料可靠性，會在更新時加上查詢時的版本，並且更新這個版本資訊。可能你要對乙個事情進行操作，這個操作可能會執行成百上千次，但是操作結果都是相同的，這就是冪等性。在海量訂單生成的業務高峰期，生產端有可能就會重 生了訊息...
原子性 冪等性
原子性 如果這個操作所處的層 layer 的更高層不能發現其內部實現與結構，那麼這個操作是乙個原子 atomic 操作。原子操作可以是乙個步驟，也可以是多個操作步驟，但是其順序不可以被打亂，也不可以被切割而只執行其中的一部分。將整個操作視作乙個整體是原子性的核心特徵。冪等性 再簡單一點說，在乙個業務...
冪等性學習及介面的冪等性
冪等性學習 一 什麼是冪等性 在這裡需要有以下幾個問題需要注意 2 冪等性不僅僅只是一次或者多次請求的時候對資源沒有 比如根據id對資料庫的查詢操作，此操作對資料庫沒有增刪改，所以多次查詢操作對資料庫結果是沒有任何影響的 3 冪等性還包括了第一次請求資源的時候，對資源產生了 但是在以後多次同樣的請求...