偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

訂單系統(tǒng)中的數(shù)據(jù)一致性方案及RocketMQ事務(wù)消息詳解

開發(fā) 架構(gòu)
生產(chǎn)中存在兩種常用的解決方案:TCC和可靠消息最終一致性。前者要求強一致,后者要求最終一致。強一致主要用于核心模塊,例如交易/訂單等。最終一致一般用于邊緣模塊例如庫存,通過mq去通知,保證最終一致性,也可以業(yè)務(wù)解耦。

數(shù)據(jù)一致性是確保業(yè)務(wù)操作正確執(zhí)行的基礎(chǔ),本文將以電商系統(tǒng)為例,詳細(xì)分析其分布式系統(tǒng)中的一致性問題。訂單核心流程:

訂單服務(wù) -> 創(chuàng)建訂單 -> 庫存服務(wù) -> 扣減庫存 -> 積分服務(wù) -> 增加積分 -> 倉儲服務(wù) -> 通知發(fā)貨

分布式一致性技術(shù)方案

生產(chǎn)中存在兩種常用的解決方案:TCC和可靠消息最終一致性。前者要求強一致,后者要求最終一致。

強一致主要用于核心模塊,例如交易/訂單等。最終一致一般用于邊緣模塊例如庫存,通過mq去通知,保證最終一致性,也可以業(yè)務(wù)解耦。

TCC:

訂單服務(wù)、庫存服務(wù)、積分服務(wù) -> 綁定為一個TCC事務(wù);

撤銷訂單時,回滾扣減庫存和增加積分。

可靠消息最終一致性:

可以去發(fā)送一個請求給消息中間件,由中間件保證一定會把消息交給下游的庫存服務(wù)去扣減庫存,倉儲服務(wù)去通知發(fā)貨等;

如果這個過程中有消息發(fā)送失敗,則可靠消息中間件應(yīng)該保證不停的重試投遞消息。

本文重點分析如何利用RocketMQ的事務(wù)消息實現(xiàn)最終一致性,TCC事務(wù)將在另外一篇文章分享。

事務(wù)消息

RocketMQ的事務(wù)消息有兩個核心概念(流程):

  • Half Message,半消息

暫時不能被 Consumer消費的消息。Producer已經(jīng)把消息發(fā)送到 Broker端,但是此消息的狀態(tài)被標(biāo)記為不能投遞,處于這種狀態(tài)下的消息稱為半消息。事實上,該狀態(tài)下的消息會被放在一個叫做 RMQ_SYS_TRANS_HALF_TOPIC的主題下。

當(dāng) Producer端對它二次確認(rèn)后,也就是 Commit之后,Consumer端才可以消費到;那么如果是Rollback,該消息則會被刪除,永遠(yuǎn)不會被消費到。

  • 事務(wù)狀態(tài)回查

可能會因為網(wǎng)絡(luò)原因、應(yīng)用問題等,導(dǎo)致Producer端一直沒有對這個半消息進(jìn)行確認(rèn),那么這時候 Broker服務(wù)器會定時掃描這些半消息,主動找Producer端查詢該消息的狀態(tài)。

簡而言之,RocketMQ事務(wù)消息的實現(xiàn)原理就是基于兩階段提交和事務(wù)狀態(tài)回查,來決定消息最終是提交還是回滾的。

核心流程

結(jié)合整個訂單接口服務(wù),分為兩個支付鏈路,一個是核心鏈路(訂單業(yè)務(wù)),一個是非核心鏈路(wms) 整個流程。

先向RocketMQ發(fā)送half msg,然后調(diào)用核心鏈路。核心鏈路要是返回失敗,就會走失敗的邏輯:退款,更改訂單狀態(tài)為取消,再給rocketmq發(fā)送callback廢棄掉剛才的消息。

如果成功,就commit msg讓消費者可以消費。如果在等待期間,一直沒有callback/commit那么mq就會走回調(diào)查詢具體的狀態(tài)。

消費者接收到消息后,消費完成就回復(fù)mq一個ack, 如果消費失敗了,mq就會重新投遞或者換一個服務(wù)投遞。使用rocketmq的half msg機制,可以實現(xiàn)這一套固定模式的最終一致性。

代碼實現(xiàn)

【核心鏈路-訂單、庫存、積分】

核心業(yè)務(wù)流程

