面一個(gè)5年java，不知數(shù)據(jù)結(jié)構(gòu)，卻大談分布式，這樣的能要嗎？我猜您向人們?cè)儐柫烁鞣NJDK數(shù)據(jù)結(jié)構(gòu)的基本實(shí)現(xiàn)原則。事實(shí)上，我一直在想。知道基本的實(shí)現(xiàn)原則是可以的，也是值得的，但是如果你不知道呢？人們知

面一個(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)。

如何使用消息隊(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ì)列。

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

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

1. 傳統(tǒng)的事務(wù)通常指數(shù)據(jù)庫事務(wù)，事務(wù)資源的強(qiáng)一致性保證了事務(wù)的一致性。在傳統(tǒng)的單一應(yīng)用中，由于事務(wù)資源在同一個(gè)應(yīng)用中，無法跨多個(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ù)