分布式事务之通过RocketMQ事务实现可靠消息最终一致性方案

RocketMQ事务消息的最佳实践 在分布式的场景下,我们经常能遇到事务一致性问题,如何去保证事务的一致性,是分布式场景下不可避免的一个重要话题。 我们很难去做到事务的强一致性(有方案),因此会退一步去保证事务的最终一致性。 如何去保证事务的最终一致性呢?我们可以利用RocketMQ的事务消息来保证事务的最终一致性。 RocketMQ如何保证事务的一致性呢?原来,RocketMQ通过将应用本地事务和发送消息操作定义到全局事务中,要么同时成功,要么同时失败。这样就保证了本地事务和消息发送的一致性: 事务消息的原理可以参考事务消息以及收发事. 阅读详情

分布式事务基础理论

基于上述的CAP和BASE理论,一般情况下会保证P和A,舍弃C,保证最终一致性。最终一致是指经过一段时间后,所有节点数据都将会达到一致。如订单的"支付中"状态,最终会变为“支付 成功”或者"支付失败",使订单状态与实际交易结果达成一致,但需要一定时间的延迟、等待。

概述案例

此方案的核心是将分布式事务拆分成多个本地事务,然后通过网络由消息队列协调完成所有事务,并实现最终一致性。以转账为例:

1. 消息发送方张三,即Bank1: 扣减余额30元,然后通过网络发送消息到MQ

2. 消息接收方李四,即Bank2: 通过网络从MQ中接收消息,然后增加余额30元

该解决方案容易理解,实现成本低,但是面临以下几个问题:

1.消息发送方执行本地事务与发送消息的原子性问题,也就是说如何保证本地事务执行成功,消息一定发送成功

begin transaction

1.数据库操作

2.发送消息

commit transation

这种情况下,貌似没有问题,如果发送消息失败,就会抛出异常,导致数据库事务回滚。但如果是超时异常,数据库回滚,但此时消息已经正常发送了,同样会导致不一致。

2.消息接收方接收消息与本地事务的原子性问题,也就是说如何保证接收消息成功后,本地事务一定执行成功

3.由于消息可能会重复发送,这就要求消息接收方必须实现幂等性

由于在生产环境中,消费方很有可能是个集群,若某一个消费节点超时但是消费成功,会导致集群同组 其他节点重复消费该消息。另外意外宕机后恢复,由于消费进度没有及时写入磁盘,会导致消费进度部 分丢失,从而导致消息重复消费。

解决方案:RocketMQ可靠消息

RocketMQ 是一个来自阿里巴巴的分布式消息中间件,于 2012 年开源,并在 2017 年正式成为 Apache 顶级项目。Apache RocketMQ 4.3之后的版本正式支持事务消息,为分布式事务实现提供了便 利性支持。因此,我们通过RocketMQ就可以解决前面的问题。

1.消息发送方执行本地事务与发送消息的原子性问题,也就是说如何保证本地事务执行成功,消息一定发送成功

RocketMQ中的Broker 与 发送方 具备双向通信能力,使得 broker 天生可以作为一个事务协调者存在;并且RocketMQ 本身提供了存储机制,使得事务消息可以持久化保存;这些优秀的设计可以保证即使发生了异常,RocketMQ依然能够保证达成事务的最终一致性。

 1. 发送方发送一个事务消息给Broker,RocketMQ会将消息状态标记为“Prepared”,此时这条消息暂时不能被接收方消费。这样的消息称之为Half Message,即半消息。

2. Broker返回发送成功给发送方

3. 发送方执行本地事务,例如操作数据库

4. 若本地事务执行成功,发送commit消息给Broker,RocketMQ会将消息状态标记为“可消费”,此 时这条消息就可以被接收方消费;若本地事务执行失败,发送rollback消息给Broker,RocketMQ 将删除该消息。

5. 如果发送方在本地事务过程中,出现服务挂掉,网络闪断或者超时,那Broker将无法收到确认结 果

