命运交织的节点：分布式事务最终一致性的心跳共鸣纪实

2024-05-10 01:52
文章标签 分布式 节点 事务 一致性 最终 心跳 纪实 共鸣 命运 交织

本文主要是介绍命运交织的节点：分布式事务最终一致性的心跳共鸣纪实，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

关注微信公众号 “程序员小胖” 每日技术干货，第一时间送达！

引言

在当今云计算和微服务架构大行其道的时代，分布式系统成为了构建高可用、高性能应用的基石。然而，随着系统规模的扩张，数据的一致性问题如同幽灵般萦绕在每位架构师心头，尤其是分布式事务处理中的挑战更是首当其冲。今天，让我们一起深入探索分布式事务模型中的“最终一致性”，揭开它那既神秘又强大的面纱。

分布式事务的挑战与背景

想象一下双十一购物节，数百万用户同时下单，订单系统、库存系统、支付系统等多个服务间需要协同完成交易。采用最终一致性模型，即使瞬间请求激增导致部分操作延迟，系统也能确保在合理的时间框架内调整库存、确认订单状态，从而维持整体业务流程的顺畅。

最终一致性？

在分布式系统中，最终一致性是一种事务模型，它保证系统中的所有数据副本最终会达到一致的状态，但不保证立即的一致性。这种模型允许在数据复制过程中存在短暂的不一致状态，但随着时间的推移，系统会通过各种机制确保数据最终达到一致。

实现策略

补偿事务（TCC）

TCC，即Try-Confirm-Cancel，是一种通过预先定义的确认和取消操作来保证事务最终一致性的模式。

**Try 阶段：**调用 Try 接口，尝试执行业务，完成所有业务检查，预留业务资源。
Confirm 或 Cancel 阶段：两者是互斥的，只能进入其中一个，并且都满足幂等性，允许失败重试。

**Confirm 操作：**对业务系统做确认提交，确认执行业务操作，不做其他业务检查，只使用 Try 阶段预留的业务资
源。

**Cancel 操作：**在业务执行错误，需要回滚的状态下执行业务取消，释放预留资源。

转账场景示例：


//Account类代表一个账户，拥有冻结、解冻、存款和取款的方法。Money类代表金额。
public class AccountService {// Try阶段：检查账户余额并冻结资金public boolean prepareTransfer(Account source, Account target, Money amount) {if (source.getBalance() < amount) {return false; // 余额不足}source.freeze(amount); // 冻结资金return true;}// Confirm阶段：实际转账操作public void confirmTransfer(Account source, Account target, Money amount) {source.withdraw(amount); // 从源账户扣除金额target.deposit(amount); // 向目标账户增加金额}// Cancel阶段：回滚操作，解冻资金public void cancelTransfer(Account source, Account target, Money amount) {source.unfreeze(amount); // 解冻资金}
}

注意事项

**幂等性：**确保Try、Confirm和Cancel操作都是幂等的，以支持重复执行而不会引起副作用。

**空回滚：**系统应能够处理“空回滚”的情况，即Cancel操作被调用，但Try操作并未实际执行。

**防悬挂：**确保系统能够处理悬挂操作，即Try操作在网络延迟后到达，而Cancel操作已经执行。

本地消息表

本地消息表的方案最初是由 ebay 的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理，通过消息日志的方式来异步执行。本地消息表是一种业务耦合的设计，消息生产方需要额外建一个事务消息表，并记录消息发送状态，消息消费方需要处理这个消息，并完成自己的业务逻辑，另外会有一个异步机制来定期扫描未完成的消息，确保最终一致性。

