今天小編給大家分享一下如何理解Java分布式事務(wù)的相關(guān)知識點，內(nèi)容詳細(xì)，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

創(chuàng)新互聯(lián)建站專注于沈北新企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,商城網(wǎng)站開發(fā)。沈北新網(wǎng)站建設(shè)公司,為沈北新等地區(qū)提供建站服務(wù)。全流程定制網(wǎng)站建設(shè)，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)

如果一個事務(wù)調(diào)用了不同服務(wù)器上的操作，那么它就成為了一個分布式事務(wù)。

考慮下面一種場景：當(dāng)你發(fā)了工資之后，把你的當(dāng)月工資￥1024從支付寶轉(zhuǎn)到了余額寶。

如果在支付寶賬戶扣除￥1024之后，余額寶系統(tǒng)掛掉了，余額寶的賬戶并沒有增加￥1024，這時候就出現(xiàn)了數(shù)據(jù)不一致的情況。

在很多系統(tǒng)中都能找到上述情況的影子：

• 在下單的時候，需要在訂單表中插入一條數(shù)據(jù)，然后把庫存減去一

• 在搜索的時候如果點擊了廣告，需要先記錄該點擊事件，然后通知商家系統(tǒng)扣除廣告費

在一個分布式事務(wù)結(jié)束的時候，事務(wù)的原子特性要求所有參與該事務(wù)的服務(wù)器必須全部提交或全部放棄該事務(wù)。為了實現(xiàn)這一點，其中一個服務(wù)器承擔(dān)了協(xié)調(diào)者(coordinater)的角色，由它來保證所有的服務(wù)器獲得相同的結(jié)果。

協(xié)調(diào)者(coordinater)的工作方式取決于它選用的協(xié)議，“兩階段提交”是分布式事務(wù)最常用的協(xié)議。

1、two-phase commit protocol

兩階段提交協(xié)議(two-phase commit protocol)的設(shè)計出發(fā)點是允許任何一個參與者自行放棄它自己的那部分事務(wù)。由于事務(wù)原子性的要求，如果部分事務(wù)被放棄，那么整個分布式事務(wù)也必須被放棄。

在該協(xié)議的第一個階段，每個參與者投票表決該事務(wù)是放棄還是提交，一旦參與者要求提交事務(wù)，那么就不允許放棄該事務(wù)。因此，在一個參與者要求提交事務(wù)之前，它必須保證最終能夠執(zhí)行分布式事務(wù)中自己的那部分，即使該參與者出現(xiàn)故障而被中途替換掉。

一個事務(wù)的參與者如果最終能提交事務(wù)，那么可以說參與者處于事務(wù)的準(zhǔn)備好(prepared)狀態(tài)。為了保證能夠提交，每個參與者必須將事務(wù)中所有發(fā)生改變的對象以及自身的狀態(tài)(prepared)保存到持久性存儲中。

在該協(xié)議的第二個階段，事務(wù)的每個參與者執(zhí)行最終統(tǒng)一的決定。如果任何一個參與者投票放棄事務(wù)，那么最終的決定是放棄事務(wù)。如果所有的參與者都投票提交事務(wù)，那么最終的決定是提交事務(wù)。

