分布式事務(wù)中的三種解決方案詳解-創(chuàng)新互聯(lián)

[TOC]

成都一家集口碑和實(shí)力的網(wǎng)站建設(shè)服務(wù)商，擁有專業(yè)的企業(yè)建站團(tuán)隊(duì)和靠譜的建站技術(shù)，10年企業(yè)及個(gè)人網(wǎng)站建設(shè)經(jīng)驗(yàn) ,為成都上千客戶提供網(wǎng)頁(yè)設(shè)計(jì)制作,網(wǎng)站開發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營(yíng)銷型網(wǎng)站建設(shè)，高端網(wǎng)站設(shè)計(jì)，同時(shí)也為不同行業(yè)的客戶提供成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選創(chuàng)新互聯(lián)。

一、分布式事務(wù)前奏

  • 事務(wù)：事務(wù)是由一組操作構(gòu)成的可靠的獨(dú)立的工作單元，事務(wù)具備ACID的特性，即原子性、一致性、隔離性和持久性。
  • 本地事務(wù)：當(dāng)事務(wù)由資源管理器本地管理時(shí)被稱作本地事務(wù)。本地事務(wù)的優(yōu)點(diǎn)就是支持嚴(yán)格的ACID特性，高效，可靠，狀態(tài)可以只在資源管理器中維護(hù)，而且應(yīng)用編程模型簡(jiǎn)單。但是本地事務(wù)不具備分布式事務(wù)的處理能力，隔離的最小單位受限于資源管理器。
  • 全局事務(wù)：當(dāng)事務(wù)由全局事務(wù)管理器進(jìn)行全局管理時(shí)成為全局事務(wù)，事務(wù)管理器負(fù)責(zé)管理全局的事務(wù)狀態(tài)和參與的資源，協(xié)同資源的一致提交回滾。
  • TX協(xié)議：應(yīng)用或者應(yīng)用服務(wù)器與事務(wù)管理器的接口。
  • XA協(xié)議：全局事務(wù)管理器與資源管理器的接口。XA是由X/Open組織提出的分布式事務(wù)規(guī)范。該規(guī)范主要定義了全局事務(wù)管理器和局部資源管理器之間的接口。主流的數(shù)據(jù)庫(kù)產(chǎn)品都實(shí)現(xiàn)了XA接口。XA接口是一個(gè)雙向的系統(tǒng)接口，在事務(wù)管理器以及多個(gè)資源管理器之間作為通信橋梁。之所以需要XA是因?yàn)樵诜植际较到y(tǒng)中從理論上講兩臺(tái)機(jī)器是無(wú)法達(dá)到一致性狀態(tài)的，因此引入一個(gè)單點(diǎn)進(jìn)行協(xié)調(diào)。由全局事務(wù)管理器管理和協(xié)調(diào)的事務(wù)可以跨越多個(gè)資源和進(jìn)程。全局事務(wù)管理器一般使用XA二階段協(xié)議與數(shù)據(jù)庫(kù)進(jìn)行交互。
  • AP：應(yīng)用程序，可以理解為使用DTP（Data Tools Platform）的程序。
  • RM：資源管理器，這里可以是一個(gè)DBMS或者消息服務(wù)器管理系統(tǒng)，應(yīng)用程序通過(guò)資源管理器對(duì)資源進(jìn)行控制，資源必須實(shí)現(xiàn)XA定義的接口。資源管理器負(fù)責(zé)控制和管理實(shí)際的資源。
  • TM：事務(wù)管理器，負(fù)責(zé)協(xié)調(diào)和管理事務(wù)，提供給AP編程接口以及管理資源管理器。事務(wù)管理器控制著全局事務(wù)，管理事務(wù)的生命周期，并且協(xié)調(diào)資源。
  • 兩階段提交協(xié)議：XA用于在全局事務(wù)中協(xié)調(diào)多個(gè)資源的機(jī)制。TM和RM之間采取兩階段提交的方案來(lái)解決一致性問(wèn)題。兩節(jié)點(diǎn)提交需要一個(gè)協(xié)調(diào)者（TM）來(lái)掌控所有參與者（RM）節(jié)點(diǎn)的操作結(jié)果并且指引這些節(jié)點(diǎn)是否需要最終提交。兩階段提交的局限在于協(xié)議成本，準(zhǔn)備階段的持久成本，全局事務(wù)狀態(tài)的持久成本，潛在故障點(diǎn)多帶來(lái)的脆弱性，準(zhǔn)備后，提交前的故障引發(fā)一系列隔離與恢復(fù)難題。
  • BASE理論：BA指的是基本業(yè)務(wù)可用性，支持分區(qū)失敗，S表示柔性狀態(tài)，也就是允許短時(shí)間內(nèi)不同步，E表示最終一致性，數(shù)據(jù)最終是一致的，但是實(shí)時(shí)是不一致的。原子性和持久性必須從根本上保障，為了可用性、性能和服務(wù)降級(jí)的需要，只有降低一致性和隔離性的要求。
  • CAP定理：對(duì)于共享數(shù)據(jù)系統(tǒng)，最多只能同時(shí)擁有CAP其中的兩個(gè)，任意兩個(gè)都有其適應(yīng)的場(chǎng)景，真是的業(yè)務(wù)系統(tǒng)中通常是ACID與CAP的混合體。分布式系統(tǒng)中最重要的是滿足業(yè)務(wù)需求，而不是追求高度抽象，絕對(duì)的系統(tǒng)特性。C表示一致性，也就是所有用戶看到的數(shù)據(jù)是一樣的。A表示可用性，是指總能找到一個(gè)可用的數(shù)據(jù)副本。P表示分區(qū)容錯(cuò)性，能夠容忍網(wǎng)絡(luò)中斷等故障。
  • 柔性事務(wù)中的服務(wù)模式：
    1. 可查詢操作：服務(wù)操作具有全局唯一的標(biāo)識(shí)，操作唯一的確定的時(shí)間。
    2. 冪等操作：重復(fù)調(diào)用多次產(chǎn)生的業(yè)務(wù)結(jié)果與調(diào)用一次產(chǎn)生的結(jié)果相同。一是通過(guò)業(yè)務(wù)操作實(shí)現(xiàn)冪等性，二是系統(tǒng)緩存所有請(qǐng)求與處理的結(jié)果，最后是檢測(cè)到重復(fù)請(qǐng)求之后，自動(dòng)返回之前的處理結(jié)果。
    3. TCC操作：Try階段，嘗試執(zhí)行業(yè)務(wù)，完成所有業(yè)務(wù)的檢查，實(shí)現(xiàn)一致性；預(yù)留必須的業(yè)務(wù)資源，實(shí)現(xiàn)準(zhǔn)隔離性。Confirm階段：真正的去執(zhí)行業(yè)務(wù)，不做任何檢查，僅適用Try階段預(yù)留的業(yè)務(wù)資源，Confirm操作還要滿足冪等性。Cancel階段：取消執(zhí)行業(yè)務(wù)，釋放Try階段預(yù)留的業(yè)務(wù)資源，Cancel操作要滿足冪等性。TCC與2PC(兩階段提交)協(xié)議的區(qū)別：TCC位于業(yè)務(wù)服務(wù)層而不是資源層，TCC沒(méi)有單獨(dú)準(zhǔn)備階段，Try操作兼?zhèn)滟Y源操作與準(zhǔn)備的能力，TCC中Try操作可以靈活的選擇業(yè)務(wù)資源，鎖定粒度。TCC的開發(fā)成本比2PC高。實(shí)際上TCC也屬于兩階段操作，但是TCC不等同于2PC操作。
    4. 可補(bǔ)償操作：Do階段：真正的執(zhí)行業(yè)務(wù)處理，業(yè)務(wù)處理結(jié)果外部可見(jiàn)。Compensate階段：抵消或者部分撤銷正向業(yè)務(wù)操作的業(yè)務(wù)結(jié)果，補(bǔ)償操作滿足冪等性。約束：補(bǔ)償操作在業(yè)務(wù)上可行，由于業(yè)務(wù)執(zhí)行結(jié)果未隔離或者補(bǔ)償不完整帶來(lái)的風(fēng)險(xiǎn)與成本可控。實(shí)際上，TCC的Confirm和Cancel操作可以看做是補(bǔ)償操作。

