【建议收藏】高并发下的分布式事务:如何选择最优方案?

简介: 本文介绍了分布式事务的三种常见解决方案。在分布式系统中,事务处理变得复杂,需确保ACID特性。TCC(Try-Confirm-Cancel)方案适用于严格资金要求的场景,如银行转账,通过预留、确认和取消步骤确保一致性。可靠消息最终一致性方案适合一致性要求较低的场景,如电商积分处理,通过消息中间件实现最终一致性。最大努力通知方案则用于允许不一致的场景,如数据分析,通过重复通知尽可能达成一致性。选择合适的方案取决于具体应用场景。



Hello,大家好!我是你们的技术小伙伴小米,今天我们一起来聊一聊“分布式事务”这个话题。最近收到不少朋友的留言,说在实际项目中遇到了分布式事务的问题,尤其是在选择合适的方案上感到困惑。今天我就来和大家分享一下常见的分布式事务解决方案,以及它们在不同场景下的应用。

分布式事务概述

在分布式系统中,事务的处理相较于单体应用要复杂得多。由于数据分散在不同的节点上,要确保事务的ACID特性(原子性、一致性、隔离性、持久性)就变得非常困难。为了解决这个问题,业界提出了多种分布式事务解决方案,每种方案都有其适用的场景。

严格资金要求场景:TCC 方案

首先,我们来看一个严格资金要求的场景,例如银行转账系统。在这个场景中,任何错误都会导致严重的后果,因此我们需要一种能够保证绝对一致性的事务处理方案。

什么是 TCC?

TCC(Try-Confirm-Cancel)是一种比较严格的分布式事务解决方案,它将一个事务分为三个阶段:

  • Try 阶段:预留资源或者预处理业务逻辑。
  • Confirm 阶段:确认并提交事务。
  • Cancel 阶段:在出现错误时回滚事务。

实战案例:银行转账

假设我们要实现一个跨行转账的功能,涉及到A银行和B银行的两个独立系统。转账过程中需要确保两边的资金变化是完全一致的。

  • Try 阶段:在A银行冻结转出账户的资金,在B银行预留转入账户的额度。
  • Confirm 阶段:A银行扣减转出账户的资金,B银行增加转入账户的余额。
  • Cancel 阶段:在任意阶段失败时,A银行解冻资金,B银行取消额度预留。

这种方案通过明确的预留、确认和取消步骤,确保了资金操作的绝对一致性。

一般分布式事务场景:可靠消息最终一致性方案

对于一些一致性要求稍低的场景,例如电商系统中的积分处理,我们可以选择可靠消息最终一致性方案。这种方案相对TCC来说,性能开销较小,更加适合高并发环境。

什么是可靠消息最终一致性?

可靠消息最终一致性是通过消息中间件实现的一种方案,其基本思路是:

  • 消息发送:在业务操作成功后发送一条消息。
  • 消息消费:消费者接收到消息后,执行相应的业务操作。
  • 消息确认:消费者处理成功后,确认消息已经被处理。

实战案例:电商积分处理

假设用户在电商平台上完成了一笔订单,我们需要给用户增加相应的积分。

  • 订单服务:订单服务在订单成功后,发送一条增加积分的消息到消息中间件。
  • 积分服务:积分服务接收到消息后,增加用户的积分,并确认消息处理成功。
  • 消息重试:如果积分服务处理失败,消息中间件会自动重试,直到消息被成功处理。

通过这种方式,我们可以确保在高并发环境下,积分数据最终达到一致。

允许不一致场景:最大努力通知方案

在某些场景下,业务对一致性的要求较低,允许存在一定的不一致性。例如在一些数据分析系统中,实时性和一致性要求并不高,此时可以采用最大努力通知方案。

什么是最大努力通知?

最大努力通知是一种相对简单的方案,它通过尽可能多的通知来达到一定的一致性:

  • 事件触发:业务操作完成后,触发通知。
  • 重复通知:在一定时间内,重复发送通知,尽可能保证接收方处理。
  • 超时放弃:超过设定时间后,放弃通知。

实战案例:数据分析系统

假设我们有一个用户行为数据分析系统,需要收集用户的点击行为。

  • 行为记录:用户点击行为发生后,记录行为数据,并触发通知发送到数据分析系统。
  • 数据分析系统:接收到通知后,处理用户行为数据。
  • 重复通知:如果数据分析系统未及时处理,系统会在一定时间内重复发送通知。