6. 此时RocketMQ将会不停的询问发送方来获取本地事务的执行状态(即事务回查)

7. 根据事务回查的结果来决定Commit或Rollback,这样就保证了消息发送与本地事务同时成功或同时失败。

以上主干流程已由RocketMQ实现,对于我们来说只需要分别实现本地事务执行的方法以及本地事务回查的方法即可,具体来说就是实现下面这个接口:

public interface TransactionListener {
/**
- 发送prepare消息成功后回调该方法用于执行本地事务
- @param msg 回传的消息,利用transactionId即可获取到该消息的唯一Id
- @param arg 调用send方法时传递的参数,当send时候若有额外的参数可以传递到send方法中,
这里能获取到
- @return 返回事务状态,COMMIT:提交 ROLLBACK:回滚 UNKNOW:未知,需要回查
*/
LocalTransactionState executeLocalTransaction(final Message msg, final
Object arg);
/**
- @param msg 通过获取transactionId来判断这条消息的本地事务执行状态
- @return 返回事务状态,COMMIT:提交 ROLLBACK:回滚 UNKNOW:未知,需要回查
*/
LocalTransactionState checkLocalTransaction(final MessageExt msg);
}

2.消息接收方接收消息与本地事务的原子性问题,也就是说如何保证接收消息成功后,本地事务一定执行成功

如果是出现了异常,RocketMQ会通过重试机制,每隔一段时间消费消息,然后再执行本地事务;如果 是超时,RocketMQ就会无限制的消费消息,不断的去执行本地事务,直到成功为止。

快速入门

通过RocketMQ可靠消息实现最终一致性,模拟两个账户的转账交易过程。两个账户分别在不同 的银行(张三在bank1、李四在bank2),bank1、bank2是两个相互独立的微服务。

为了实现幂等性,需要分别在bank1、bank2数据库中新增de_duplication表,即交易记录表(去重表)。

消息发送方bank1

1. Controller层代码以及定义一个类封装转账消息:

@RestController
@Slf4j
public class AccountInfoController {
    @Autowired
    private AccountInfoService accountInfoService;

    @GetMapping(value = "/transfer")
    public String transfer(){
        accountInfoService.updateAccountBalance(new AccountChangeEvent("1",100,System.currentTimeMillis()));
        return "转账成功";
    }
}
@Data
@AllArgsConstructor
@NoArgsConstructor
public class AccountChangeEvent implements Serializable {
    /**
     * 账号
     */
    private String accountNo;
    /**
     * 变动金额
     */
    private double amount;
    /**
     * 事务号,时间戳
     */
    private long txNo;

}

2. 实现dao数据访问层,一共四个功能

@Mapper
@Component
public interface AccountInfoDao {
    /**
     * 修改某账号的余额
     * @param accountNo 账号
     * @param amount 变动金额
     * @return
     */
        @Update("update account_info set account_balance=account_balance+#{amount} where account_no=#{accountNo}")
                int updateAccountBalance(@Param("accountNo") String accountNo, @Param("amount") Double amount);


    /**
     * 查询某账号信息
     * @param accountNo 账号
     * @return
     */
    @Select("select * from account_info where where account_no=#{accountNo}")
    AccountInfo findByIdAccountNo(@Param("accountNo") String accountNo);

    /**
     * 查询某事务记录是否已执行
     * @param txNo 事务编号
     * @return
     */
    @Select("select count(1) from de_duplication where tx_no = #{txNo}")
    int isExistTx(long txNo);

    /**
     * 保存某事务执行记录
     * @param txNo 事务编号
     * @return
     */
    @Insert("insert into de_duplication values(#{txNo},now());")
    int addTx(long txNo);
}

3. 实现发送转账消息

@Component
public class BankMessageProducer {
    @Resource
    private RocketMQTemplate rocketMQTemplate;