二、柔性事務(wù)解決方案架構(gòu)

在電商領(lǐng)域等互聯(lián)網(wǎng)場(chǎng)景下，傳統(tǒng)的事務(wù)在數(shù)據(jù)庫(kù)性能和處理能力上都暴露出了瓶頸。柔性事務(wù)有兩個(gè)特性：基本可用和柔性狀態(tài)。所謂基本可用是指分布式系統(tǒng)出現(xiàn)故障的時(shí)候允許損失一部分的可用性。柔性狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，這個(gè)中間狀態(tài)不會(huì)影響系統(tǒng)整體的可用性，比如數(shù)據(jù)庫(kù)讀寫分離的主從同步延遲等。柔性事務(wù)的一致性指的是最終一致性。

（一）、基于可靠消息的最終一致性方案概述

分布式事務(wù)中的三種解決方案詳解

  • 實(shí)現(xiàn)：業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交之前，向?qū)崟r(shí)消息服務(wù)請(qǐng)求發(fā)送消息，實(shí)時(shí)消息服務(wù)只記錄消息數(shù)據(jù)，而不是真正的發(fā)送。業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)提交之后，向?qū)崟r(shí)消息服務(wù)確認(rèn)發(fā)送。只有在得到確認(rèn)發(fā)送指令后，實(shí)時(shí)消息服務(wù)才會(huì)真正發(fā)送。
  • 消息：業(yè)務(wù)處理服務(wù)在業(yè)務(wù)事務(wù)回滾后，向?qū)崟r(shí)消息服務(wù)取消發(fā)送。消息發(fā)送狀態(tài)確認(rèn)系統(tǒng)定期找到未確認(rèn)發(fā)送或者回滾發(fā)送的消息，向業(yè)務(wù)處理服務(wù)詢問(wèn)消息狀態(tài)，業(yè)務(wù)處理服務(wù)根據(jù)消息ID或者消息內(nèi)容確認(rèn)該消息是否有效。被動(dòng)方的處理結(jié)果不會(huì)影響主動(dòng)方的處理結(jié)果，被動(dòng)方的消息處理操作是冪等操作。
  • 成本：可靠的消息系統(tǒng)建設(shè)成本，一次消息發(fā)送需要兩次請(qǐng)求，業(yè)務(wù)處理服務(wù)需要實(shí)現(xiàn)消息狀態(tài)回查接口。
  • 優(yōu)點(diǎn)：消息數(shù)據(jù)獨(dú)立存儲(chǔ)，獨(dú)立伸縮，降低業(yè)務(wù)系統(tǒng)和消息系統(tǒng)之間的耦合。對(duì)最終一致性時(shí)間敏感度較高，降低業(yè)務(wù)被動(dòng)方的實(shí)現(xiàn)成本。兼容所有實(shí)現(xiàn)JMS標(biāo)準(zhǔn)的MQ中間件，確保業(yè)務(wù)數(shù)據(jù)可靠的前提下，實(shí)現(xiàn)業(yè)務(wù)的最終一致性，理想狀態(tài)下是準(zhǔn)實(shí)時(shí)的一致性。

