如何使用消息隊(duì)列解決分布式事務(wù)？有兩種選擇。Scheme 1 Local message transaction table生產(chǎn)者需要添加一個(gè)事務(wù)消息表。具體步驟如下：[1。生產(chǎn)者執(zhí)行業(yè)務(wù)邏輯并將事務(wù)

如何使用消息隊(duì)列解決分布式事務(wù)？

有兩種選擇。

Scheme 1 Local message transaction table

生產(chǎn)者需要添加一個(gè)事務(wù)消息表。具體步驟如下：[1。生產(chǎn)者執(zhí)行業(yè)務(wù)邏輯并將事務(wù)記錄插入到消息表中。這兩個(gè)操作在一個(gè)本地事務(wù)中

2。啟動(dòng)后臺(tái)線程定期輪詢消息表并將消息發(fā)送到消息隊(duì)列

3。刪除消息表中的消息，直到發(fā)送成功。

方案2需要消息隊(duì)列支持，業(yè)務(wù)端提供回溯接口

1。生產(chǎn)端將準(zhǔn)備好的消息發(fā)送到消息隊(duì)列

2。在本地事務(wù)中，業(yè)務(wù)邏輯

3。根據(jù)執(zhí)行結(jié)果確認(rèn)或取消準(zhǔn)備好的消息

4。消息隊(duì)列將確保準(zhǔn)備好的消息被確認(rèn)或取消，并且消息隊(duì)列將不斷地向生產(chǎn)端請(qǐng)求執(zhí)行結(jié)果，這要求生產(chǎn)端提供類似的回調(diào)函數(shù)。

在方案2中，消息隊(duì)列取代了方案1中的消息表和后臺(tái)線程輪詢功能，但并非所有消息隊(duì)列都支持此功能。支持Rocketmq。

方案1的開發(fā)工作量大，外部依賴性小

方案2的開發(fā)工作量小，但依賴于特定的消息隊(duì)列。

微服務(wù)調(diào)用為啥用RPC框架，http不更簡(jiǎn)單嗎？

簡(jiǎn)單一點(diǎn)，HTTP是協(xié)議，RPC是概念！RPC可以基于HTTP協(xié)議（feign）、TCP協(xié)議（netty）、RMI協(xié)議（soap）和web服務(wù)（XML-RPC）框架實(shí)現(xiàn)。在傳輸過程中，由于序列化方法的不同，也出現(xiàn)了一些框架和協(xié)議，如Dubbo中的Dubbo協(xié)議、grpc protobuf序列化協(xié)議等。實(shí)際上，它們都是基于遠(yuǎn)程調(diào)用的概念。什么是遠(yuǎn)程呼叫？

關(guān)鍵是RPC是遠(yuǎn)程調(diào)用。遠(yuǎn)程調(diào)用是客戶端通過上述協(xié)議向服務(wù)器發(fā)送接口、參數(shù)、參數(shù)類型、方法、返回值、返回值類型等（稱為方法簽名），通知服務(wù)器要調(diào)用的接口方法。這個(gè)過程就是RPC的實(shí)現(xiàn)過程！HTTP和RPC是兩碼事

！在性能方面，HTTP本身是基于TCP協(xié)議的，屬于應(yīng)用層協(xié)議，所以HTTP協(xié)議本身在實(shí)現(xiàn)過程中會(huì)占用大量的資源（內(nèi)存、帶寬等）。在性能方面，它肯定不如直接通過TCP實(shí)現(xiàn)的RPC協(xié)議快。不管HTTP有多優(yōu)化，它絕對(duì)沒有TCP那么快！另一方面，TCP依賴于字節(jié)碼。目前常用的是將客戶端調(diào)用的接口信息以序列化的方式發(fā)送到服務(wù)器端。序列化框架包括許多內(nèi)容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字節(jié)碼）。序列化后的字節(jié)碼越小，占用的帶寬越小，序列化時(shí)間越長(zhǎng)，線程IO延遲越短，線程IO延遲越小。因此，在具體的應(yīng)用層，有很多技術(shù)可以討論。您可以根據(jù)自己的硬件能力選擇相應(yīng)的技術(shù)

！歡迎熱愛科技的人們來探索

面一個(gè)5年java，不知數(shù)據(jù)結(jié)構(gòu)，卻大談分布式，這樣的能要嗎？

我猜您向人們?cè)儐柫烁鞣NJDK數(shù)據(jù)結(jié)構(gòu)的基本實(shí)現(xiàn)原則。事實(shí)上，我一直在想。知道基本的實(shí)現(xiàn)原則是可以的，也是值得的，但是如果你不知道呢？人們知道哪些數(shù)據(jù)結(jié)構(gòu)適用于哪些場(chǎng)景，并且能夠熟練地使用它們。那不是。。。夠了嗎？對(duì)貴公司的需求不足嗎？你希望他為你的公司創(chuàng)建一個(gè)新的數(shù)據(jù)結(jié)構(gòu)嗎？就像two peas或JDK一樣，JDK的數(shù)據(jù)結(jié)構(gòu)性能遇到了瓶頸，求職者會(huì)給你提供比工作提供的數(shù)據(jù)結(jié)構(gòu)更好的數(shù)據(jù)結(jié)構(gòu)。

傳統(tǒng)事務(wù)為什么解決不了分布式事務(wù)？

其根本原因是傳統(tǒng)事務(wù)只能解決單個(gè)事務(wù)資源的問題，而分布式事務(wù)則考慮了多個(gè)事務(wù)資源的問題。這兩種場(chǎng)景是不同的，傳統(tǒng)的事務(wù)無(wú)法解決分布式事務(wù)的問題。

1. 傳統(tǒng)的事務(wù)通常指數(shù)據(jù)庫(kù)事務(wù)，事務(wù)資源的強(qiáng)一致性保證了事務(wù)的一致性。在傳統(tǒng)的單一應(yīng)用中，由于事務(wù)資源在同一個(gè)應(yīng)用中，無(wú)法跨多個(gè)事務(wù)資源調(diào)用，因此可以高效工作；

，只需要保證數(shù)據(jù)的“最終一致性”，但最終時(shí)間需要在用戶可接受的范圍內(nèi)；但在金融關(guān)聯(lián)交易領(lǐng)域，仍然需要采用強(qiáng)一致性的方法來保證交易的準(zhǔn)確性和可靠性。

3. 目前，分布式事務(wù)常用的解決方案有：兩階段提交、三階段提交、sagas長(zhǎng)事務(wù)、補(bǔ)償模式、可靠事件模式（本地事件表、外部事件表）、可靠事件模式（非事務(wù)消息、事務(wù)消息），TCC等

不同實(shí)現(xiàn)的優(yōu)缺點(diǎn)如下圖所示：

科普知識(shí)@大象聊天技術(shù)