    public void sendAccountChangeEvent(AccountChangeEvent accountChangeEvent) {
        //构造消息
        JSONObject jsonObject=new JSONObject();
        jsonObject.put("accountChange",accountChangeEvent);
        //这里Message需要导入spring的包
        Message<String> msg= MessageBuilder.withPayload( jsonObject.toJSONString()).build();

        //发送消息
        rocketMQTemplate.sendMessageInTransaction("producer_ensure_transfer",
                "topic_ensure_transfer",
                msg, null);

    }
}

业务流程1(发送转账消息)

controller接收修改金额请求  调用service修改金额方法 传入一个AccountChangeEvent对象,用当前时间代表事务号

service层方法调用BankMessageProducer消息发送类中的方法

 由于RocketMQTemplate发送消息需要一个message对象 所以要先创建一个JSONObject将AccountChangeEvent对象写入然后转换为JSON字符串封装到Message对象中,将其发送,使用sendMessageInTransaction发送事务消息

4. 实现业务层代码

分别实现了发送事务消息与本地事务扣减金额,注意 doUpdateAccountBalance的本地事务若执行成功,就会在交易记录去重表(de_duplication)保存数据。

@Transactional(isolation = Isolation.SERIALIZABLE)(最高隔离级别,不允许事务并发执行,而必须串行化执行,最安全,不可能出现更新、脏读、不可重复读、幻读)

@Service
@Slf4j
public class AccountInfoServiceImpl implements AccountInfoService {

    @Autowired
    private BankMessageProducer bankMessageProducer;

    @Autowired
    private AccountInfoDao accountInfoDao;
     /**
     * 更新帐号余额-发送消息
     * @param accountChange
     */
    @Override
    public void updateAccountBalance(AccountChangeEvent accountChange) {
        bankMessageProducer.sendAccountChangeEvent(accountChange);
    }
    /**
     * 更新帐号余额-本地事务
     * @param accountChange
     */
    @Override
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public void doUpdateAccountBalance(AccountChangeEvent accountChange) {
        accountInfoDao.updateAccountBalance(accountChange.getAccountNo(),accountChange.getAmount()*-1);
        accountInfoDao.addTx(accountChange.getTxNo());
    }
}

修改账户金额完成后保存该事务执行的记录到de_duplication表中

5. 实现RocketMQ事务消息监听器

RocketMQLocalTransactionListener

其中有两个功能:

(1) executeLocalTransaction,该方法执行本地事务,会被RocketMQ自动调用

在这个方法中进行事务处理 如果失败了就选择回滚事务

return RocketMQLocalTransactionState.ROLLBACK;

成功就提交事务

return RocketMQLocalTransactionState.COMMIT;

(2) checkLocalTransaction,该方法实现事务回查,利用了交易记录去重表(de_duplication),会被RocketMQ自动调用

@Component
@Slf4j
@RocketMQTransactionListener(txProducerGroup = "producer_ensure_transfer")
public class TransferTransactionListenerImpl implements RocketMQLocalTransactionListener {

    @Autowired
    private AccountInfoService accountInfoService;

    @Autowired
    private AccountInfoDao accountInfoDao;

    /**
     * 执行本地事务
     * @param msg
     * @param arg
     * @return
     */
    @Override
    public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        //1.接收并解析消息
        final JSONObject jsonObject = JSON.parseObject(new String((byte[])
                msg.getPayload()));
        AccountChangeEvent accountChangeEvent =
                JSONObject.parseObject(jsonObject.getString("accountChange"),AccountChangeEvent.
                        class);

        //2.执行本地事务
        Boolean isCommit = true;
        try {
            accountInfoService.doUpdateAccountBalance(accountChangeEvent);
        }catch (Exception e){
            isCommit = false;
        }