（二）、TCC事務(wù)補(bǔ)償型方案

分布式事務(wù)中的三種解決方案詳解

  • 實(shí)現(xiàn)：一個(gè)完整的業(yè)務(wù)活動(dòng)由一個(gè)主業(yè)務(wù)服務(wù)于若干的從業(yè)務(wù)服務(wù)組成。主業(yè)務(wù)服務(wù)負(fù)責(zé)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng)。從業(yè)務(wù)服務(wù)提供TCC型業(yè)務(wù)操作。業(yè)務(wù)活動(dòng)管理器控制業(yè)務(wù)活動(dòng)的一致性，它登記業(yè)務(wù)活動(dòng)的操作，并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型操作的Confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的Cancel操作。
  • 成本：實(shí)現(xiàn)TCC操作的成本較高，業(yè)務(wù)活動(dòng)結(jié)束的時(shí)候Confirm和Cancel操作的執(zhí)行成本。業(yè)務(wù)活動(dòng)的日志成本。
  • 使用范圍：強(qiáng)隔離性，嚴(yán)格一致性要求的業(yè)務(wù)活動(dòng)。適用于執(zhí)行時(shí)間較短的業(yè)務(wù)，比如處理賬戶或者收費(fèi)等等。
  • 特點(diǎn)：不與具體的服務(wù)框架耦合，位于業(yè)務(wù)服務(wù)層，而不是資源層，可以靈活的選擇業(yè)務(wù)資源的鎖定粒度。TCC里對(duì)每個(gè)服務(wù)資源操作的是本地事務(wù)，數(shù)據(jù)被鎖住的時(shí)間短，可擴(kuò)展性好，可以說(shuō)是為獨(dú)立部署的SOA服務(wù)而設(shè)計(jì)的。