【步驟一】:發(fā)送事務(wù)消息(half msg

springboot下,RocketMQ的集成還是很簡單的,引入
rocketmq-spring-boot-starter依賴、添加相關(guān)配置后,即可利用RocketMQTemplate的sendMessageInTransaction方法發(fā)送消息:

/**
 * 發(fā)送事務(wù)消息
 *
 * @param topic   topic
 * @param message 消息對象
 */
public void sendMessageInTransaction(String topic, Object message) {
    String transactionId = UUID.randomUUID().toString();
    TransactionSendResult result = this.rocketMQTemplate.sendMessageInTransaction(topic, MessageBuilder.withPayload(message)
            .setHeader(RocketMQHeaders.TRANSACTION_ID, transactionId)
            .build(), message);
}

【步驟二】:broker回調(diào),執(zhí)行本地事務(wù)

消息發(fā)送成功之后,系統(tǒng)需要知道RocketMQ的broker是否成功收到了消息,這里主要借助
RocketMQTransactionListener注解實現(xiàn)。在成功收到回調(diào)后,會觸發(fā)executeLocalTransaction來
執(zhí)行核心業(yè)務(wù)(訂單、庫存、積分等)。

@RocketMQTransactionListener
public class OrderTransactionListener implements RocketMQLocalTransactionListener {

    /**
     * 執(zhí)行本地事務(wù),即處理核心鏈路
     * @param msg
     * @param arg
     * @return
     */
    @Override
    public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
          	// 事務(wù)transactionId
            String transactionId = msg.getHeaders().get("rocketmq_TRANSACTION_ID").toString();
            // 本地事務(wù),執(zhí)行核心鏈路業(yè)務(wù)
            String payload = new String((byte[]) msg.getPayload());
            OrderTranscationMesageDTO data = JSONObject.parseObject(payload, OrderTranscationMesageDTO.class);
            orderService.executeCoreBusiness(data.getPayMoney(),data.getOrderDO(), data.getTransactionNo(),data.getPayType(),transactionId);
        } catch (Exception e) {
            log.error("本地事務(wù)執(zhí)行異常:{}事務(wù)消息回滾", e.getMessage());
            return RocketMQLocalTransactionState.ROLLBACK;
        }
      	log.info("提交事務(wù)消息");
        return RocketMQLocalTransactionState.COMMIT;
    }

    /**
     * 校驗本地事務(wù)(broker未收到提交或回滾事務(wù)消息時主動回查)
     * @param msg
     * @return
     */
    @Override
    public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
        // 事務(wù)transactionId
        String transactionId = msg.getHeaders().get("rocketmq_TRANSACTION_ID").toString();
        // 數(shù)據(jù)庫能查到,說明本地事務(wù)執(zhí)行失敗,需要回滾
        if (Objects.isNull(transcationLogDao.getById(transactionId))){
            return RocketMQLocalTransactionState.ROLLBACK;
        }
        return RocketMQLocalTransactionState.COMMIT;
    }

}

執(zhí)行核心業(yè)務(wù)的同時,還有一個很重要的環(huán)節(jié),即記錄事務(wù)ID。為什么要記錄事務(wù)ID呢?假想這樣一種情況:我們本地事務(wù)即核心的業(yè)務(wù)都成功執(zhí)行后,需要提交RocketMQ的事務(wù)消息,只有提交后,消息才能被消費者(即非核心業(yè)務(wù)系統(tǒng),如倉儲)消費,但是如果提交時,網(wǎng)絡(luò)出現(xiàn)異常,broker一直未收到怎么辦呢,這時利用transactionId,也是RocketMA的回查機制了。

/**
  * 核心業(yè)務(wù),并記錄RocketMQ事務(wù)ID
*/
@GlobalTransactional  // seata全局事務(wù)
public void executeCoreBusiness(BigDecimal payMoney, AppDerivativeGoodsOrderDO orderDO, String transactionNo, String payType,String transactionId) {
		// 核心業(yè)務(wù)偽代碼
    orderService.execute();
    storeFeign.execute();
    scoreFeign.execute();
    
    // 數(shù)據(jù)庫記錄rocket事務(wù)消息ID 用于異常情況下的回查
    if (Objects.nonNull(transactionId)){
        //寫入事務(wù)日志
        TransactionLogDO log = new TransactionLogDO();
        log.setId(transactionId);
        log.setBusiness("order");
        log.setForeignKey(String.valueOf(orderDO.getId()));
        transcationLogDao.save(log);
    }
}

本地事務(wù)執(zhí)行成功之后,記錄事務(wù)ID,即便提交時,出現(xiàn)網(wǎng)絡(luò)異常,broker遲遲未收到,也可以利用回查機制,即checkLocalTransaction方法,得知本地事務(wù)是否執(zhí)行成功。

用于記錄事務(wù)的表結(jié)構(gòu):

