简单高效!本地消息表助你轻松实现分布式事务

简介: 本文由小米分享,介绍如何使用本地消息表解决分布式事务问题。分布式事务在微服务架构中变得复杂,本地消息表提供了一种简单高效的方法。它通过在同一事务中处理业务操作和消息记录,然后异步发送消息,确保数据一致性。文章详细阐述了本地消息表的原理、实现步骤、优势及不足,强调了其实现的简单性、高性能和高可靠性,但也指出其潜在的开发复杂度和延迟性问题。



Hello,大家好!我是小米,一个热爱技术的29岁程序员,今天我们来聊聊分布式系统中的一个关键问题——分布式事务。作为技术人,你是否曾经因为分布式事务的问题而头疼不已呢?今天我就和大家分享一下,如何通过本地消息表来优雅地解决分布式事务问题。

什么是分布式事务?

在单体应用中,事务管理相对简单,通过数据库的ACID特性(原子性、一致性、隔离性、持久性)来确保数据的一致性。然而,随着业务的发展,系统架构逐渐演变为微服务架构,多个服务之间需要协同工作。这时候,事务管理变得复杂起来,因为数据操作分布在不同的服务和数据库上。

分布式事务是指跨多个独立的数据源或服务的事务。它需要确保所有参与的操作要么全部成功,要么全部回滚,以保证数据的一致性。

常见的分布式事务解决方案

在讨论本地消息表之前,我们先了解一下常见的分布式事务解决方案:

1. 二阶段提交(2PC)

二阶段提交协议是经典的分布式事务协议,分为准备阶段和提交阶段。在准备阶段,协调者向所有参与者询问是否可以提交事务,如果所有参与者都同意,进入提交阶段;否则,进入回滚阶段。

虽然2PC可以保证事务的一致性,但它存在一些问题:

  • 性能开销大:准备阶段和提交阶段需要两次网络通信,增加了延迟。
  • 单点故障:协调者的故障会导致整个事务挂起。
  • 锁定资源:在准备阶段,参与者会锁定资源,影响系统的并发性。

2. 三阶段提交(3PC)

三阶段提交协议是对二阶段提交的改进,增加了一个预提交阶段,以减少单点故障和提高系统的容错性。但它仍然存在性能开销大和实现复杂度高的问题。

3. TCC(Try-Confirm/Cancel)

TCC模型将事务分为三个阶段:

  • Try阶段:预留资源
  • Confirm阶段:确认执行
  • Cancel阶段:取消执行

TCC比2PC更灵活,但需要业务层面实现补偿逻辑,增加了开发成本。

4. 本地消息表

接下来,我们重点介绍一种比较简单、实用且高效的解决方案——本地消息表。

本地消息表的原理

本地消息表是一种通过在本地数据库中记录消息状态来实现分布式事务的方法。其核心思想是将业务操作和消息记录放在同一个本地事务中,确保它们要么同时成功,要么同时失败。然后,通过一个独立的消息调度器异步地将消息发送到消息队列中,从而实现跨服务的事务一致性。

具体流程如下:

  • 业务操作与消息记录:在同一个本地事务中,完成业务操作并将消息记录插入本地消息表。
  • 消息调度器:一个独立的消息调度器不断扫描本地消息表,找到需要发送的消息,并将其发送到消息队列。
  • 消费消息:其他服务从消息队列中消费消息,并执行相应的业务操作。

通过这种方式,我们将跨服务的分布式事务问题转化为本地事务问题,利用本地数据库的ACID特性,确保业务操作和消息记录的一致性。

本地消息表的实现步骤

下面我们详细介绍一下本地消息表的具体实现步骤:

1. 创建本地消息表

首先,在数据库中创建一张消息表,用于记录需要发送的消息。例如:

这张表包含以下字段:

  • id:消息的唯一标识
  • message_content:消息的内容
  • status:消息的状态(NEW, SENT, FAILED)
  • created_at:消息的创建时间
  • updated_at:消息的更新时间

2. 业务操作与消息记录放在同一个事务中

在进行业务操作时,将消息记录插入本地消息表。例如,在订单服务中创建订单时:

通过使用@Transactional注解,确保业务操作和消息记录在同一个本地事务中执行。

3. 消息调度器

消息调度器是一个独立的组件,它不断扫描本地消息表,找到需要发送的消息,并将其发送到消息队列。例如:

这里使用Spring的@Scheduled注解,每隔5秒执行一次消息发送任务。首先,从本地消息表中查找状态为NEW的消息,然后将消息发送到消息队列。如果发送成功,更新消息状态为SENT;如果发送失败,更新消息状态为FAILED

4. 消费消息

其他服务从消息队列中消费消息,并执行相应的业务操作。例如,在库存服务中,消费订单创建的消息,进行库存扣减:

通过消息队列,实现了跨服务的异步通信和事务一致性。

本地消息表的优势

本地消息表解决方案相比于其他分布式事务解决方案,有以下几个显著的优势:

  • 简单易实现:本地消息表基于数据库的本地事务,不需要引入复杂的分布式事务协议,降低了实现难度。
  • 高性能:业务操作和消息记录在同一个本地事务中执行,避免了跨网络通信的开销,提高了系统性能。
  • 高可靠性:通过独立的消息调度器,确保消息最终一定会发送到消息队列,即使发生网络故障或服务重启,也不会丢失消息。

本地消息表的不足

当然,本地消息表也有一些不足之处:

  • 开发复杂度:需要手动实现消息调度器和消息表的管理逻辑,增加了开发工作量。
  • 延迟性:由于消息发送是异步进行的,可能会有一定的延迟,对于实时性要求较高的场景,需要额外优化。
  • 消息幂等性:需要确保消息的幂等性,避免重复消费造成数据不一致。

END

通过本地消息表,我们可以优雅地解决分布式事务中的数据一致性问题。它简单易实现,性能高且可靠性强,是一种非常实用的分布式事务解决方案。当然,它也有一些不足,需要在具体应用中根据实际需求进行权衡和优化。

希望今天的分享能对大家有所帮助!如果你有任何问题或想法,欢迎在评论区留言,我们一起交流探讨。

本文作者:小米,一个热爱技术分享的29岁程序员。如果你喜欢我的文章,欢迎关注我的微信公众号软件求生,获取更多技术干货!

相关文章
|
1月前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
3月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
5月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
140 2
基于Redis的高可用分布式锁——RedLock
|
5月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
1月前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
103 5
|
2月前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
70 8
|
2月前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
61 16
|
2月前
|
缓存 NoSQL PHP
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
46 5
|
3月前
|
缓存 NoSQL Java
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
78 3
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
|
3月前
|
NoSQL Redis 数据库
计数器 分布式锁 redis实现
【10月更文挑战第5天】
56 1