Ⅰ RabbitMQ，RocketMQ，Kafka 事務性，消息丟失和重復發送處理策略
我們的伺服器從單機發展到擁有多台機器的分布式系統，各個系統之前需要藉助於網路進行通信，原有單機中相對可靠的方法調用以及進程間通信方式已經沒有辦法使用，同時網路環境也是不穩定的，造成了我們多個機器之間的數據同步問題，這就是典型的分布式事務問題。
在分布式事務中事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。分布式事務就是要保證不同節點之間的數據一致性。
1、2PC(二階段提交)方案 - 強一致性
2、3PC(三階段提交)方案
3、TCC （Try-Confirm-Cancel）事務 - 最終一致性
4、Saga事務 - 最終一致性
5、本地消息表 - 最終一致性
6、MQ事務 - 最終一致性
消息的生產方，除了維護自己的業務邏輯之外，同時需要維護一個消息表。這個消息表裡面記錄的就是需要同步到別的服務的信息，當然這個消息表，每個消息都有一個狀態值，來標識這個消息有沒有被成功處理。
發送放的業務邏輯以及消息表中數據的插入將在一個事務中完成，這樣避免了業務處理成功 + 事務消息發送失敗，或業務處理失敗 + 事務消息發送成功，這個問題。
舉個栗子：
我們假定目前有兩個服務，訂單服務，購物車服務，用戶在購物車中對幾個商品進行合並下單，之後需要情況購物車中剛剛已經下單的商品信息。
1、消息的生產方也就是訂單服務，完成了自己的邏輯(對商品進行下單操作)然後把這個消息通過 mq 發送到需要進行數據同步的其他服務中，也就是我們栗子中的購物車服務。
2、其他服務(購物車服務)會監聽這個隊列；
1、如果收到這個消息，並且數據同步執行成功了，當然這也是一個本地事務，就通過 mq 回復消息的生產方(訂單服務)消息已經處理了，然後生產方就能標識本次事務已經結束。如果是一個業務上的錯誤,就回復消息的生產方，需要進行數據回滾了。
2、很久沒收到這個消息，這種情況是不會發生的，消息的發送方會有一個定時的任務，會定時重試發送消息表中還沒有處理的消息；
3、消息的生產方(訂單服務)如果收到消息回執；
1、成功的話就修改本次消息已經處理完，也就是本次分布式事務的同步已經完成；
2、如果消息的結果是執行失敗，同時在本地回滾本次事務，標識消息已經處理完成；
3、如果消息丟失，也就是回執消息沒有收到，這種情況也不太會發生，消息的發送方(訂單服務)會有一個定時的任務，定時重試發送消息表中還沒有處理的消息，下游的服務需要做冪等，可能會收到多次重復的消息，如果一個回復消息生產方中的某個回執信息丟失了，後面持續收到生產方的 mq 消息，然後再次回復消息的生產方回執信息，這樣總能保證發送者能成功收到回執，消息的生產方在接收回執消息的時候也要做到冪等性。
這里有兩個很重要的操作：
1、伺服器處理消息需要是冪等的，消息的生產方和接收方都需要做到冪等性；
2、發送放需要添加一個定時器來遍歷重推未處理的消息，避免消息丟失，造成的事務執行斷裂。
該方案的優缺點
優點：
1、在設計層面上實現了消息數據的可靠性，不依賴消息中間件，弱化了對 mq 特性的依賴。
2、簡單，易於實現。
缺點：
主要是需要和業務數據綁定到一起，耦合性比較高，使用相同的資料庫，會佔用業務資料庫的一些資源。
下面分析下幾種消息隊列對事務的支持
RocketMQ 中的事務，它解決的問題是，確保執行本地事務和發消息這兩個操作，要麼都成功，要麼都失敗。並且，RocketMQ 增加了一個事務反查的機制，來盡量提高事務執行的成功率和數據一致性。
主要是兩個方面，正常的事務提交和事務消息補償
正常的事務提交
1、發送消息（half消息），這個 half 消息和普通消息的區別，在事務提交 之前，對於消費者來說，這個消息是不可見的。
2、MQ SERVER寫入信息，並且返回響應的結果；
3、根據MQ SERVER響應的結果，決定是否執行本地事務,如果MQ SERVER寫入信息成功執行本地事務，否則不執行；
如果MQ SERVER沒有收到 Commit 或者 Rollback 的消息，這種情況就需要進行補償流程了
補償流程
1、MQ SERVER如果沒有收到來自消息發送方的 Commit 或者 Rollback 消息，就會向消息發送端也就是我們的伺服器發起一次查詢，查詢當前消息的狀態；
2、消息發送方收到對應的查詢請求，查詢事務的狀態，然後把狀態重新推送給MQ SERVER，MQ SERVER就能之後後續的流程了。
相比於本地消息表來處理分布式事務，MQ 事務是把原本應該在本地消息表中處理的邏輯放到了 MQ 中來完成。
Kafka 中的事務解決問題，確保在一個事務中發送的多條信息，要麼都成功，要麼都失敗。也就是保證對多個分區寫入操作的原子性。
通過配合 Kafka 的冪等機制來實現 Kafka 的 Exactly Once，滿足了讀取-處理-寫入這種模式的應用程序。當然 Kafka 中的事務主要也是來處理這種模式的。
什麼是讀取-處理-寫入模式呢？
栗如：在流計算中，用 Kafka 作為數據源，並且將計算結果保存到 Kafka 這種場景下，數據從 Kafka 的某個主題中消費，在計算集群中計算，再把計算結果保存在 Kafka 的其他主題中。這個過程中，要保證每條消息只被處理一次，這樣才能保證最終結果的成功。Kafka 事務的原子性就保證了，讀取和寫入的原子性，兩者要不一起成功，要不就一起失敗回滾。
這里來分析下 Kafka 的事務是如何實現的
它的實現原理和 RocketMQ 的事務是差不多的，都是基於兩階段提交來實現的，在實現上可能更麻煩
先來介紹下事務協調者，為了解決分布式事務問題，Kafka 引入了事務協調者這個角色，負責在服務端協調整個事務。這個協調者並不是一個獨立的進程，而是 Broker 進程的一部分，協調者和分區一樣通過選舉來保證自身的可用性。
Kafka 集群中也有一個特殊的用於記錄事務日誌的主題，裡面記錄的都是事務的日誌。同時會有多個協調者的存在，每個協調者負責管理和使用事務日誌中的幾個分區。這樣能夠並行的執行事務，提高性能。
下面看下具體的流程
事務的提交
1、協調者設置事務的狀態為PrepareCommit，寫入到事務日誌中；
2、協調者在每個分區中寫入事務結束的標識，然後客戶端就能把之前過濾的未提交的事務消息放行給消費端進行消費了；
事務的回滾
1、協調者設置事務的狀態為PrepareAbort，寫入到事務日誌中；
2、協調者在每個分區中寫入事務回滾的標識，然後之前未提交的事務消息就能被丟棄了；
這里引用一下【消息隊列高手課中的圖片】
RabbitMQ 中事務解決的問題是確保生產者的消息到達MQ SERVER，這和其他 MQ 事務還是有點差別的，這里也不展開討論了。
先來分析下一條消息在 MQ 中流轉所經歷的階段。
生產階段 ：生產者產生消息，通過網路發送到 Broker 端。
存儲階段 ：Broker 拿到消息，需要進行落盤，如果是集群版的 MQ 還需要同步數據到其他節點。
消費階段 ：消費者在 Broker 端拉數據，通過網路傳輸到達消費者端。
發生網路丟包、網路故障等這些會導致消息的丟失
在生產者發送消息之前，通過channel.txSelect開啟一個事務，接著發送消息， 如果消息投遞 server 失敗，進行事務回滾channel.txRollback，然後重新發送， 如果 server 收到消息，就提交事務channel.txCommit
不過使用事務性能不好，這是同步操作，一條消息發送之後會使發送端阻塞，以等待RabbitMQ Server的回應，之後才能繼續發送下一條消息，生產者生產消息的吞吐量和性能都會大大降低。
使用確認機制，生產者將信道設置成 confirm 確認模式，一旦信道進入 confirm 模式，所有在該信道上面發布的消息都會被指派一個唯一的ID（從1開始），一旦消息被投遞到所有匹配的隊列之後，RabbitMQ 就會發送一個確認（Basic.Ack）給生產者（包含消息的唯一 deliveryTag 和 multiple 參數），這就使得生產者知曉消息已經正確到達了目的地了。
multiple 為 true 表示的是批量的消息確認，為 true 的時候，表示小於等於返回的 deliveryTag 的消息 id 都已經確認了，為 false 表示的是消息 id 為返回的 deliveryTag 的消息，已經確認了。
確認機制有三種類型
1、同步確認
2、批量確認
3、非同步確認
同步模式的效率很低，因為每一條消息度都需要等待確認好之後，才能處理下一條；
批量確認模式相比同步模式效率是很高，不過有個致命的缺陷，一旦回復確認失敗，當前確認批次的消息會全部重新發送，導致消息重復發送；
非同步模式就是個很好的選擇了，不會有同步模式的阻塞問題，同時效率也很高，是個不錯的選擇。
Kafaka 中引入了一個 broker。 broker 會對生產者和消費者進行消息的確認，生產者發送消息到 broker，如果沒有收到 broker 的確認就可以選擇繼續發送。
只要 Procer 收到了 Broker 的確認響應，就可以保證消息在生產階段不會丟失。有些消息隊列在長時間沒收到發送確認響應後，會自動重試，如果重試再失敗，就會以返回值或者異常的方式告知用戶。
只要正確處理 Broker 的確認響應，就可以避免消息的丟失。
RocketMQ 提供了3種發送消息方式，分別是：
同步發送：Procer 向 broker 發送消息，阻塞當前線程等待 broker 響應 發送結果。
非同步發送：Procer 首先構建一個向 broker 發送消息的任務，把該任務提交給線程池，等執行完該任務時，回調用戶自定義的回調函數，執行處理結果。
Oneway發送：Oneway 方式只負責發送請求，不等待應答，Procer 只負責把請求發出去，而不處理響應結果。
在存儲階段正常情況下，只要 Broker 在正常運行，就不會出現丟失消息的問題，但是如果 Broker 出現了故障，比如進程死掉了或者伺服器宕機了，還是可能會丟失消息的。
防止在存儲階段消息額丟失，可以做持久化，防止異常情況(重啟，關閉，宕機)。。。
RabbitMQ 持久化中有三部分：
消息的持久化，在投遞時指定 delivery_mode=2（1是非持久化），消息的持久化，需要配合隊列的持久，只設置消息的持久化，重啟之後隊列消失，繼而消息也會丟失。所以如果只設置消息持久化而不設置隊列的持久化意義不大。
對於持久化，如果所有的消息都設置持久化，會影響寫入的性能，所以可以選擇對可靠性要求比較高的消息進行持久化處理。
不過消息持久化並不能百分之百避免消息的丟失
比如數據在落盤的過程中宕機了，消息還沒及時同步到內存中，這也是會丟數據的，這種問題可以通過引入鏡像隊列來解決。
鏡像隊列的作用：引入鏡像隊列，可已將隊列鏡像到集群中的其他 Broker 節點之上，如果集群中的一個節點失效了，隊列能夠自動切換到鏡像中的另一個節點上來保證服務的可用性。(更細節的這里不展開討論了)
操作系統本身有一層緩存，叫做 Page Cache，當往磁碟文件寫入的時候，系統會先將數據流寫入緩存中。
Kafka 收到消息後也會先存儲在也緩存中(Page Cache)中，之後由操作系統根據自己的策略進行刷盤或者通過 fsync 命令強制刷盤。如果系統掛掉，在 PageCache 中的數據就會丟失。也就是對應的 Broker 中的數據就會丟失了。
處理思路
1、控制競選分區 leader 的 Broker。如果一個 Broker 落後原先的 Leader 太多，那麼它一旦成為新的 Leader，必然會造成消息的丟失。
2、控制消息能夠被寫入到多個副本中才能提交，這樣避免上面的問題1。
1、將刷盤方式改成同步刷盤；
2、對於多個節點的 Broker，需要將 Broker 集群配置成：至少將消息發送到 2 個以上的節點，再給客戶端回復發送確認響應。這樣當某個 Broker 宕機時，其他的 Broker 可以替代宕機的 Broker，也不會發生消息丟失。
消費階段就很簡單了，如果在網路傳輸中丟失，這個消息之後還會持續的推送給消費者，在消費階段我們只需要控制在業務邏輯處理完成之後再去進行消費確認就行了。
總結：對於消息的丟失，也可以藉助於本地消息表的思路，消息產生的時候進行消息的落盤，長時間未處理的消息，使用定時重推到隊列中。
消息在 MQ 中的傳遞，大致可以歸類為下面三種：
1、At most once: 至多一次。消息在傳遞時，最多會被送達一次。是不安全的，可能會丟數據。
2、At least once: 至少一次。消息在傳遞時，至少會被送達一次。也就是說，不允許丟消息，但是允許有少量重復消息出現。
3、Exactly once：恰好一次。消息在傳遞時，只會被送達一次，不允許丟失也不允許重復，這個是最高的等級。
大部分消息隊列滿足的都是At least once，也就是可以允許重復的消息出現。
我們消費者需要滿足冪等性,通常有下面幾種處理方案
1、利用資料庫的唯一性
根據業務情況，選定業務中能夠判定唯一的值作為資料庫的唯一鍵，新建一個流水表，然後執行業務操作和流水表數據的插入放在同一事務中，如果流水表數據已經存在，那麼就執行失敗，藉此保證冪等性。也可先查詢流水表的數據，沒有數據然後執行業務，插入流水表數據。不過需要注意，資料庫讀寫延遲的情況。
2、資料庫的更新增加前置條件
3、給消息帶上唯一ID
每條消息加上唯一ID,利用方法1中通過增加流水表，藉助資料庫的唯一性來處理重復消息的消費。
Ⅱ 雙十一是怎麼保證高並發，分布式系統中，數據一致性
前言 在系統開發過程中，經常遇到數據重復插入、重復更新、消息重發發送等等問題，因為應用系統的復雜邏輯以及網路交互存在的不確定性，會導致這一重復現象，但是有些邏輯是需要有冪等特性的，否則造成的後果會比較嚴重，例如訂單重復創建，這時候帶來的問題可是非同一般啊。 什麼是系統的冪等性 冪等是數據中得一個概念，表示N次變換和1次變換的結果相同。 高並發的系統如何保證冪等性？ 1.查詢 查詢的API，可以說是天然的冪等性，因為你查詢一次和查詢兩次，對於系統來講，沒有任何數據的變更，所以，查詢一次和查詢多次一樣的。 2.MVCC方案 多版本並發控制，update with condition，更新帶條件，這也是在系統設計的時候，合理的選擇樂觀鎖，通過version或者其他條件，來做樂觀鎖，這樣保證更新及時在並發的情況下，也不會有太大的問題。 例如：update table_xxx set name=#name#,version=version+1 where version=#version# ,或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。 3.單獨的去重表 如果涉及到的去重的地方特別多，例如ERP系統中有各種各樣的業務單據，每一種業務單據都需要去重，這時候，可以單獨搞一張去重表，在插入數據的時候，插入去重表，利用資料庫的唯一索引特性，保證唯一的邏輯。 4.分布式鎖 還是拿插入數據的例子，如果是分布是系統，構建唯一索引比較困難，例如唯一性的欄位沒法確定，這時候可以引入分布式鎖，通過第三方的系統，在業務系統插入數據或者更新數據，獲取分布式鎖，然後做操作，之後釋放鎖，這樣其實是把多線程並發的鎖的思路，引入多多個系統，也就是分布式系統中得解決思路。 5.刪除數據 刪除數據，僅僅第一次刪除是真正的操作數據，第二次甚至第三次刪除，直接返回成功，這樣保證了冪等。 6.插入數據的唯一索引 插入數據的唯一性，可以通過業務主鍵來進行約束，例如一個特定的業務場景，三個欄位肯定確定唯一性，那麼，可以在資料庫表添加唯一索引來進行標示。 這里有一個場景，API層面的冪等，例如提交數據，如何控制重復提交，這里可以在提交數據的form表單或者客戶端軟體，增加一個唯一標示，然後服務端，根據這個UUID來進行去重，這樣就能比較好的做到API層面的唯一標識。 7.狀態機冪等 在設計單據相關的業務，或者是任務相關的業務，肯定會涉及到狀態機，就是業務單據上面有個狀態，狀態在不同的情況下會發生變更，一般情況下存在有限狀態機，這時候，如果狀態機已經處於下一個狀態，這時候來了一個上一個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。 以上就是高並發系統數據冪等的解決方案的資料整理，後續繼續補充相關知識，謝謝大家對本站的支持！
Ⅲ 深入理解分布式事務，高並發下分布式事務的解決方案
1、什麼是分布式事務
分布式事務就是指事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。以上是網路的解釋，簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。本質上來說，分布式事務就是為了保證不同資料庫的數據一致性。
2、分布式事務的產生的原因
2.1、資料庫分庫分表
當資料庫單表一年產生的數據超過1000W，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的一個資料庫變成了多個資料庫。這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證數據的一致性，那麼就要用到分布式事務。
2.2、應用SOA化
所謂的SOA化，就是業務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對於訂單中心，有專門的資料庫存儲訂單信息，用戶中心也有專門的資料庫存儲用戶信息，庫存中心也會有專門的資料庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那麼就會涉及到訂單資料庫和庫存資料庫，為了保證數據一致性，就需要用到分布式事務。
以上兩種情況表象不同，但是本質相同，都是因為要操作的資料庫變多了！
3、事務的ACID特性
3.1、原子性（A）
所謂的原子性就是說，在整個事務中的所有操作，要麼全部完成，要麼全部不做，沒有中間狀態。對於事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。
3.2、一悔凱兄致性（C）
事務的執行必須保證系統的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那麼不管並發多少，不管發生什麼，只要事務執行成功了，那麼最後A賬戶一定是450元，B賬戶一定是350元。
3.3、隔離性（I）
所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態不會被其他事務感知。
3.4、持久性（D）
所謂的持久性，就是說一單事務完成了，那麼事務對數據所做的變更就完全保存在了資料庫中，即使發生停電，系統宕機也是如此。
4、分布式事務的應用場景
4.1、支付
最經典的場景就是支付了，一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務里執行，要麼全孫毀部成功，要麼全部失敗。而對於買家賬戶屬於買家中心，對應的是買家資料庫，而賣家賬戶屬於賣家中心，對應的是賣家資料庫，對不同資料庫的操作必然需要引入分布式事務。
4.2、在線下單
買家在電商平台下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態，庫存和訂單一般屬於不同的資料庫，需要使用分布式事務保證數據一致性。
5、常見的分布式事務解決方案
5.1、基於XA協議的兩階段提交
XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現，比如Oracle、DB2這些商業資料庫都實現了XA介面，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：
總的來說，XA協議比較簡單，而且一旦商業資料庫實現了XA協議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往並發量很高，XA無法滿足高並發場景。XA目前在商業資料庫支持的比較理想，在mysql資料庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日誌，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。
5.2、消息事務+最終一致性
所謂的消息事務就是基於消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發消息放在了一個分布式事務里，保證要麼本地操作成功成功並且對外發消息成功，要麼兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：
1、A系統向消息中間件發送一條預備消息
2、碧襲消息中間件保存預備消息並返回成功
3、A執行本地事務
4、A發送提交消息給消息中間件
通過以上4步完成了一個消息事務。對於以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：
步驟一出錯，則整個事務失敗，不會執行A的本地操作步驟二出錯，則整個事務失敗，不會執行A的本地操作步驟三出錯，這時候需要回滾預備消息，怎麼回滾？答案是A系統實現一個消息中間件的回調介面，消息中間件會去不斷執行回調介面，檢查A事務執行是否執行成功，如果失敗則回滾預備消息步驟四齣錯，這時候A的本地事務是成功的，那麼消息中間件要回滾A嗎？答案是不需要，其實通過回調介面，消息中間件能夠檢查到A執行成功了，這時候其實不需要A發提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務基於消息中間件的兩階段提交往往用在高並發場景下，將一個分布式事務拆成一個消息事務（A系統的本地操作+發消息）+B系統的本地操作，其中B系統的操作由消息驅動，只要消息事務成功，那麼A操作一定成功，消息也一定發出來了，這時候B會收到消息去執行本地操作，如果本地操作失敗，消息會重投，直到B操作成功，這樣就變相地實現了A與B的分布式事務。原理如下：
雖然上面的方案能夠完成A和B的操作，但是A和B並不是嚴格一致的，而是最終一致的，我們在這里犧牲了一致性，換來了性能的大幅度提升。當然，這種玩法也是有風險的，如果B一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。
5.3、TCC編程模式
所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。總之，TCC就是通過代碼人為實現了兩階段提交，不同的業務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式並不能很好地被復用。
6、總結
分布式事務，本質上是對多個資料庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務+最終一致性、TCC模式，而完全控制就是完全實現兩階段提交。部分控制的好處是並發量和性能很好，缺點是數據一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決於業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力