`
yale
  • 浏览: 359904 次
  • 性别: Icon_minigender_1
  • 来自: 武汉
社区版块
存档分类
最新评论

替代分布式事务策略

 
阅读更多

由于数据量的巨大,现在大部分的Web应用都需要部署很多个数据库实例。这样,有时候某些操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性,经典的方法是使用两阶段事务提交(我的blog中已经提到过),现在MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了,开发者泪在其中的同时,却没有考虑分布式事务是否给系统带来了伤害。

 

分布式事务提供的原则保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下,分布式事务才能够顺利完成,只要有一个工作不正常,整个事务就不能完成。这样,系统的可用性就相当于参加分布式事务的各实例的可用性之积,实例越多,可用性下降越明显。从性能和可伸缩性角度看,首先是事务的总持续时间通常是各实例操作时间之和,因为一个事务中的各个操作通常是顺序执行的,这样事务的响应时间就会增加很多;其次是一般Web应用的事务都不大,单机操作时间也就几毫秒甚至不到1毫秒,一但涉及到分布式事务,提交时节点间的网络通信往返过程也为毫秒级别,对事务响应时间的影响也不可忽视。由于事务持续时间延长,事务对相关资源的锁定时间也相应增加,从而可能严重增加了并发冲突,影响到系统吞吐率和可伸缩性。

 

正是由于分布式事务有以上问题,在设计上就可以不采用分布式事务,而是通过其它途径来解决数据一致性问题。其中使用的最重要的技术就是消息队列和消息应用状态表。
举个例子。假设系统中有以下两个表:库存表、出入库明细表,其中库存表(记录商品当前库存、初期库存、末期库存),出入库明细表(记录每个商品出入的详细信息)这样,在进行一笔交易时,若使用事务,就需要对数据库进行以下操作:
事务开始;
插入数据到出入库明细表中;
更新库存表;
提交事务;

假设库存表和出入库明细表存储在不同的节点上,那么上述事务就是一个分布式事务。要消除这一分布式事务,将它拆分成两个子事务,一个写入数据到出入库明细表,一个更新库存表,这样做是不行的,因为有可能出入库明细表写入成功后,更新库存表失败,系统将不能恢复到一致状态。

 

解决方案是使用消息队列。如下所示,先启动一个事务,写入数据到出入库明细表后,并不直接去更新库存表,而是将要对库存表进行的更新插入到消息队列中。另外有一个异步任务轮询队列内容进行处理。

那么我们现在就需要将消息队列中的信息放到库存表中来提交第二个事务,提交成功后,再从消息队列中删除该消息。由于消息队列存储与库存表不在一起,可能还没来得及将应用过的消息从队列中删除时系统就出故障了。这时系统恢复后会重新应用一次这一消息,由于幂等性,应用多次也能产生正确的结果。

 

但实际情况下,消息很难具有幂等性,对某表执行一次和执行多次相同的sql语句(insert、update等语句)的结束显然是不一样的。解决这一问题的方法是使用另一个表记录已经被成功应用的消息,并且这个表使用与库存表相同的存储。

我们来仔细分析一下:
1、消息队列与出入库使用同一实例,因此第一个事务不涉及分布式操作;
2、新添加的表与库存表在同一个实例中,也能保证一致性;
3、第二个事务结束后,如果出故障,那么系统会重新从消息队列中取出这一消息,但通过新添加的表可以检查出来这一消息已经被应用过,跳过这一消息实现正确的行为;
4、最后将已经成功应用,且已经从消息队列中删除的消息从新添加的表中删除,可以将新添加的表保证在很小的状态(不清除也是可以的,不影响系统正确性)。由于消息队列与新添加的表在不同实例上,将对应新添加的表的记录删除之前可能出故障。一但这时出现故障,新添加的表中会留下一些垃圾内容,但不影响系统正确性,另外这些垃圾内容也是可以正确清理的。虽然由于没有分布式事务的强一致性保证,使用上述方案在系统发生故障时,系统将短时间内处于不一致状态。但基于消息队列和消息应用状态表,最终可以将系统恢复到一致。使用消息队列方案,解除了两个数据库实例之间的紧密耦合,其性能和可伸缩性是分布式事务不可比拟的。

 

当然,使用分布式事务有助于简化应用开发,使用消息队列明显需要更多的工作量,两者各有优缺点。个人观点是,对于时间紧迫或者对性能要求不高的系统,应采用分布式事务加快开发效率,对于时间需求不是很紧,对性能要求很高的系统,应考虑使用消息队列方案。对于原使用分布式事务,且系统已趋于稳定,性能要求高的系统,则可以使用消息队列方案进行重构来优化性能。

 

1
1
分享到:
评论
3 楼 guoshun0321 2014-07-23  
如果在第一次提交时,数据写入到消息队列后,如果由于网络故障,消息没有即使返回给应用程序,导致应用程序超时,整个应用回滚。那么消息队列里面是有数据的,数据库里面本次操作是无效的。这样就会导致数据的不一致性。
2 楼 heipacker 2014-04-02  
楼主这方案明显不行啊
1 楼 ruanzy888888 2014-02-13  
若第一个失败了,第二个成功了呢?

相关推荐

    分布式事务之两阶段提交,转载自:银河里的星星

    分布式事务在现代大规模分布式系统中扮演着至关重要的角色,它确保了在多个节点间的数据一致性。两阶段提交(Two-Phase Commit, 2PC)是分布式事务中常见的一种协调协议,用于解决分布式环境下数据的一致性问题。这...

    ASE数据库分布式事务管理手册.pdf

    3. **Saga模式**:虽然不是ASE的内置功能,但Saga模式是一种用于处理分布式事务的替代方案,它将一个大的事务分解为一系列较小的本地事务,每个事务都负责更新数据的一部分。如果某个事务失败,后续的补偿事务将恢复...

    聊聊分布式事务,再说说解决方案1

    因此,出现了许多替代方案,如补偿事务(Saga)、分布式事务协调器(如TCC,Try-Confirm-Cancel)和最终一致性模型。 1. **补偿事务(Saga)**:Saga是一种长事务,由一系列短事务组成,每个短事务都可以被回滚,以...

    使用RabbitMQ+延迟队列实现分布式事务的最终一致性方案

    在本方案中,我们将利用RabbitMQ的延迟队列特性来实现在订单和库存系统中的分布式事务最终一致性。 RabbitMQ是基于AMQP(Advanced Message Queuing Protocol)的消息中间件,它提供了一种可靠的消息传递机制,使得...

    LCN-分布式事务配置

    LCN(Local Capable Notifier)是一个专门为Spring Boot和Dubbo设计的轻量级...但需要注意的是,任何分布式事务方案都不能完全替代对业务逻辑的精心设计,因此在实际应用中,应结合业务场景,选择最适合的事务策略。

    掌握分布式事务的艺术:深入MySQL XA事务处理

    ### 掌握分布式事务的艺术:深入 MySQL XA ...对于更复杂的分布式系统,可能需要采用其他机制来提高系统的可用性和性能,例如分布式事务的替代方案如 Saga 模式或者最终一致性的策略等。这些主题将在后续的文章中探讨。

    分布式事务处理方案.docx

    ### 分布式事务处理方案详解 #### 数据库事务的基本特性:ACID 在讨论分布式事务之前,我们首先回顾一下数据库事务的基本概念。数据库事务具备四大基本特性:原子性(Atomicity)、一致性(Consistency)、隔离性...

    分布式事务的6种解决方案.docx

    分布式事务是现代软件架构中的重要组成部分,特别是在...设计良好的分布式事务策略需要综合考虑这些因素,并可能结合多种方法以达到最佳效果。在实践中,还应注意监控、回滚和补偿机制,以应对可能出现的异常情况。

    微服务--分布式事务的实现方法及替代方案

    本文将深入探讨几种分布式事务的实现方法及其替代方案。 首先,我们来看事务补偿机制。这是确保事务链中任何操作都能被正确回滚的一种策略。如果在事务链中有正向操作,那么必须存在对应的逆向操作,以在出错时进行...

    nacos,seata,sentinel.zip

    Nacos和Sentinel可以直接作为SpringCloud的替代品,提供更轻量级、更高效的解决方案,而Seata则弥补了SpringCloud在分布式事务处理上的不足。 综上所述,Nacos、Seata和Sentinel是构建高可用、高并发和强一致性的...

    基于Raft分布式一致性协议实现的局限及其对数据库的风险.docx

    综上所述,虽然Raft协议在很多场景下表现出色,但在高并发、多表事务以及分布式事务处理的数据库环境中,其顺序投票策略带来的局限性不容忽视。为了解决这些问题,可能需要对协议进行优化,或者寻找更适合数据库特性...

    分布式系统工程实践_taobao

    两阶段提交(Two-Phase Commit, 2PC)是一种保证分布式事务原子性的协议。它涉及到准备(prepare)阶段和提交(commit)阶段。2PC虽然可以确保事务的一致性,但同时也带来了性能开销和故障恢复的复杂性。 ##### 2.7 Paxos...

    PetShop4.0源码 详细的解析资料 两种同步和基于MSMQ的异步处理 缓存处理策略 Master Pages Wizard Control

    System.Transactions是.NET Framework 2.0下出现的一个事务控制的命名空间,它是处理替代COM+来处理分布式事务的一种新的途径。 2.使用泛型的强类型代替了IList。 3.使用了ASP.NET2.0下的角色及成员管理。 4.对于...

    springcloud分布式服务治理

    Spring Cloud Alibaba 是一套针对中国开发者设计的微服务解决方案,它整合了阿里巴巴的开源项目和云产品,如 Nacos(服务注册与发现)、Sentinel(流量控制、熔断、降级)、Seata(分布式事务)等。这些组件旨在提供...

    开源项目-pingcap-tidb.zip

    它采用两阶段提交(2PC)和分布式事务的优化策略,如乐观锁和多版本并发控制(MVCC),确保在大规模数据和高并发下仍能保证事务的正确性。 **水平扩展** 不同于传统的单体数据库,TiDB是基于水平扩展设计的。通过...

    petshop(宠物商店) V4.0源码文件

    System.Transactions是.NET Framework 2.0下出现的一个事务控制的命名空间,它是处理替代COM+来处理分布式事务的一种新的途径。 2.使用泛型的强类型代替了IList。 3.使用了ASP.NET2.0下的角色及成员管理。 4.对于...

    分布式 宿舍管理系统 +RMI+ExtJS 补上jar包

    `jta-1.1.jar`是Java Transaction API的实现,用于处理分布式事务,确保在多资源操作中数据的一致性。 这些库和框架的组合使用,使得这个宿舍管理系统具备了分布式处理能力,能够处理大量并发请求,并通过RMI技术...

    分布式数据确认架构.pptx

    1. **两阶段提交 (2PC)**:一种经典的分布式事务处理协议,协调参与者之间的事务提交,确保原子性和持久性,但可能存在死锁和延迟问题。 2. **三阶段提交 (3PC)**:2PC的扩展,引入了中止操作,以解决死锁问题,但...

    分布式文件系统HDFS原理与操作

    它并不是NameNode的热备份,一旦NameNode发生故障,SecondaryNameNode并不能直接替代NameNode,而是需要结合其他机制比如ZooKeeper来实现NameNode的高可用。 以上就是HDFS的原理与操作相关的知识点,从其设计思想到...

    银行数据中心从业人员对转型分布式系统的困惑与对策.docx

    6. 分布式事务:解决跨服务、跨节点的事务一致性问题,如2PC、TCC、Saga等事务管理策略。 7. 容器化与编排:Docker容器化技术配合Kubernetes等编排工具,实现应用的快速部署和扩展。 四、转型挑战与对策面对分布式...

Global site tag (gtag.js) - Google Analytics