（三）、大努力通知型

分布式事務(wù)中的三種解決方案詳解

  • 實(shí)現(xiàn)：業(yè)務(wù)活動(dòng)的主動(dòng)方在完成處理之后向業(yè)務(wù)活動(dòng)的被動(dòng)方發(fā)送消息，允許消息丟失。業(yè)務(wù)活動(dòng)的被動(dòng)方根據(jù)定時(shí)策略，向業(yè)務(wù)活動(dòng)的主動(dòng)方查詢，恢復(fù)丟失的業(yè)務(wù)消息。
  • 約束：被動(dòng)方的處理結(jié)果不影響主動(dòng)方的處理結(jié)果。
  • 成本：業(yè)務(wù)查詢與校對(duì)系統(tǒng)的建設(shè)成本。
  • 使用范圍：對(duì)業(yè)務(wù)最終一致性的時(shí)間敏感度低。跨企業(yè)的業(yè)務(wù)活動(dòng)。
  • 特點(diǎn)：業(yè)務(wù)活動(dòng)的主動(dòng)方在完成業(yè)務(wù)處理之后，向業(yè)務(wù)活動(dòng)的被動(dòng)方發(fā)送通知消息。主動(dòng)方可以設(shè)置時(shí)間階梯通知規(guī)則，在通知失敗后按規(guī)則重復(fù)通知，知道通知N次后不再通知。主動(dòng)方提供校對(duì)查詢接口給被動(dòng)方按需校對(duì)查詢，用戶恢復(fù)丟失的業(yè)務(wù)消息。
  • 適用范圍：銀行通知，商戶通知。

三、基于可靠消息的最終一致性方案詳解

（一）、消息發(fā)送一致性

消息中間件在分布式系統(tǒng)中的核心作用就是異步通訊、應(yīng)用解耦和并發(fā)緩沖（也叫作流量削峰）。在分布式環(huán)境下，需要通過(guò)網(wǎng)絡(luò)進(jìn)行通訊，就引入了數(shù)據(jù)傳輸?shù)牟淮_定性，也就是CAP理論中的分區(qū)容錯(cuò)性。

分布式事務(wù)中的三種解決方案詳解

消息發(fā)送一致性是指產(chǎn)生消息的業(yè)務(wù)動(dòng)作與消息發(fā)送一致，也就是說(shuō)如果業(yè)務(wù)操作成功，那么由這個(gè)業(yè)務(wù)操作所產(chǎn)生的消息一定要發(fā)送出去，否則就丟失。

處理方式一

public void completeOrderService() {
    // 處理訂單
    order.process();

    // 發(fā)送會(huì)計(jì)原始憑證消息
    pipe.sendAccountingVouchetMessage();
}

在上面的情況中，如果業(yè)務(wù)操作成功，執(zhí)行的消息發(fā)送之前應(yīng)用發(fā)生故障，消息發(fā)送不出去，導(dǎo)致消息丟失，將會(huì)產(chǎn)生訂單系統(tǒng)與會(huì)計(jì)系統(tǒng)的數(shù)據(jù)不一致。如果消息系統(tǒng)或者網(wǎng)絡(luò)異常，也會(huì)導(dǎo)致消息發(fā)送不出去，也會(huì)造成數(shù)據(jù)不一致。

處理方式二

public void completeOrderService() {
    // 發(fā)送會(huì)計(jì)原始憑證消息
    pipe.sendAccountingVouchetMessage();

    // 處理訂單
    order.process();
}