CREATE TABLE `transaction_log` (
  `id` varchar(32) COLLATE utf8mb4_bin NOT NULL DEFAULT '' COMMENT '事務(wù)ID',
  `business` varchar(32) COLLATE utf8mb4_bin NOT NULL COMMENT '業(yè)務(wù)標(biāo)識',
  `foreign_key` varchar(32) COLLATE utf8mb4_bin NOT NULL COMMENT '對應(yīng)業(yè)務(wù)表中的主鍵',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

【非核心鏈路-wms倉儲】

【步驟三】:消費消息,處理其他業(yè)務(wù)

上述的步驟保證了核心業(yè)務(wù)與RocketMQ消息的一致性,即核心業(yè)務(wù)成功,消息就一定會被發(fā)送到broker。接下來就是非核心業(yè)務(wù)(如倉儲物流)監(jiān)聽消息,通過@RocketMQMessageListener實現(xiàn):

@RocketMQMessageListener(topic = "order_topic",consumerGroup = "order_group")
public class TestListener implements RocketMQListener<MessageExt> {
    @Override
    public void onMessage(MessageExt messageExt) {
        if(messageExt.getReconsumeTimes() >= 3){
            log.error("消息重試已達(dá)最大次數(shù),將通知業(yè)務(wù)人員排查問題。{}",messageExt.getMsgId());
            //消息處理,第3次處理失敗后,發(fā)送郵件通知人工介入
            sendMail(messageExt.getMsgId());
        }
        // 倉儲物流相關(guān)業(yè)務(wù) 
        wmsService.execute(messageExt.getBody());
    }
}

非核心業(yè)務(wù),接受不了消息后,再處理相關(guān)業(yè)務(wù),其實,此時已經(jīng)與核心業(yè)務(wù)脫離了關(guān)聯(lián),因此,不管它成功與否,核心業(yè)務(wù)都已經(jīng)完成了,這也為何是最終一致性,而非強一致性。

最終一致性主要依賴的是RocketMQ的重試機制以及補償處理(比人工干預(yù))。如上述代碼中,假若wmsService執(zhí)行業(yè)務(wù)過程拋出了異常,即消息消費失敗,RocketMQ則會自動重發(fā)。默認(rèn)16次,可以通過配置修改。另外,可以在重試一定次數(shù)后,做補償處理,例如,將執(zhí)行失敗的任務(wù)記錄在數(shù)據(jù)庫,后續(xù)定時任務(wù)補償處理,抑或是像上述代碼,發(fā)送郵件通知相關(guān)人員。

冪等性消費

消息的重發(fā),有可能帶來另外一個問題,重復(fù)消費。不做處理,就可能導(dǎo)致數(shù)據(jù)重復(fù)插入,倉儲系統(tǒng)就可能重復(fù)發(fā)貨。

冪等性:就是用戶對于同一操作發(fā)起的一次請求或者多次請求的結(jié)果是一致的,不會因為多次點擊而產(chǎn)生了副作用。

實現(xiàn)冪等性消費的方式有很多種,具體怎么做,根據(jù)自己的情況來看。一種常用的方式就是利用redis緩存,在執(zhí)行操作之前,先到緩存中查詢,該操作是否已執(zhí)行過。

總結(jié)

本文重點闡述了基于RocketMQ來實現(xiàn)最終一致性的分布式事務(wù)案例。

責(zé)任編輯:姜華 來源: 今日頭條
相關(guān)推薦

2021-03-04 06:49:53

RocketMQ事務(wù)

2023-12-01 13:51:21

數(shù)據(jù)一致性數(shù)據(jù)庫

2019-01-15 17:58:03

微服務(wù)架構(gòu)數(shù)據(jù)

2019-12-17 08:40:33

微服務(wù)架構(gòu)數(shù)據(jù)

2009-06-18 09:18:08

Oracle檢索數(shù)據(jù)數(shù)據(jù)一致性事務(wù)恢復(fù)

2021-11-01 21:15:54

微服務(wù)系統(tǒng)數(shù)據(jù)

2025-03-27 08:20:54

2023-08-22 09:32:44

邊緣計算管理

2023-11-22 12:55:59

微服務(wù)架構(gòu)數(shù)據(jù)庫

2022-07-21 06:54:28

微服務(wù)系統(tǒng)RocketMQ

2018-09-11 10:46:10

緩存數(shù)據(jù)庫一致性

2024-12-26 15:01:29

2023-09-07 08:11:24

Redis管道機制

2021-12-05 21:06:27

軟件

2021-10-18 10:30:59

流計算阿里云

2021-10-13 09:55:11

流計算引擎數(shù)據(jù)

2021-06-16 08:33:02

分布式事務(wù)ACID

2023-06-07 08:10:29

2023-12-27 14:23:10

微服務(wù)數(shù)據(jù)存儲

2025-03-27 03:00:00

點贊
收藏

51CTO技術(shù)棧公眾號