实战代码示例：

  1. 系统收到下单请求，将订单业务数据存入到订单库中，并且同时存储该订单对应的消息数据，比如购买商品的 ID 和数量，消息数据与订单库为同一库，更新订单和存储消息为一个本地事务，要么都成功，要么都失败。
   @Servicepublic class OrderService {@Resourceprivate OrderMapper orderMapper;@Resourceprivate OrderMessageMapper orderMessageMapper;@Autowiredprivate MessageProducer messageProducer; // 消息队列的发送器@Transactionalpublic void placeOrder(Order order, OrderMessage orderMessage) {// 将订单业务数据存入到订单库中int orderRows = orderMapper.insert(order);// 同时存储该订单对应的消息数据int messageRows = orderMessageMapper.insert(orderMessage);// 确保订单和消息数据都成功插入if (orderRows == 1 && messageRows == 1) {// 发送库存更新消息到消息队列messageProducer.sendMessage(orderMessage);} else {// 如果任何插入失败，抛出异常以回滚事务throw new RuntimeException("Order or message data insertion failed");}}}
  1. 库存服务更新
    @Autowiredprivate InventoryDomainService inventoryDomainService;@Overridepublic boolean consume(MqMessageEntity<OrderMessage> mqMessageEntity) {log.info("接收订单支付完成请求，扣件库存:{}", JSON.toJSONString(mqMessageEntity));return inventoryDomainService.deductionInventory(mqMessageEntity);}
  1. 订单服务更新本地消息表
        @Autowiredprivate OrderMessageMapper orderMessageMapper;public void sendMessage(OrderMessage orderMessage) {// 向消息队列发送库存更新消息// 消息发送成功的回调中更新本地消息表状态orderMessageMapper.upodateMessageStatus(orderMessage);}
  1. 异步任务重试机制
    使用Spring的@Scheduled注解来定时触发异步任务。这个地方用任何调度计划都可以实现 我用的是spring自带的@Scheduled注解实现的。异步技术也可以根据自己的情况选择。

@Component
public class MessageRetryScheduler {@Autowiredprivate MessageProducer messageProducer;@Scheduled(fixedRate = 60000) // 每60秒执行一次public void scheduleMessageRetry() {messageProducer.scanAndRetryUnsentMessages();}
}@Autowiredprivate OrderMessageMapper orderMessageMapper;@Asyncpublic void scanAndRetryUnsentMessages() {List<OrderMessageDO> unsentMessages = orderMessageMapper.queryByStatus("PENDING");for (OrderMessage message : unsentMessages) {try {sendMessage(message); // 重试发送消息orderMessageMapper.updateStatus(message);} catch (Exception e) {// 可以选择更新状态为错误或其他逻辑orderMessageMapper.updateStatus(message);}}}

RocketMQ 事务消息

RocketMQ 事务消息是一种支持分布式事务的消息。它通过引入 prepare、commit 和 rollback 三个阶段，来确保事务消息的一致性。

**prepare 阶段：**消息发送方发送半消息，此时消息的状态为“待提交”。

**commit 阶段：**消息发送方向 RocketMQ 发送 commit 消息请求，RocketMQ 判断此时半消息是否被确认，如果半消息已被确认，则将消息标记为“可消费”并提交事务。如果半消息未被确认，则将消息标记为“不可消费”并终止事务。

**rollback 阶段：**消息发送方向 RocketMQ 发送 rollback 消息请求，RocketMQ 将半消息标记为“不可消费”并回滚
事务。


代码示例：

创建并初始化一个事务消息生产者：

import org.apache.rocketmq.client.producer.LocalTransactionState;
import org.apache.rocketmq.client.producer.TransactionListener;
import org.apache.rocketmq.client.producer.TransactionMQProducer;
import org.apache.rocketmq.common.message.Message;import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;public class TransactionProducer {public static void main(String[] args) throws Exception {// 实例化消息生产者，并指定NameServer地址TransactionMQProducer producer = new TransactionMQProducer("please_rename_unique_group_name");producer.setNamesrvAddr("localhost:9876");// 指定事务监听器producer.setTransactionListener(new TransactionListener() {@Overridepublic LocalTransactionState executeLocalTransaction(Message msg, Object arg) {// 执行本地事务逻辑，例如数据库操作// 假设执行成功，返回Commit状态return LocalTransactionState.CommitMessage;}@Overridepublic LocalTransactionState checkLocalTransaction(Message msg) {// 检查本地事务状态，确认是否需要提交或回滚// 这里可以根据业务逻辑来实现检查// 假设检查通过，返回Unknown状态，让消息服务决定是提交还是回滚return LocalTransactionState.Unknown;}});// 启动生产者producer.start();// 创建消息Message msg = new Message("TopicTest", "TagA", "Hello RocketMQ".getBytes());// 发送事务消息SendResult sendResult = producer.sendMessageInTransaction(msg, null);System.out.printf("%s%n", sendResult);// 关闭生产者producer.shutdown();}
}

在代码示例中我们实现了TransactionListener接口的两个方法：

**executeLocalTransaction：**执行本地事务逻辑，返回事务状态。如果本地事务执行成功，返回CommitMessage；如果执行失败，返回RollbackMessage。

**checkLocalTransaction：**检查本地事务状态。如果事务状态未知，返回Unknown，让消息队列服务决定是提交还是回滚消息。

最大努力通知

最大努力通知型( Best-effort delivery)是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低
的业务，且被动方处理结果 不影响主动方的处理结果。典型的使用场景：如银行通知、商户通知等。
最大努力通知型的实现方案，一般符合以下特点：

  1. 不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。
  2. 定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息

代码示例：

发送通知

@Service
public class NotificationService {@Autowiredprivate RabbitTemplate rabbitTemplate;public void sendNotification(String message) {// 发送通知消息到MQrabbitTemplate.convertAndSend("notificationExchange", "notificationRoutingKey", message);}
}

监听消息并处理

@Component
public class NotificationListener {@RabbitListener(queues = "notificationQueue")public void handleNotification(String message) {// 处理消息，例如更新库存processNotification(message);// 确认消息已处理acknowledgeMessage();}private void processNotification(String message) {// 业务逻辑处理}private void acknowledgeMessage() {// 向发送方确认消息已处理的逻辑}
}

重试机制通常由消息中间件提供，如RabbitMQ的死信队列和重试策略。校对机制可能需要额外的接口和逻辑来实现。

结语

最终一致性作为分布式系统中一种重要的事务处理哲学，它在实践中展现出了强大的生命力。然而，没有银弹存在，每种模型都有其适用场景与局限。作为技术探索者，我们应当持续思考如何更精细地控制一致性级别，结合业务特性量体裁衣，设计出既能满足业务需求又能保持系统弹性的解决方案。那么，您在实际项目中遇到过哪些分布式事务的挑战？对于最终一致性模型又有何独到见解或疑问呢？欢迎留言讨论，共同推进技术的边界。

这篇关于命运交织的节点：分布式事务最终一致性的心跳共鸣纪实的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/975106。

相关文章

【前端学习】AntV G6-08 深入图形与图形分组、自定义节点、节点动画（下）

【前端学习】AntV G6-08 深入图形与图形分组、自定义节点、节点动画（下）

【课程链接】 AntV G6：深入图形与图形分组、自定义节点、节点动画（下）_哔哩哔哩_bilibili 本章十吾老师讲解了一个复杂的自定义节点中，应该怎样去计算和绘制图形，如何给一个图形制作不间断的动画，以及在鼠标事件之后产生动画。（有点难，需要好好理解） <!DOCTYPE html><html><head><meta charset="UTF-8"><title>06
阅读更多...
day-51 合并零之间的节点

day-51 合并零之间的节点

思路 直接遍历链表即可，遇到val=0跳过，val非零则加在一起，最后返回即可 解题过程 返回链表可以有头结点，方便插入，返回head.next Code /*** Definition for singly-linked list.* public class ListNode {* int val;* ListNode next;* ListNode() {}*
阅读更多...
Codeforces Beta Round #47 C凸包 （最终写法）

Codeforces Beta Round #47 C凸包 （最终写法）

题意慢慢看。 typedef long long LL ;int cmp(double x){if(fabs(x) < 1e-8) return 0 ;return x > 0 ? 1 : -1 ;}struct point{double x , y ;point(){}point(double _x , double _y):x(_x) , y(_y){}point op
阅读更多...
【每日一题】LeetCode 2181.合并零之间的节点（链表、模拟）

【每日一题】LeetCode 2181.合并零之间的节点（链表、模拟）

【每日一题】LeetCode 2181.合并零之间的节点（链表、模拟） 题目描述 给定一个链表，链表中的每个节点代表一个整数。链表中的整数由 0 分隔开，表示不同的区间。链表的开始和结束节点的值都为 0。任务是将每两个相邻的 0 之间的所有节点合并成一个节点，新节点的值为原区间内所有节点值的和。合并后，需要移除所有的 0，并返回修改后的链表头节点。 思路分析 初始化：创建一个虚拟头节点
阅读更多...
集中式版本控制与分布式版本控制——Git 学习笔记01

集中式版本控制与分布式版本控制——Git 学习笔记01

什么是版本控制 如果你用 Microsoft Word 写过东西，那你八成会有这样的经历： 想删除一段文字，又怕将来这段文字有用，怎么办呢？有一个办法，先把当前文件“另存为”一个文件，然后继续改，改到某个程度，再“另存为”一个文件。就这样改着、存着……最后你的 Word 文档变成了这样： 过了几天，你想找回被删除的文字，但是已经记不清保存在哪个文件了，只能挨个去找。真麻烦，眼睛都花了。看
阅读更多...
MySql 事务练习

MySql 事务练习

事务（transaction） -- 事务 transaction-- 事务是一组操作的集合，是一个不可分割的工作单位，事务会将所有的操作作为一个整体一起向系统提交或撤销请求-- 事务的操作要么同时成功，要么同时失败-- MySql的事务默认是自动提交的，当执行一个DML语句，MySql会立即自动隐式提交事务-- 常见案例：银行转账-- 逻辑：A给B转账1000：1.查询
阅读更多...
开源分布式数据库中间件

开源分布式数据库中间件

转自：https://www.csdn.net/article/2015-07-16/2825228 MyCat：开源分布式数据库中间件 为什么需要MyCat？ 虽然云计算时代，传统数据库存在着先天性的弊端，但是NoSQL数据库又无法将其替代。如果传统数据易于扩展，可切分，就可以避免单机（单库）的性能缺陷。 MyCat的目标就是：低成本地将现有的单机数据库和应用平滑迁移到“云”端
阅读更多...
Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

在 Redis 中，Lua 脚本具有原子性是因为 Redis 保证在执行脚本时，脚本中的所有操作都会被当作一个不可分割的整体。具体来说，Redis 使用单线程的执行模型来处理命令，因此当 Lua 脚本在 Redis 中执行时，不会有其他命令打断脚本的执行过程。脚本中的所有操作都将连续执行，直到脚本执行完成后，Redis 才会继续处理其他客户端的请求。 Lua 脚本在 Redis 中原子性的原因
阅读更多...
JS和jQuery获取节点的兄弟，父级，子级元素

JS和jQuery获取节点的兄弟，父级，子级元素

原文转自http://blog.csdn.net/duanshuyong/article/details/7562423 先说一下JS的获取方法，其要比JQUERY的方法麻烦很多，后面以JQUERY的方法作对比。 JS的方法会比JQUERY麻烦很多，主要则是因为FF浏览器，FF浏览器会把你的换行也当最DOM元素。 <div id="test"><div></div><div></div
阅读更多...
MySQL中一致性非锁定读

MySQL中一致性非锁定读

一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(multi versionning)的方式来读取当前执行时间数据库中行的数据，如果读取的行正在执行DELETE或UPDATE操作，这是读取操作不会因此等待行上锁的释放。相反的，InnoDB会去读取行的一个快照数据 上面展示了InnoDB存储引擎一致性的非锁定读。之所以称为非锁定读，因
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2