这种方案虽然不能保证每次行为数据都被记录,但对于大多数数据分析场景来说,已经足够。

END

在分布式系统中,选择合适的事务处理方案至关重要。不同的方案有其适用的场景和优势:

  • TCC 方案:适用于严格资金要求的场景,保证绝对一致性。
  • 可靠消息最终一致性方案:适用于一般分布式事务场景,保证最终一致性。
  • 最大努力通知方案:适用于允许不一致的场景,保证尽可能一致。

希望今天的分享能对大家有所帮助,如果你在实际项目中遇到分布式事务的问题,欢迎留言或私信,我会尽力解答你的疑惑!

记得关注小米的公众号,获取更多技术分享哦!

我们下期见,拜拜~

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

相关文章
|
2月前
|
消息中间件 Java Linux
2024年最全BATJ真题突击:Java基础+JVM+分布式高并发+网络编程+Linux(1),2024年最新意外的惊喜
2024年最全BATJ真题突击:Java基础+JVM+分布式高并发+网络编程+Linux(1),2024年最新意外的惊喜
|
2月前
|
存储 NoSQL Java
分布式锁中的王者方案 - Redission
分布式锁中的王者方案 - Redission
49 1
|
9天前
|
消息中间件 缓存 监控
如何设计一个秒杀系统,(高并发高可用分布式集群)
【7月更文挑战第4天】设计一个高并发、高可用的分布式秒杀系统是一个非常具有挑战性的任务,需要从架构、数据库、缓存、并发控制、降级限流等多个维度进行考虑。
23 1
|
13天前
|
存储 NoSQL Java
探索Java分布式锁:在高并发环境下的同步访问实现与优化
【6月更文挑战第30天】Java分布式锁在高并发下确保数据一致性,通过Redis的SETNX、ZooKeeper的临时节点、数据库操作等方式实现。优化策略包括锁超时重试、续期、公平性及性能提升,关键在于平衡同步与效率,适应大规模分布式系统的需求。
25 1
|
16天前
|
NoSQL 算法 Java
技术好文:Redis实现分布式锁的7种方案
技术好文:Redis实现分布式锁的7种方案
|
3天前
|
设计模式 安全 NoSQL
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
8 0
|
3天前
|
设计模式 存储 缓存
Java面试题:结合建造者模式与内存优化,设计一个可扩展的高性能对象创建框架?利用多线程工具类与并发框架,实现一个高并发的分布式任务调度系统?设计一个高性能的实时事件通知系统
Java面试题:结合建造者模式与内存优化,设计一个可扩展的高性能对象创建框架?利用多线程工具类与并发框架,实现一个高并发的分布式任务调度系统?设计一个高性能的实时事件通知系统
9 0
|
1月前
|
消息中间件 存储 运维
轻量级分布式事务实现:掌握最大努力通知方案
本文介绍了分布式事务的重要概念,特别是最大努力通知方案。最大努力通知是一种基于消息通知的分布式事务处理方式,通过异步通知确保最终一致性。方案包括事务消息发送、消息中间件持久化和最大努力通知三个步骤。虽然它实现简单、性能高且灵活,但可能无法保证强一致性,且存在重试和人工干预的成本。文中还提供了一个电商订单与库存系统同步的案例,并分析了该方案的优缺点。
29 1
|
12天前
|
存储 NoSQL Java
探索Java分布式锁:在高并发环境下的同步访问实现与优化
【7月更文挑战第1天】在分布式系统中,Java分布式锁解决了多节点共享资源的同步访问问题,确保数据一致性。常见的实现包括Redis的SETNX和过期时间、ZooKeeper的临时有序节点、数据库操作及Java并发库。优化策略涉及锁超时、续期、公平性及性能。选择合适的锁策略对高并发系统的稳定性和性能至关重要。
28 0
|
1月前
|
canal 缓存 关系型数据库
高并发场景下,6种方案,保证缓存和数据库的最终一致性!
在解决缓存一致性的过程中,有多种途径可以保证缓存的最终一致性,应该根据场景来设计合适的方案,读多写少的场景下,可以选择采用“Cache-Aside结合消费数据库日志做补偿”的方案,写多的场景下,可以选择采用“Write-Through结合分布式锁”的方案,写多的极端场景下,可以选择采用“Write-Behind”的方案。
207 0