問題在于，要保證每個參與者都投票，并且達(dá)成一個共同的決定。在無故障時，該協(xié)議相當(dāng)簡單。但是，協(xié)議必須在出現(xiàn)各種故障(例如服務(wù)器崩潰，消息丟失或服務(wù)暫時無法通信）時能夠正常工作。

2、兩階段提交的實現(xiàn)

為了實現(xiàn)兩階段提交協(xié)議，分布式事務(wù)中的協(xié)調(diào)者和參與者通常按照下面的接口進(jìn)行通信：

• canCommit(trans) ?

協(xié)調(diào)者詢問參與者是否可以提交事務(wù)，參與者回復(fù)自己的投票結(jié)果。

• doCommit(trans) 

協(xié)調(diào)者告訴參與者提交它的那部分事務(wù)。

• doAbort(trans) 

協(xié)調(diào)者告訴參與者放棄它的那部分事務(wù)。

• haveCommitted(trans, participant) 

參與者用該操作向協(xié)調(diào)者確認(rèn)它提交了事務(wù)。

• getDecision(trans) ?

當(dāng)參與者在投Yes票后一段時間內(nèi)未收到應(yīng)答時，參與者用該操作向協(xié)調(diào)者詢問事務(wù)的投票表決結(jié)果。該操作用于從服務(wù)器崩潰或從消息延遲中恢復(fù)。

階段一（投票階段）： 1）協(xié)調(diào)者向分布式事務(wù)的所有參與者發(fā)送canCommit？請求 2）當(dāng)參與者收到canCommit請求后，它向協(xié)調(diào)者回復(fù)自己的投票（Yes/No）。    在投Yes票之前，它在持久性存儲中保存所有對象，準(zhǔn)備提交。如果投No票，參與者立即放棄。 階段二（提交階段）： 1）協(xié)調(diào)者收集所有的投票（包括它自己的投票）。    a）如果不存在故障并且所有的投票都是Yes時，那么協(xié)調(diào)者將決定提交事務(wù)并向所有參與者發(fā)送doCommit       請求    b）否則，協(xié)調(diào)者決定放棄該事務(wù)，并向所有投Yes票的參與者發(fā)送doAbort請求 2）投Yes票的等待者等待協(xié)調(diào)者發(fā)送的doCommit或者doAbort請求。一旦參與者接收到任何一種請求消息，    它將根據(jù)該請求放棄或者提交事務(wù)。如果請求是提交事務(wù)，那么他還要向協(xié)調(diào)者發(fā)送一個haveCommitted    來確認(rèn)事務(wù)已經(jīng)提交

3、分布式事務(wù)的故障模型

在分布式事務(wù)中執(zhí)行的過程中，可能出現(xiàn)磁盤故障，進(jìn)程崩潰以及消息的丟失，超時等。

兩階段提交是一種達(dá)成共識的協(xié)議，在該系統(tǒng)中，如果進(jìn)程崩潰，那么是不可能達(dá)成共識的。但是，兩階段提交卻是在這些條件下達(dá)成了共識，這是由于進(jìn)程的崩潰被屏蔽，崩潰的進(jìn)程被一個新的進(jìn)程取代，新進(jìn)程的狀態(tài)根據(jù)持久性存儲中保存的信息和其他進(jìn)程擁有的信息來設(shè)定。

3.1、故障模型

Lampson提出過一個分布式事務(wù)的故障模型，包括了硬盤故障、服務(wù)器故障以及通信故障。該故障模型聲稱：可以保證算法在出現(xiàn)故障時正確工作，但是對于不可預(yù)見的災(zāi)難性故障則不能正確處理。盡管會出現(xiàn)錯誤，但是可以在發(fā)生不正確行為之前發(fā)現(xiàn)并處理這些錯誤。Lampson的故障模型包括以下故障：

• 對持久性存儲的寫操作可能發(fā)生故障（或因為寫操作無效或因為寫入錯誤的值）。例如，將數(shù)據(jù)寫到錯誤的磁盤塊被認(rèn)為是災(zāi)難性故障。文件存儲可能損壞。在持久性存儲中讀數(shù)據(jù)時可根據(jù)校驗和來判斷數(shù)據(jù)塊是否損壞。

• 服務(wù)器可能偶爾崩潰。當(dāng)一個崩潰的服務(wù)器由一個新進(jìn)程取代后，它的可變內(nèi)存被重置，崩潰之前的數(shù)據(jù)均丟失。此后新進(jìn)程執(zhí)行一個可恢復(fù)過程，根據(jù)持久存儲中的信息以及從其他進(jìn)程獲得的信息設(shè)置對象的值，包括兩階段提交協(xié)議有關(guān)對象的值。當(dāng)一個處理器出現(xiàn)故障時，服務(wù)器也會崩潰，這樣它就不會發(fā)送錯誤的信息或?qū)㈠e誤的值寫入持久存儲，即它不會產(chǎn)生隨機(jī)故障。服務(wù)器崩潰可能出現(xiàn)在任何時候，特別是在恢復(fù)時也可能出現(xiàn)。

• 消息傳遞可能有任意長的延遲。消息可能丟失、重復(fù)或者損壞。接收方（通過校驗和）能夠檢測到受損消息。未發(fā)現(xiàn)的受損消息和偽造的消息可能會導(dǎo)致災(zāi)難性故障。

利用這個關(guān)于持久性存儲、處理器和通信的故障模型能夠設(shè)計出一個可靠系統(tǒng)，該系統(tǒng)的組件可對付任何單一故障，并提供一個簡單的故障模型。特別是，可靠存儲(stable storage)可以在出現(xiàn)一個write操作故障或者進(jìn)程崩潰的情況下提供原子寫操作。它是通過將每一個數(shù)據(jù)塊復(fù)制到兩個磁盤上實現(xiàn)的。此時一個write操作用于兩個磁盤塊，在一個磁盤出現(xiàn)故障的前提下，另一個好的磁盤也可以提供正確數(shù)據(jù)?？煽刻幚砥?stable processor)使用可靠存儲，用于在崩潰之后恢復(fù)對象?？赏ㄟ^可靠的遠(yuǎn)程過程調(diào)用機(jī)制來屏蔽通信錯誤。

3.2、兩階段提交協(xié)議的超時

在兩階段協(xié)議的不同階段，協(xié)調(diào)者或參與者都會遇到這種場景：不能處理它的那部分協(xié)議，直到接收到下一個請求或應(yīng)答為止。

