RabbitMQ 冪等性概念及業界主流解決方案

1、什麼是冪等性

能夠參考數據庫樂觀鎖機制，好比執行一條更新庫存的 SQL 語句，在併發場景，爲了性能和數據可靠性，會在更新時加上查詢時的版本，而且更新這個版本信息。可能你要對一個事情進行操做，這個操做可能會執行成百上千次，可是操做結果都是相同的，這就是冪等性。

2、消費端的冪等性保障

在海量訂單生成的業務高峯期，生產端有可能就會重複發生了消息，這時候消費端就要實現冪等性，這就意味着咱們的消息永遠不會被消費屢次，即便咱們收到了同樣的消息。

業界主流的冪等性有兩種操做：

1.惟一 ID + 指紋碼 機制，利用數據庫主鍵去重

2.利用redis的原子性去實現
複製代碼

3、惟一 ID + 指紋碼 機制

你們確定懂惟一 ID 的，就很少說了，爲何須要指紋碼呢？這是爲了應對用戶在一瞬間的頻繁操做，這個指紋碼多是咱們的一些規則或者時間戳加別的服務給到的惟一信息碼，它並不必定是咱們系統生成的，基本都是由咱們的業務規則拼接而來，可是必定要保證惟一性，而後就利用查詢語句進行判斷這個id是否存在數據庫中。

好處就是實現簡單，就一個拼接，而後查詢判斷是否重複。

壞處就是在高併發時，若是是單個數據庫就會有寫入性能瓶頸

解決方案 ：根據 ID 進行分庫分表，對 id 進行算法路由，落到一個具體的數據庫，而後當這個 id 第二次來又會落到這個數據庫，這時候就像我單庫時的查重同樣了。利用算法路由把單庫的冪等變成多庫的冪等，分攤數據流量壓力，提升性能。

4、利用 redis 的原子性去實現

相信你們都知道 redis 的原子性操做，我這裏就不須要過多介紹了。

使用 redis 的原子性去實現須要考慮兩個點

一是 是否 要進行數據落庫，若是落庫的話，關鍵解決的問題是數據庫和緩存如何作到原子性？ 數據庫與緩存進行同步確定要進行寫操做，到底先寫 redis 仍是先寫數據庫，這是個問題，涉及到緩存更新與淘汰的問題

二是若是不落庫，那麼都存儲到緩存中，如何設置定時同步的策略？ 不入庫的話，可使用雙重緩存等策略，保障一個消息副本，具體同步可使用相似 databus 這種同步工具。