        //3.返回执行结果
        if(isCommit){
            return RocketMQLocalTransactionState.COMMIT;
        }else {
            return RocketMQLocalTransactionState.ROLLBACK;
        }
    }


    /**
     * 事务回查
    * @param msg
    * @return
        */
    @Override
    public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
        System.out.println("事务回查");
        //1.接收并解析消息
        final JSONObject jsonObject = JSON.parseObject(new String((byte[])
                msg.getPayload()));
        AccountChangeEvent accountChangeEvent =
                JSONObject.parseObject(jsonObject.getString("accountChange"),AccountChangeEvent.
                        class);

        //2.查询de_duplication表
        int isExistTx = accountInfoDao.isExistTx(accountChangeEvent.getTxNo());

        //3.根据查询结果返回值
        if(isExistTx>0){
            return RocketMQLocalTransactionState.COMMIT;
        }else {
            return RocketMQLocalTransactionState.ROLLBACK;
        }
    }
}

rocketMQ逻辑结构:

业务流程2(消息成功接受回调,执行本地事务)

监听器监听到broker传回的半消息发送成功后执行本地事务  设置一个boolean值代表事务执行成功与否,如果抓取到异常则说明本地事务执行失败,失败则进行回滚,否则就提交事务

业务流程3(事务回查)

由于在执行executeLocalTransaction这个方法的时候可能会出现异常而导致执行事务的结果并没有发送给rocketMQ,如果是超时异常,数据库回滚,但此时消息已经正常发送了,同样会导致不一致,破坏执行本地事务与发送消息这两个操作的原子性问题,所以rocketMQ会自动调用checkLocalTransaction这个方法会不断的检查事务执行结果  而这个方法是根据de_duplication表中的数据来判断事务是否成功,因为在业务流程2中修改bank1数据的时候也会同步记录到de_duplication表中 根据结果返回提交或者回滚消息给rocketMQ

至此 bank1这里的业务步骤就执行完毕了

消息接受方bank2

1.定义监听器

业务流程1(监听消息)

一旦监听到bank1服务发送的消息 就会执行onMessage方法

该方法会先解析JSON字符串,获取其中的accountChangeEvent对象

接着执行本地事务更新 调用service层方法

@Component
@RocketMQMessageListener(topic = "topic_ensure_transfer", consumerGroup =
        "consumer_ensure_transfer")
public class EnsureMessageConsumer implements RocketMQListener<String> {

    @Autowired
    private AccountInfoService accountInfoService;

    @Override
    public void onMessage(String message) {
        System.out.println("消费消息:"+message);
        //1.解析消息
        final JSONObject jsonObject = JSON.parseObject(message);
        AccountChangeEvent accountChangeEvent =
                JSONObject.parseObject(jsonObject.getString("accountChange"),AccountChangeEvent.
                        class);
        //2.执行本地事务
        accountChangeEvent.setAccountNo("2");
        accountInfoService.updateAccountBalance(accountChangeEvent);
    }
}

2.service层代码

业务流程2(执行本地事务)

最高级事务级别,先看下de_duplication中是否有事务数据 如果有的话证明已经修改过bank2的数据库,则不做修改,以此避免了接口幂等性问题

@Service
@Slf4j
public class AccountInfoServiceImpl implements AccountInfoService {

    @Autowired
    private AccountInfoDao accountInfoDao;

    @Override
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public void updateAccountBalance(AccountChangeEvent accountChange) {
        System.out.println("bank2执行本地事务");
        int isExistsTx = accountInfoDao.isExistTx(accountChange.getTxNo());
        if(isExistsTx==0){
            accountInfoDao.updateAccountBalance(accountChange.getAccountNo(),accountChange.getAmount());
            accountInfoDao.addTx(accountChange.getTxNo());

        }
    }
}

总结:

bank1和bank2都成功

bank1执行本地事务失败,则bank2接收不到转账消息。

bank1执行完本地事务后,不返回任何信息,则Broker会进行事务回查,直到获取事务结果消息。

bank2执行本地事务失败,会进行重试消费。

可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入该机制后,同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响,并实现了两个服务的解耦。

