了解什么是分布式事務(wù)問題

分布式事務(wù)是指涉及多個獨立的計算機系統(tǒng)（也稱為節(jié)點或參與者）之間的事務(wù)處理。在分布式系統(tǒng)中，每個節(jié)點可能各自擁有自己的數(shù)據(jù)存儲和事務(wù)管理機制。分布式事務(wù)的目標(biāo)是保證在跨多個節(jié)點執(zhí)行的一系列操作可以以一致和可靠的方式執(zhí)行和提交，即使在面對故障或并發(fā)操作時也能保持?jǐn)?shù)據(jù)的完整性和一致性。

分布式事務(wù)通常包括以下四個關(guān)鍵屬性：

1. 原子性（Atomicity）：要么所有的操作都成功執(zhí)行并提交，要么所有的操作都回滾，保證所有節(jié)點的數(shù)據(jù)狀態(tài)一致。
2. 一致性（Consistency）：事務(wù)執(zhí)行前和執(zhí)行后系統(tǒng)的狀態(tài)保持一致。
3. 隔離性（Isolation）：事務(wù)在執(zhí)行期間對其他事務(wù)是隔離的，即每個事務(wù)都感覺不到其他事務(wù)的存在。
4. 持久性（Durability）：一旦事務(wù)提交，其結(jié)果必須永久存儲，即使在系統(tǒng)故障的情況下也能恢復(fù)。

實現(xiàn)分布式事務(wù)可以采用兩階段提交（Two-Phase Commit）協(xié)議或三階段提交（Three-Phase Commit）協(xié)議等機制。這些協(xié)議通過協(xié)調(diào)參與者之間的狀態(tài)和決策來實現(xiàn)分布式事務(wù)的一致性。然而，由于分布式事務(wù)需要跨越網(wǎng)絡(luò)和多個節(jié)點進行通信和協(xié)調(diào)，因此可能會面臨性能和可靠性等挑戰(zhàn)。

舉例說明：
當(dāng)服務(wù)A通過restTemplate調(diào)用服務(wù)B的接口，服務(wù)A會持久化數(shù)據(jù)到A數(shù)據(jù)庫，而服務(wù)B會持久化數(shù)據(jù)到數(shù)據(jù)庫B，那么如果這個時候數(shù)據(jù)傳輸中間出現(xiàn)了問題，數(shù)據(jù)庫A出現(xiàn)了持久化，而服務(wù)B持久化失敗執(zhí)行了回滾，但是數(shù)據(jù)庫A是無法進行事務(wù)的回滾了，這個時候可能就會造成臟數(shù)據(jù)了

通過RabbitMQ來解決分布式事務(wù)問題

MQ解決分布式事務(wù)問題

可靠生產(chǎn)

主要是通過一張冗余表和定時任務(wù)解決了可靠生產(chǎn)的問題

在本地數(shù)據(jù)庫中創(chuàng)建一張冗余表
（1）如果消息可以正常發(fā)送到MQ，并且MQ給與了確認(rèn)消息，那么這條數(shù)據(jù)會在冗余表中設(shè)置status為1；
（2）如果MQ此時宕機，那么這條數(shù)據(jù)就會存儲到冗余表中，設(shè)置狀態(tài)碼為0（默認(rèn)狀態(tài)），會創(chuàng)建一個定時任務(wù)，定時將冗余的消息再發(fā)送到MQ中；
（3）如果發(fā)送次數(shù)超過兩會，也就是status字段為2，那么就會判斷是消息出現(xiàn)了問題，然后通知人工來排查問題所在

可靠消費

1.首先創(chuàng)建一個消費者，監(jiān)聽隊列中的消息

2.如果消費者在消費消息的時候，出現(xiàn)了異常（代碼中默認(rèn)設(shè)置的是1/0的異常），那么就會觸發(fā)MQ的重試機制，會導(dǎo)致死循環(huán)。解決消息重試的幾種方案：（面試常問）
（1）控制重發(fā)的次數(shù)
在配置文件中進行相關(guān)重試次數(shù)的配置，如果達(dá)到了最大的重試次數(shù)，會把這條消息在隊列中移除！
如果我們在配置文件中沒有開啟手動ack，使用默認(rèn)的自動ack，那么會存在消息丟失的情況，一般不會使用這種方法

（2）try + catch + 手動ack
①第一步首先要在yaml配置文件開啟手動ack，這樣消息在出現(xiàn)異常，甚至是超過重試次數(shù)的時候就不會被移除，我們還能將這條消息轉(zhuǎn)移到死信隊列中！

②在消費者消費消息的業(yè)務(wù)代碼中，在catch中設(shè)置ack
調(diào)用basicNack方法，參數(shù)requeue，如果設(shè)置成false，那么消息如果消異常，就會將他轉(zhuǎn)移到死信隊列中，如果設(shè)置成true，那么就會將這條消息移除掉

（3）try + catch + 手動ack + 死信隊列處理 + 人工干預(yù)
①在上面開啟手動ack的基礎(chǔ)上，創(chuàng)建死信交換機和死信隊列，綁定到接收消息的隊列中，如果消息出現(xiàn)異常，那么就會將消息轉(zhuǎn)移到死信隊列中

②創(chuàng)建一個新的消費者來監(jiān)聽死信隊列，這個消費者中的業(yè)務(wù)邏輯就不能包含處理異常消息的代碼了，一般到了監(jiān)聽死信隊列的情況下，再往后就得需要人工干預(yù)了！

③還需要考慮數(shù)據(jù)的冪等性，就是要保證數(shù)據(jù)在數(shù)據(jù)庫中不被重復(fù)添加
直接把訂單號設(shè)置成主鍵，這樣主鍵就一定是唯一的啦！
或者是使用分布式鎖！

至此，關(guān)于RabbitMQ解決分布式事務(wù)的問題介紹完畢，后續(xù)還會持續(xù)更新相關(guān)技術(shù)點，敬請期待~~~文章來源地址http://www.zghlxwxcb.cn/news/detail-856402.html

到了這里，關(guān)于RabbitMQ——解決分布式事務(wù)問題，RabbitMQ的重要作用之一！??！通過可靠生產(chǎn)和可靠消費來完美解決！的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！