如果將上面的兩個(gè)操作調(diào)換一下順序，這種情況就會(huì)更加不可控了，消息發(fā)出去了業(yè)務(wù)訂單可能會(huì)失敗，會(huì)造成訂單系統(tǒng)與業(yè)務(wù)系統(tǒng)的數(shù)據(jù)不一致。那么JMS標(biāo)準(zhǔn)中的XA協(xié)議是否可以保障發(fā)送的一致性？

  • JMS協(xié)議標(biāo)準(zhǔn)的API中，有很多以XA開頭的接口，其實(shí)就是前面講到的支持XA協(xié)議（基于兩階段提交協(xié)議）的全局事務(wù)型接口。

    XAConnection.class
XAConnectionFactory.class
XAQueueConnection.class
XAQueueConnectionFactory.class
XASession.class
XATopicConnection.class
XATopicConnectionFactory.class
XATopicSession.class
  • JMS中的XA系列的接口可以提供分布式事務(wù)的支持。但是引用XA方式的分布式事務(wù)，就會(huì)帶來(lái)很多局限性。
    1. 要求業(yè)務(wù)操作的資源必須支持XA協(xié)議，但是并不是所有的資源都支持XA協(xié)議。
    2. 兩階段提交協(xié)議的成本。
    3. 持久化成本等DTP模型的局限性，例如：全局鎖定、成本高、性能低。
    4. 使用XA協(xié)議違背了柔性事務(wù)的初衷。

（二）、保證消息一致的變通做法

分布式事務(wù)中的三種解決方案詳解

  1. 發(fā)送消息：主動(dòng)方現(xiàn)將應(yīng)用把消息發(fā)給消息中間件，消息狀態(tài)標(biāo)記為“待確認(rèn)”狀態(tài)。
  2. 消息中間件收到消息后，把消息持久化到消息存儲(chǔ)中，但是并不影響被動(dòng)方投遞消息。
  3. 消息中間件返回消息持久化結(jié)果，主動(dòng)方根據(jù)返回的結(jié)果進(jìn)行判斷如何進(jìn)行業(yè)務(wù)操作處理：
    1. 失?。悍艞増?zhí)行業(yè)務(wù)操作處理，結(jié)束，必要時(shí)向上層返回處理結(jié)果。
    2. 成功：執(zhí)行業(yè)務(wù)操作處理。
  4. 業(yè)務(wù)操作完成后，把業(yè)務(wù)操作結(jié)果返回給消息中間件。
  5. 消息中間件收到業(yè)務(wù)操作結(jié)構(gòu)后，根據(jù)業(yè)務(wù)結(jié)果進(jìn)行處理：
    1. 失敗：刪除消息存儲(chǔ)中的消息，結(jié)束。
    2. 成功：更新消息存儲(chǔ)中的消息狀態(tài)為“待發(fā)送”，然后執(zhí)行消息投遞。
  6. 前面的正向流程都成功之后，向被動(dòng)方應(yīng)用投遞消息。

但是在上面的處理流程中，任何一個(gè)環(huán)節(jié)都有可能出現(xiàn)問(wèn)題。

（三）、常規(guī)MQ消息處理流程和特點(diǎn)

分布式事務(wù)中的三種解決方案詳解

  • 常規(guī)的MQ隊(duì)列處理流程無(wú)法實(shí)現(xiàn)消息的一致性。
  • 投遞消息的本質(zhì)就是消息消費(fèi)，可以細(xì)化。

（四）、消息重復(fù)發(fā)送問(wèn)題和業(yè)務(wù)接口冪等性設(shè)計(jì)

分布式事務(wù)中的三種解決方案詳解

對(duì)于未確認(rèn)的消息，采用按規(guī)則重新投遞的方式進(jìn)行處理。對(duì)于以上流程，消息重復(fù)發(fā)送會(huì)導(dǎo)致業(yè)務(wù)處理接口出現(xiàn)重復(fù)調(diào)用的問(wèn)題。消息消費(fèi)過(guò)程中消息重復(fù)發(fā)送的主要原因就是消費(fèi)者成功接收處理完消息后，消息中間件沒(méi)有及時(shí)更新投遞狀態(tài)導(dǎo)致的。如果允許消息重復(fù)發(fā)送，那么消費(fèi)方應(yīng)該實(shí)現(xiàn)業(yè)務(wù)接口的冪等性設(shè)計(jì)。