《使用RocketMQ 做Spring Cloud异步场景分布式事务》 作者:陶陶技术笔记 链接:https://www.cnblogs.com/zlt2000/p/11570917.html?utm_source=tuicool&utm_medium=referral 一、背景 在微服务架构中,我们常常使用异步化的手段来提升系统的吞吐量和解耦上下游,而构建异步架构最常用的手段就是使用 消息队列(MQ) ,那异步架构怎样才能实现数据... 阅读详情

相关推荐

RocketMQ事务消息如何保证数据的最终一致性

前言 在面过的几家大厂中,几乎每轮的面试官(没写错,几乎是每轮面试官)都问了同样一个问题:你们的系统是分布式的系统吗? 答:是。 面试官:那么你们分布式的系统是如何解决分布式事务这个问题的呢?也就是如何保证数据的一致性。 答:我们的系统中通过 RocketMQ 的事务消息来保证数据的最终一致性。 面试官:那你说说它是如何来保证数据的最终一致性的? 答:分两部分来回答,第一部分先回答事务消息的实现流程,第二部分解释为什么它能保证数据的最终一致性。 事务消息的实现流程 [外链图片转存失败,源站可能有防盗链机

天堂的博客 5153

消息队列重难点问题

消息队列 RabbitMQ Kafka RocketMQ 解耦 异步 削峰 如何保证消息不被重复消费 如何保证消息传输的可靠性 如何保证消息的顺序性 如何解决消息积压 如果要自己实现一个消息队列,架构设计应该是怎样的 kafka为什么能实现高吞吐量

weixin_43111776的博客 1738

分布式事务解决方案(TCC和最终一致性)

分布式事务解决方案探讨-TCC和可靠消息最终一致性方案

棉花糖老丫 1564

RocketMQ - 如何实现事务消息

事务消息的使用场景很多,比如在电商系统中用户下单后新增了订单记录,对应的商品库存需要减少。又例如红包业务,张三给李四发红包,张三的账户余额需要扣减,李四的账户余额需要增加,怎么保证张三账户扣减李四账户加钱呢?这些问题都是事务问题,可以简单理解为:一个表的数据更新后,如何保证另外一个表的数据也更新成功。如果使用同一个数据库实例,那么问题很简单,可以使用本地事务来解决,Spring的@Transactional注解就支持。消费事务消息与消费普通消息的代码是一样的,无需做任何修改。

yang的博客 5700

VScode利用EIDE和cortex-debug进行stm32开发(也适用51)

你是否因为keil页面太丑而烦恼,你是否因为keil编译太慢而恼怒,ok阿,今天也是给大家带来怎么在vscode上进行stm32的编程(我不会告诉你,我搞了好几天才搞好的💔💔💔)为什么是简单介绍?因为太啰嗦了,我嫌麻烦😋,大家可以去EIDE的官方文档去看。

weixin_73952614的博客 9368

如何用Python实现SPEI指数计算?从数据准备到结果可视化完整指南

本文提供了一份完整的Python实现SPEI指数计算指南,涵盖从数据准备、潜在蒸散量计算到结果可视化的全流程。详细介绍了使用Thornthwaite方法计算PET、拟合三参数log-logistic分布以及标准化转换的核心算法,并提供了模块化代码和可视化方案,帮助用户构建可复用的干旱分析工具。

cola5的博客 265

rocketmq怎么保证消息一致性_SpringCloud集成RocketMQ实现可靠消息最终一致性分布式事务方案...

1.什么是可靠消息最终一致性事务​ 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。​ 此方案是利用消息中间件完成,如下图:​ 事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务发起方和消息中间件之间,事务参与方(消息消费方)和消息...

weixin_39669701的博客 299

山景BP10_128DBG开发板通过蓝牙连接手机放歌实验回顾

最近在学习上海山景公司的BP10_128DBG的开发板,因为网上关于BP10开发板的帖子也比较少,在学习的时候也没有太多的参考资料,基本上都是官方的历程。蓝牙放歌这个demo对我来说也比较复杂,特写下此博客进行记录、总结,大家有需要的可以参考。

weixin_56646002的博客 2015

分布式事务解决方案-RocketMQ实现可靠消息最终一致性

1.什么是可靠消息最终一致性事务 ​ 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。 ​ 此方案是利用消息中间件完成,如下图: ​ 事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务发起方和消息中间件之间,事务参与方(消息消费方)和消息中间件之间都是通过网络通信,由于网络通信的不确定性会导致分布式事务问题。 因此可靠..

z69183787的专栏 1096

深入CARLA地图底层:OpenDRIVE文件如何影响你的仿真效果与避坑指南

本文深入解析CARLA仿真中OpenDRIVE地图文件的核心作用,揭示其如何影响车道连接、交通规则和导航逻辑。通过实战案例和代码示例,提供五大典型地图问题的诊断与修复方案,帮助开发者优化仿真效果并规避常见陷阱。

weixin_34180452的博客 271

LLM制造业最佳实践:基于大语言模型处理最优化问题,制造业如何更优排产,提升资源利用率

随着制造业数字化转型加速,生产排产优化成为提升企业效率和竞争力的关键环节。大语言模型(LLM)凭借其强大的多模态数据处理、动态优化和智能推理能力,在复杂排产场景中展现出独特优势。谷歌、DeepSeek等机构的研究表明,LLM可通过自然语言交互和生成式决策,突破传统优化算法的局限性。本报告结合半导体行业实践案例与技术路径,系统分析LLM在排产优化中的应用潜力与挑战。

shiter编写程序的艺术 923

rocketmq 重复消费_SpringCloud集成RocketMQ实现可靠消息最终一致性分布式事务方案...

1.什么是可靠消息最终一致性事务​ 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。​ 此方案是利用消息中间件完成,如下图:​ 事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务发起方和消息中间件之间,事务参与方(消息消费方)和消息...

weixin_39944515的博客 399

2023年全国职业院校技能大赛“信息安全管理与评估”-真题——赛题题目+答案解析

2023年全国职业院校技能大赛“信息安全管理与评估”-真题——赛题题目+答案解析

君逍遥o 5973

rocketmq怎么保证消息一致性_分布式事务解决方案-RocketMQ实现可靠消息最终一致性...

1.什么是可靠消息最终一致性事务​ 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。​ 此方案是利用消息中间件完成,如下图:​ 事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务发起方和消息中间件之间,事务参与方(消息消费方)和消息...

weixin_42150745的博客 595

黑猫带你学eMMC协议第1篇:全网最全emmc协议中文详讲,这份学习框架图,你值得拥有!!!(持续更新中...)

黑猫带你学eMMC协议第7篇:全网最全emmc写保护详解(write protect) 黑猫带你学eMMC协议第8篇:emmc可靠写详解(Write Reliability) 黑猫带你学eMMC协议第9篇:emmc的分区配置(partitioning) 黑猫带你学eMMC协议第10篇:eMMC命令队列详解(CMDQ) 黑猫带你学eMMC协议第11篇:eMMC擦除详解(erase/trim/discard/sanitize/secure erase/secure trim…) 黑猫带你学eMMC协议第12篇:

黑猫奥利奥的博客 2万+

超级全的PCB LAYOUT高速信号走线指南——简化应用版

在PCB Layout中,几乎涵盖了所有的高速信号走线指南。包括了TF/SD、HDMI、LVDS、DVP、eDP、MIPI、USB2.0、USB3.0、MAC、BT.1120、PCIE高速信号等等。此版本为简化版。

bhxc809751502的博客 8541

dubbo分布式事务解决方案_分布式事务解决方案-RocketMQ实现可靠消息最终一致性...

1.什么是可靠消息最终一致性事务​ 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。​ 此方案是利用消息中间件完成,如下图:​ 事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务发起方和消息中间件之间,事务参与方(消息消费方)和消息...

weixin_39632212的博客 251

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

最大努力通知【分布式事务解决方案】

【1】账户系统调用充值系统接口;【2】充值系统完成支付处理向账户系统发起充值结果通知,若通知失败,则充值系统按策略进行重复通知;【3】账户系统接收到充值结果通知修改充值状态[实时性与数据一致性可以延迟];【4】账户系统未接收到通知会主动调用充值系统的接口查询充值结果[当用户查询状态时,状态为失败时,回查充值系统]发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括:【1】有一定的消息重复通知机制。因为接收通知方可能没有接收到通知,此时要有一定的机制对消息重复通知。

程序猿进阶 2050

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

分布式事务(4)可靠消息最终一致性

1 可靠消息最终一致性事务的基本概念 2 问题产生分析 2.1 本地事务与消息发送的原子性问题 2.2 事务参与方接收消息的可靠性 2.3 消息重复消费的问题 3 解决方案 3.1 本地消息表方案 3.2 RocketMQ事务消息方案 4 RocketMQ实现可靠消息最终一致性事务 demo 4.1 demo组成说明 4.2 创建数据库 5.3.4.启动RocketMQ 3.3.5 导入distribution-tx 5.3.8 测试场景 4.2 小结 5 可靠消息最终一致性事务应用场景

michael_linux的博客,一个小小小学生。滴水穿石,步步为营,只为那刹那芳华。 1369

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

java分布式事务——最终一致性,最大努力通知总结!

关于CAP,BASE理论,以及TCC,seata解决方案,可以参考我上一篇博客https://blog.csdn.net/zhangkaixuan456/article/details/108210071 4.分布式事务解决方案之可靠消息最终一致性 4.1.什么是可靠消息最终一致性事务 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息...

zhangkaixuan456的博客 1311

分布式事务总结

​ 通过上面我们已经学习了CAP理论的相关知识,CAP是一个已经被证实的理论:一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容忍性(Partition tolerance)这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。

lastingboy的博客 2941

可靠消息最终一致性【本地消息表、RocketMQ 事务消息方案】

一、可靠消息最终一致性事务概述 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。 此方案是利用消息中间件完成,如下图: 事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务参与方(消息消费方)和消息中间件之间都是通过网络通信,由于网络通信的不确定性会导致分布式事务问题。因此可靠消息最终一致性方案要解决以下几个问题: 【1】本地事务与消息发送

程序猿进阶 1553

分布式事务解决方案之可靠消息最终一致性

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能 够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。此方案是利用消息中间件完成,如下图:\事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,事务发起方和消息中间件 之间,事务参与方(消息消费方)和消息中间件之间都是通过网络通信,由于网络通信的不确定性会导致分布式事 务问题。1.本地事务与消息发送的原子性问题。

LU58542226的博客 762

【进阶之路】可靠消息最终一致性解决方案

导言 大家好,我是南橘,从接触java到现在也有差不多两年时间了,两年时间,从一名连java有几种数据结构都不懂超级小白,到现在懂了一点点的进阶小白,学到了不少的东西。知识越分享越值钱,我这段时间总结(包括从别的大佬那边学习,引用)了一些平常学习和面试中的重点(自我认为),希望给大家带来一些帮助 这是消息中间件的文章,大家没有看过的可以跟着看一下 【进阶之路】消息队列——原理及选型(一) 【...

南橘Home 2474

可靠消息最终一致性分布式事务解决方案

之前文章写过主流的一些,但其实工作中很少有一些高并发的业务中去使用这些方案,因为对于高并发的场景来说,引入这些方案的性能损耗太大,且对系统事务侵入性太强影响系统稳定性。所以在高并发的业务中,如果对实时性可以容忍秒级的延迟,那么使用最终一致性事务方案是最合适的选择。

WannaRunning的博客 1357

《深入理解分布式事务》第九章 可靠消息最终一致性分布式事务原理

《深入理解分布式事务》第九章 可靠消息最终一致性分布式事务原理

2022年毕业的萌新程序猿,输出一下自己的学习内容~ 724
上一篇: 分布式事务基础理论
下一篇: Java High Level RESRT Client API 入门级操作Elasticsearch
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值