分布式事务的解决方案（技术篇2-7-1）

江南的架构笔记
179 阅读4分钟

本地事务

  • 分布式事务：服务：CAP理论:

    CAP理论，又叫做CAP原则，网上对他的概念描述非常的清晰，且一致。换句话说，我们在网上搜到的CAP理论的描述，基本都是一样的。它的描述是这样的：CAP指的是在一个分布式系统中，一致性（Consistency）、可用性Availability）、分区容错性（Partitiontolerance）。其中，C,A,P的说明如下：
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端]的读写请求。（对数据更新具备高可用性）
分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。```

  • 分布式事务：BASE理论：

BASE理论是指，Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最
终一致性）。
1、基本可用 BA：（Basically Available ）：
指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5
秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。简单来说就是基
本可用。
2、软状态 S：（ Soft State）：
软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步
的时候存在延时。简单来说就是状态可以在一段时间内不同步。
3、最终一致性 E：（Eventually Consistent ）：

分布式事务解决方案

  • 二阶段提交： -具体的实现：atomikos,  mybaitplus中@DS。应用领域：单体应用对应多个数据源的情况。

    • 缺点：所有事务都到齐之后才能提交，严重的影响性能；而且一个事务有问题则会导致其他事务都异常。
    • 目前已经越来越淡出分布式事务的解决方案。

  • TCC事务：

    • try|commit| cancel

  • 最终一致性

分布式事务的二阶段提交：

  • atomikos

分布式事务实战- 事务消息：RocketMQ

  • 支持事务的MQ: activeMQ, RocketMQ
  • 使用RocketMQ的示意图：

image.png

  • RocketMQ事务消息执行流程图 image.png
  • rocket消息事务的原理介绍： image.png
  • 重要代码实现赏析：
    • RocketMQ监听器事务提交|回滚实现：
    • 对于RocketMQ来讲：事务就3个状态：1正在执行；2执行成功；3执行失败 image.png
    • RocketMQ的监听器回查方法实现：

image.png

  • RocketMQ发送消息：
    image.png
  • RokcetMQ接收消息：
    image.png

附录：

问题思考：

  • 1，发送方本地事务成功，rocketMQ的监听器异常，则mq不会提交数据，但是发送方的本地数据库数据状态已经被更改，此问题如何解决？
    答：引入数据对冲的概念，当本地事务成功，但是mq监听器异常之后，则异常处理中将本地事务提交的数据进行回滚。
    由此可见RocketMQ也是TCC的一种实现方案，只是没有Seata的方案完善而已。

  • 2，发送方本地事务成功，rocketMQ正常commit数据，消费者接收到数据之后消费数据失败，此时如何解决？
    答：消费方人工将异常数据重试。保证消费方的数据必须消费成功。
    或者使用定时任务处理。
    重试机制在MQ中存在，需要消费方做好消息的幂等性处理机制就可以。
    对于此种情况，消费方消费失败,也可以将消息写回到MQ中，让生成者进行消息对冲,但对于多个微服务来讲就太麻烦了，一般不这样做，而是采用Seata的本身消息表去实现

  • 3,rocketMq的unknown机制，如果是unknown后进行检查，如果检查结果还是unknown则会放到人工干预队列，此处需要自己写代码实现。可以放到另一个队列进行人工干预？但是此中情况一般不出现（可能是网络异常，MQ也没办法）。

avatar
文章
阅读
粉丝