（五）、本地消息服務(wù)方案

分布式事務(wù)中的三種解決方案詳解

  • 實(shí)現(xiàn)思路：
    1. 主動(dòng)方應(yīng)用系統(tǒng)通過(guò)業(yè)務(wù)操作完成業(yè)務(wù)數(shù)據(jù)的操作，在準(zhǔn)備發(fā)送消息的時(shí)候?qū)⑾⒋鎯?chǔ)在主動(dòng)方應(yīng)用系統(tǒng)一份，另一份發(fā)送到實(shí)時(shí)消息服務(wù)
    2. 被動(dòng)方應(yīng)用系統(tǒng)監(jiān)聽(tīng)實(shí)時(shí)消息系統(tǒng)中的消息，當(dāng)被動(dòng)方完成消息處理后通過(guò)調(diào)用主動(dòng)方接口完成消息確認(rèn)
    3. 主動(dòng)方接收到消息確認(rèn)以后刪除消息數(shù)據(jù)。
    4. 通過(guò)消息查詢服務(wù)查詢到消息被接收之后再規(guī)定的時(shí)間內(nèi)沒(méi)有返回ACK確認(rèn)消息就通過(guò)消息恢復(fù)系統(tǒng)重新發(fā)送消息。
  • 優(yōu)點(diǎn)：
    1. 消息的時(shí)效性比較高
    2. 從應(yīng)用設(shè)計(jì)的角度實(shí)現(xiàn)了消息數(shù)據(jù)的可靠性，消息數(shù)據(jù)的可靠性不依賴于MQ中間件，弱化了對(duì)MQ中間件特性的依賴。
    3. 方案輕量級(jí)，容易實(shí)現(xiàn)。
  • 缺點(diǎn)：
    1. 與具體的業(yè)務(wù)場(chǎng)景綁定，耦合性強(qiáng)，不可以共用。
    2. 消息數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)同步，占用業(yè)務(wù)系統(tǒng)資源。
    3. 業(yè)務(wù)系統(tǒng)在使用關(guān)系型數(shù)據(jù)庫(kù)的情況下消息服務(wù)性能會(huì)受到關(guān)系型數(shù)據(jù)庫(kù)的并發(fā)性能限制。

（六）、獨(dú)立消息服務(wù)方案