首先考慮這樣的情形：某個投票者投Yes票并等待協(xié)調(diào)者發(fā)回最終決定，即告訴它是提交事務(wù)還是放棄事務(wù)。這樣參與者的結(jié)果是不確定(uncertain)的，它在協(xié)調(diào)者處得到投票結(jié)果之前不能進(jìn)行進(jìn)一步處理。參與者不能單方面決定下一步做什么，同時該事務(wù)使用的對象也不能釋放以用于其他事物。參與者向協(xié)調(diào)者發(fā)出getDecision請求來獲取事務(wù)的結(jié)果，直到收到應(yīng)答時，才能進(jìn)入兩階段協(xié)議的第二階段。

同理，如果協(xié)調(diào)者發(fā)生故障，那么參與者將不能獲得協(xié)定，直到協(xié)調(diào)者被替代為止，這可能導(dǎo)致不確定狀態(tài)的參與者長時間的延遲。

不依賴協(xié)調(diào)者獲取最終決定的方法是通過參與者協(xié)作來獲得決定。這種策略的優(yōu)點是可以在協(xié)調(diào)者出故障時使用。

4、兩階段提交的故障處理

• 當(dāng)參與者發(fā)生故障的時候：

• 當(dāng)協(xié)調(diào)者發(fā)生故障的時候：

5、兩階段提交的性能

假設(shè)一切運(yùn)轉(zhuǎn)正常，即協(xié)調(diào)者參與者不出現(xiàn)故障，通信也正常時，有N個參與者的兩階段提交協(xié)議需要N個canCommit消息和應(yīng)答，然后再有N個doCommit消息。這樣消息開銷和3N成正比，時間開銷是3次消息往返。由于協(xié)議在沒有haveCommitted消息時仍可以正常運(yùn)作（它們的作用只是通知服務(wù)器刪除過時的協(xié)調(diào)者消息），因此在估計協(xié)議開銷上，不將haveCommitted消息計算在內(nèi)。

在最壞的情況下，兩階段提交協(xié)議在執(zhí)行過程中可能出現(xiàn)任意多次服務(wù)器和通信故障。盡管協(xié)議不能指定協(xié)議完成的時間限制，但它能正確處理連續(xù)故障（服務(wù)崩潰或者消息丟失），并保證最終完成。

6、使用消息隊列來避免分布式事務(wù)

5.1、消息隊列

由于分布式事務(wù)存在嚴(yán)重的性能問題，在設(shè)計高并發(fā)服務(wù)的時候，往往通過其他途徑來解決數(shù)據(jù)一致性問題。

舉例來講，你在北京很有名的姚記炒肝點了炒肝并付了錢后，他們并不會直接把你點的炒肝給你，而是給你一張小票，然后讓你拿著小票到出貨區(qū)排隊去取。為什么他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強(qiáng)（并發(fā)量更高）。

還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉(zhuǎn)賬服務(wù)也是如此，當(dāng)支付寶賬戶扣除1萬后，我們只要生成一個憑證（消息）即可，這個憑證（消息）上寫著“讓余額寶賬戶增加 1萬”，只要這個憑證（消息）能可靠保存，我們最終是可以拿著這個憑證（消息）讓余額寶賬戶增加1萬的，即我們能依靠這個憑證（消息）完成最終一致性。

這樣我們上述的轉(zhuǎn)賬就變成了如下過程：

• 支付寶在扣款事務(wù)提交之前，向消息隊列發(fā)送消息。此時的消息隊列只記錄消息，而并沒有將消息發(fā)往余額寶。

• 當(dāng)支付寶扣款事務(wù)提交成功，向消息隊列發(fā)送確認(rèn)。在得到確認(rèn)的指令后，消息隊列向該消息發(fā)往余額寶。

• 當(dāng)支付寶扣款事務(wù)提交失敗，向消息隊列發(fā)送取消。在得到取消的指令后，消息隊列取消該消息，該消息將不會被發(fā)送。

• 對于那么未確認(rèn)的消息，需要消息隊列去支付寶系統(tǒng)查詢這個消息的狀態(tài)，并進(jìn)行更新。（因為支付寶可能在扣款事務(wù)提交成功后掛掉，此時消息的狀態(tài)未被更新為：“確認(rèn)發(fā)送“。從而導(dǎo)致消息不能被發(fā)送。

5.2、重復(fù)投遞

還有一個嚴(yán)重的問題是消息重復(fù)投遞，以我們支付寶轉(zhuǎn)賬到余額寶為例，如果相同的消息被重復(fù)投遞兩次，那么我們余額寶賬戶將會增加2萬而不是1萬了。

以上就是“如何理解Java分布式事務(wù)”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學(xué)習(xí)更多的知識，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

分享名稱：如何理解Java分布式事務(wù)
本文路徑：http://chinadenli.net/article10/joisdo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站營銷、品牌網(wǎng)站制作、響應(yīng)式網(wǎng)站、營銷型網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)