分布式事務(wù)中的三種解決方案詳解

  • 實(shí)現(xiàn)思路：
    1. 預(yù)發(fā)送消息：主動(dòng)方應(yīng)用系統(tǒng)預(yù)發(fā)送消息，由消息服務(wù)子系統(tǒng)存儲(chǔ)消息，如果存儲(chǔ)失敗，那么也就無(wú)法進(jìn)行業(yè)務(wù)操作。如果返回存儲(chǔ)成功，然后執(zhí)行業(yè)務(wù)操作。
    2. 執(zhí)行業(yè)務(wù)操作：執(zhí)行業(yè)務(wù)操作如果成功的時(shí)候，將業(yè)務(wù)操作執(zhí)行成功的狀態(tài)發(fā)送到消息服務(wù)子系統(tǒng)。消息服務(wù)子系統(tǒng)修改消息的標(biāo)識(shí)為“可發(fā)送”狀態(tài)。
    3. 發(fā)送消息到實(shí)時(shí)消息服務(wù)：當(dāng)消息的狀態(tài)發(fā)生改變的時(shí)候，立刻將消息發(fā)送到實(shí)時(shí)消息服務(wù)中。接下來(lái)，消息將會(huì)被消息業(yè)務(wù)的消費(fèi)端監(jiān)聽(tīng)到，然后被消費(fèi)。
    4. 消息狀態(tài)子系統(tǒng)：相當(dāng)于定時(shí)任務(wù)系統(tǒng)，在消息服務(wù)子系統(tǒng)中定時(shí)查找確認(rèn)超時(shí)的消息，在主動(dòng)方應(yīng)用系統(tǒng)中也去定時(shí)查找沒(méi)有處理成功的任務(wù)，進(jìn)行相應(yīng)的處理。
    5. 消息消費(fèi)：當(dāng)消息被消費(fèi)的時(shí)候，向?qū)崟r(shí)消息服務(wù)發(fā)送ACK，然后實(shí)時(shí)消息服務(wù)刪除消息。同時(shí)調(diào)用消息服務(wù)子系統(tǒng)修改消息為“被消費(fèi)”狀態(tài)。
    6. 消息恢復(fù)子系統(tǒng)：當(dāng)消費(fèi)方返回消息的時(shí)候，由于網(wǎng)絡(luò)中斷等其他原因?qū)е孪](méi)有及時(shí)確認(rèn)，那么需要消息恢復(fù)子系統(tǒng)定時(shí)查找出在消息服務(wù)子系統(tǒng)中沒(méi)有確認(rèn)的消息。將沒(méi)有被確認(rèn)的消息放到實(shí)時(shí)消息服務(wù)中，進(jìn)行重做，因?yàn)楸粍?dòng)方應(yīng)用系統(tǒng)的接口是冪等的。
  • 優(yōu)點(diǎn)：
    1. 消息服務(wù)獨(dú)立部署，獨(dú)立維護(hù)，獨(dú)立伸縮。
    2. 消息存儲(chǔ)可以按需選擇不同的數(shù)據(jù)庫(kù)來(lái)集成實(shí)現(xiàn)。
    3. 消息服務(wù)可以被相同的的使用場(chǎng)景使用，降低重復(fù)建設(shè)服務(wù)的成本。
    4. 從分布式服務(wù)應(yīng)用設(shè)計(jì)開發(fā)角度實(shí)現(xiàn)了消息數(shù)據(jù)的可靠性，消息數(shù)據(jù)的可靠性不依賴于MQ中間件，弱化了對(duì)MQ中間件特性的依賴。
    5. 降低了業(yè)務(wù)系統(tǒng)與消息系統(tǒng)之間的耦合，有利于系統(tǒng)的擴(kuò)展維護(hù)。
  • 缺點(diǎn)：
    1. 一次消息發(fā)送需要兩次請(qǐng)求。
    2. 主動(dòng)方應(yīng)用系統(tǒng)需要實(shí)現(xiàn)業(yè)務(wù)操作狀態(tài)的校驗(yàn)與查詢接口。

（七）、消息服務(wù)子系統(tǒng)的設(shè)計(jì)實(shí)現(xiàn)

示例消息數(shù)據(jù)表：

名稱數(shù)據(jù)類型允許空默認(rèn)值屬性釋義
uuidvarchar(50)No—uniqueUUID
versionint(11)No0—版本號(hào)
editervarchar(100)YesNULL—修改者
creatervarchar(100)YesNULL—創(chuàng)建者
edit_timedatetimeYes0000-00-00 00:00:00—最后修改時(shí)間
create_timedatetimeNo0000-00-00 00:00:00—創(chuàng)建時(shí)間
msg_idvarchar(50)No——消息ID
msg_bodylongtextNo——消息內(nèi)容
msg_date_typevarchar(50)Yes——消息數(shù)據(jù)類型
consumer_queuevarchar(100)No——消費(fèi)隊(duì)列
send_timesint(6)No0—消息重發(fā)次數(shù)
is_deadvarchar(20)No——是否死亡
statusvarchar(20)No——狀態(tài)
remarkvarchar(200)Yes——備注
field0varchar(200)Yes——擴(kuò)展字段0
field1varchar(200)Yes——擴(kuò)展字段1
field2varchar(200)Yes——擴(kuò)展字段2

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國(guó)云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開啟，新人活動(dòng)云服務(wù)器買多久送多久。

網(wǎng)站標(biāo)題：分布式事務(wù)中的三種解決方案詳解-創(chuàng)新互聯(lián)
當(dāng)前URL：http://bm7419.com/article48/dpoihp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)公司、標(biāo)簽優(yōu)化、用戶體驗(yàn)、外貿(mào)建站、虛擬主機(jī)

廣告

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

外貿(mào)網(wǎng)站制作