- 综合排序
- 最热优先
- 最新优先
- 来自专栏CKL的思考空间
事务一致性测试
等等，不对，为什么这里没做事务管理？如果有事务，失败了不就会回滚么？ 03 研发应该不会犯这么低级的错误，再看看代码。想到了Spring中有统一的事务管理注解，应该会使用到的，为什么会没生效呢？ 解偶，在方法中只处理双写操作，其他的业务逻辑做异步处理（例如这个场景中，事件更新可以异步处理，并做对应的补偿机制），这样就不会影响主数据的一致性。 对于事务的一致性测试，在平时很容易被忽略，大家都还是相信开发会使用事务的。但是对于事务管理是否会失效，没有引起足够的重视。 对于测试人员而言，常见的事务一致性测试场景有哪些呢？ a. 双写或者多写的情况：随着现在中间件使用得越来越多，双写或者多写的情况也会增加，当数据记录在多个地方时，需要关注一致性问题 b. 异步处理，常见的是MQ，如果消费失败，是否有对应的补偿机制来保障一致性 c. 跨系统的数据存储，有些业务数据存在关联性，又分布在不同的系统中，如何保障一致性，也是测试人员需要关注的。
44320编辑于 2023-08-28 - 来自专栏积累沉淀
storm一致性事务
Storm提供了一套事务性组件Transaction Topology，用来解决这个问题。 Transactional Topology目前已经不再维护，由Trident来实现事务性topology，但是原理相同。 一、一致性事务的设计 Storm如何实现即对tuple并行处理，又保证事务性。本节从简单的事务性实现方法入手，逐步引出Transactional Topology的原理。 要想实现真正的分布式事务处理，可以使用storm提供的Transactional Topology。在此之前，我们先详细介绍一下CoordinateBolt的原理。 Trident事务性原理这里不详细介绍，有兴趣的读者请自行查阅资料。
1.6K50发布于 2018-01-11 - 来自专栏刘明的小酒馆
事务与一致性：刚性or柔性？
我们在一致性中讨论过事务在并发情况下执行时，可能发生的一系列问题：虽然单个事务执行并没有错误，但是它的执行可能会牵连到其他事务的执行，最终导致数据库的整体一致性出现偏差。 “一致性”在数据库领域有两个意义，一个是ACID中的C，另一个是CAP的C，前者是我们经常讨论的，也是普遍意义上的数据库事务一致性，而后一个将是之后会展开讨论的，有关分布式事务的一致性。 ACID 事务的一致性定义基本可以理解为是事务对数据完整性约束的遵循。这些约束可能包括主键约束、外键约束或是一些用户自定义约束。 最终一致性（柔性事务） 刚才我们讲了分布式事务在高并发场景下的败北，其实根据CAP原则我们很容易明白，想要保证可用性的同时保证一致性是不可能的，于是现在大多数的分布式系统中都对一致性做出了妥协： 我们不追求整个操作过程中每一时刻的一致性 （强一致性），转而追求最终结果的一致性（最终一致性）。
2.3K110发布于 2018-02-06 - 来自专栏huofo's blog
MySQL事务（二）事务隔离的实现原理：一致性读
这项技术使得InnoDB的事务隔离级别下执行一致性读操作有了保证，换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值。 数组里事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。这个视图数组加高水位就组成了当前事务的一致性视图（read-view）。 在更新时如何使用一致性读 image.png 图3 示例1 我们来看示例1，如果事务B在事务C更新之前查询，这个查询返回值是1。 可重复读的核心就是一致性读；而事务更新数据的时候，只能用当前读。如果当前的记得的行锁被其他事务占用的话，就需要进入锁等待。 读提交 读提交的实现方式跟可重复读类似，它们最主要的区别是： 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图； 在读提交隔离级别下，每个语句执行前都会重新算出一个新的视图
52240编辑于 2022-03-18 - 来自专栏码农沉思录
分布式事务？No, 最终一致性
点击上方“码农沉思录”，选择“设为星标” 优质文章，及时送达 事务一致性 现今互联网界，分布式系统和微服务架构盛行。 一个简单操作，在服务端非常可能是由多个服务和数据库实例协同完成的。 在互联网金融等一致性要求较高的场景下，多个独立操作之间的一致性问题显得格外棘手。 基于水平扩容能力和成本考虑，传统的强一致的解决方案（e.g.单机事务）纷纷被抛弃。其理论依据就是响当当的CAP原理。 异步确保（没有事务消息） “异步确保”这个词不一定是准确的，还没找到更合适的词，抱歉。 异步化不只是为了一致性，有时候更多的考虑响应时间，下游稳定性等因素。 我们认为这个程度的一致性已经能够满足绝大部分互联网应用场景。代价是生产方做了不少额外的事情，但相比没有事务消息情况，确实解放了不少劳动力。 ? P.S. 如果说事务消息重点解决了生产者和MQ之间的一致性问题，那么重试机制对于确保消费者和MQ之间的一致性是至关重要的。 重试可以是pull模式，也可以是push模式。
86510发布于 2020-02-19 - 来自专栏Java编程指南
分布式系统事务一致性
# 分布式事务 分布式事务的目的是保障分布式存储中数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点宕机，像单机事务一样的ACID是无法奢望的。 该种模式的难点在于解决本地事务执行和消息发送的一致性：两者要同时执行成功或者同时取消执行。 实现上主要有两种方式： 基于事务消息的方案 基于本地消息的方案 1）基于事务消息的分布式事务 普通消息是无法解决本地事务执行和消息发送的一致性问题的。 超时有可能发送成功了，有可能发送失败了，消息的发送方是无法确定的，所以此时消息发送方无论是提交事务还是回滚事务，都有可能不一致性出现。 # 总结 阅读了不少这方面的文章，在此基础上，总结一下分布式事务一致性的解决方案。分布式系统的事务一致性本身就是一个技术难题，目前没有一种很简单很完美的方案能够应对所有场景。
97320发布于 2020-06-28 - 来自专栏码农沉思录
分布式系统事务一致性
分布式系统数据的强一致性、弱一致性和最终一致性可以通过Quorum NRW算法分析。 三 分布式事务 分布式事务的目的是保障分布式存储中数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点宕机，像单机事务一样的ACID是无法奢望的。 上诉的方式是一种非常经典的实现，基本避免了分布式事务，实现了“最终一致性”。但是，关系型数据库的吞吐量和性能方面存在瓶颈，频繁的读写消息会给数据库造成压力。 这样就保证了消息发送与本地事务同时成功或同时失败。如下图： ? 各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛，而且比较可靠。 总结： 阅读了不少这方面的文章，在此基础上，总结一下分布式事务一致性的解决方案。分布式系统的事务一致性本身就是一个技术难题，目前没有一种很简单很完美的方案能够应对所有场景。
69930发布于 2019-03-07 - 来自专栏后端从入门到精通
微服务下如何保证事务一致性
1、cap理论 当每个独立的模块都拆分过后，分布式事务的一致性就出现了问题。 A用户在银行转账给B用户，A用户扣款100成功，但是B用户那边的系统宕机或者一些网络原因，导致B用户账户不变，这时候就出现了不一致性。 cap理论就此诞生，一致性，可用性和分区容错率。 这三个是不能全部满足的，当满足一致性和可用性，就要牺牲分区容错率，也就是只能满足其二。 也是就出现了base理论，最终一致性就好。 2、2pc/3pc 两阶段提交的工作步骤是什么呢？ TCC也属于强一致性，适合与金额相关的业务。 Tcc工作步骤是什么呢? 5、最大努力通知方案 上游在本地事务一切正常，发送mq消息给下游，重试几次，消费成功则ok，消费失败则通过手动补偿机制进入死信队列，存入表。
39110编辑于 2023-09-05 - 来自专栏性能与架构
分布式事务方案 - 最终一致性
在分布式时代，分库分表是很常见的，微服务系统中，各个系统通常使用独立的数据库，所以，事务很难靠数据库本身保证，只能靠业务系统来解决。 下面我们分析下最终一致性的实现方案，最终一致性通常都是使用消息中间件来实现的，系统结构如下： ? 那看下这样做是否可以，就是把更新数据库和给消息中间件发消息放到一个事务中，这样不就原子了吗？ 有问题，例如： 如果消息发送失败，具体问题出在哪儿？ 如果发消息时网络延迟很高怎么办，数据库事务一直被拖着，性能差，风险高。 所以，放入一个事务中这种方法是不可取的。 以上就是通过最终一致性解决分布式事务问题的基本思路，A 保证消息不丢，B 保证消息不漏、幂等。
83120发布于 2019-05-17 - 来自专栏软件系统思考
商城交易事务一致性保障方案
其中两个概念非常重要：原子性：多个操作必须合并成一个原子操作，即事务。 能量守恒：入账出账的值必须一样设计原则能单机事务就单机事务，别搞分布式事务，复杂度直线上升；实在不行要做分布式事务，逻辑要尽可能简单无脑；可用性达到百分之一百是做梦，最后需要有兜底逻辑，最后的最后是人工兜底 负责账目的正确性详细设计下单--->支付--->交货主要的模块包括下单模块：生成订单和预处理库存；支付模块：生成支付订单、接收第三方支付结果通知；对账模块：订单和库存数据定时对账；异常处理：处理异常情况和异常告警，对失败的事务进行兜底 支付模块交易模块主要问题是保证扣钱和发货的事务性，扣钱了必须要要发货。
21900编辑于 2025-11-04 - 来自专栏从小白开始修炼
【MySql】MySql事务隔离级别与一致性
所以单个事务，对用户表现出来的特性，就是原子性 所有的事务都有执行过程，那么在多个事务各自执行多个SQL的时候，就还是有可能会出现互相影响的情况。比如：多个事务同时访问同一张表，甚至同一行数据。 事务间互相影响，指的是事务在并行执行的时候，即都没有commit的时候，影响会比较大 一致性(Consistency) 事务执行的结果，必须使数据库从一个一致性状态，变到另一个一致性状态。 当数据库只包含事务成功提交的结果时，数据库处于一致性状态。 如果系统运行发生中断，某个事务尚未完成而被迫中断，而改未完成的事务对数据库所做的修改已被写入数据库，此时数据库就处于一种不正确（不一致）的状态。因此一致性是通过原子性来保证的。 其实一致性和用户的业务逻辑强相关，一般MySQL提供技术支持，但是一致性还是要用户业务逻辑做支撑，也就是，一致性，是由用户决定的 而技术上，通过AID保证C
59330编辑于 2023-10-15 高效掌握YashanDB事务一致性保障技术
YashanDB作为一款支持单机、分布式及共享集群部署的关系型数据库，提供了完善的事务一致性保障机制。 本文基于YashanDB的系统架构与核心技术，深入解析其事务一致性保障手段，助力用户理解并高效应用这一关键技术。 YashanDB事务模型与多版本并发控制机制YashanDB的事务系统基于标准的ACID事务特性设计，重点在于实现高效的并发控制和数据一致性保障。 可串行化隔离级别基于快照隔离，采取事务级快照一致性，并引入写冲突检测机制。若两个事务尝试修改相同数据且不兼容，将触发串行化冲突，导致事务重试或回滚，从而防止幻读和不可重复读的产生。 事务一致性保障的最佳实践建议合理选择事务隔离级别：根据应用对一致性和性能的需求，选择读已提交或可串行化隔离级别，避免不必要的性能损耗。
26810编辑于 2025-09-10- 来自专栏芋道源码1024
深入剖析分布式事务一致性
无法做到强一致 理论上的强一致性 NewSQL的强一致性 弱一致性的分类 CAP理论中的一致性 总结 ---- 概述 分布式事务是用来解决跨数据库、跨服务更新数据一致性问题的。 事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。 Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。 当我们业务变复杂，引入多个数据库和大量微服务时，上述本地事务的一致性，依旧是业务非常关心的。假如一个业务更新操作，跨库或者跨服务时，那么此时业务关心的一致性问题，就变成了分布式事务中的一致性问题。 我们进行了以下关于一致性强弱的分类： 一致性由强到弱分别是： XA事务>消息>TCC>SAGA 这里的消息指的是本地消息表这种类型的分布式事务 他们的分类为： 无中间态：数据只有两个状态，事务前和事务后 例如我们的dtm分布式事务框架，将全局事务进度保存在CP的数据库中（云厂商大多提供了CP的数据库） 总结 本文详尽的分析了分布式事务中一致性相关的问题，在确认没有强一致性方案的情况下，分析了弱一致性分类及理论上可能的强一致方案
48730编辑于 2022-03-04 - 来自专栏Java
redis与mysql的数据一致性问题（事务一致性）
redis与mysql的数据一致性问题（事务一致性） 案例：考虑一个在线购物应用，其中有一个购物车服务，购物车信息存储在MySQL中，同时为了提高性能，购物车中的商品数量也被缓存到了Redis。 ', password='password', db='ecommerce') cursor = mysql_conn.cursor() try: # 开始MySQL事务 ： 在MySQL中执行购物车更新操作时，将相关操作包裹在事务中，以确保它们的原子性。 如果任何一个操作失败，整个事务将被回滚，防止不一致的数据状态。 如果在执行事务前发现被监视的键（购物车缓存键）被其他客户端修改，则事务会被取消。
33210编辑于 2025-01-21 - 来自专栏老男孩成长之路
分布式事务里的最终一致性
本地事务ACID大家应该都知道了，统一提交，失败回滚，严格保证了同一事务内数据的一致性！ 而分布式事务不能实现这种ACID，它只能实现CAP原则里的某两个，CAP也是分布式事务的一个广泛被应用的原型，CAP(Consistency, Availability, Partition Tolerance 应用于CP和AP的原则在业界出现了一些框架： CP系统就有二阶段提交(强一致性) ? AP系统就有TCC(补偿型事务) ? 对消息确保型－最终一致性的分布式事务的理解： 1. 服务A提交数据 2. 向消息中心发送消息 3. 消息中心向订阅方推送消息 4. 订阅方处理自己的业务逻辑 5. 失败去反复去重试，直到成功，而不是向强一致性那样，把A回滚的
63210发布于 2019-12-02 - 来自专栏开源部署
Spring实现WebService分布式事务一致性
1.分布式事物 分布式事务是指操作多个数据库之间的事务，为了保证事物的一致性，一般都采用2阶段提交的办法实现。 这里强调下一致性要求，如果追求强一致性就只能采用JTA事物实现。 如果是最终一致性就不需要JTA实现了，可以采用异步消息队列实现。我这里用的是spring提供的JTA事物，因为这是个人习惯。 -- JTA事务管理器 --> <bean id="springTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager -- <em>事务</em>管理 --> <tx:advice id="txAdvice" transaction-manager="springTransactionManager"> <tx:attributes
47010编辑于 2022-07-04 - 来自专栏技术成长
强一致性事务和DTP模型的概念
强一致性事务强一致性事务是在分布式系统中保证多个操作在一个事务中按照顺序执行并达到一致的一种机制。在强一致性下，所有参与的节点都能看到完全一致的数据状态，就好像操作是在一个原子性步骤中执行一样。 总体而言，强一致性要求所有节点在同一个事务中按照相同的顺序执行操作并达到一致状态，而弱一致性和最终一致性则允许存在一定的延迟和不一致性。 它定义了事务的开始、提交和回滚等操作，并确保所有参与的资源在事务操作中保持一致性。协调执行：DTP模型协调并控制分布式系统中各个参与者的事务操作。 它可以在系统崩溃或者故障恢复后重新执行中断的事务，以保证整个系统的一致性。 总之，DTP模型通过提供事务管理、协调执行、错误处理和可靠性保证等功能，能够有效地管理和控制分布式系统中的事务操作，确保分布式事务的一致性和可靠性。
50751编辑于 2023-11-14 - 来自专栏小坤探游架构笔记
如何看待一致性 & 事务 & 共识问题
这里我们仅讨论ACID属性的C，即事务一致性。 不同术语下的一致性认知差异 关于一致性，我想我们会看到很多种不同的说法，也不同的认识。那么我们谈论的一致性经常会在哪些方面看到呢？ 其中这个余额不变就是我们ACID中的Consistency，它谈及是我们业务层面上的一致性，换言之是我们应用程序的属性，即这种一致性的概念依赖于应用程序对于不变量的定义，并且应用程序有责任正确地定义其事务 分布式事务与原子提交 在我们对事务以及一致性的认知之后，还有一种情况是我之前没有描述过的，那就是如果是在一个跨多节点或者分区事务的存储系统中，我们必然面临着分布式事务问题。 那么事务、一致性以及共识之间又有什么区别与联系呢？ 事务我们关注的是单点层面如何保证存储系统的可靠性，对于故障容忍提供一种安全性保障的机制，而共识问题关注的是分布式层如何实现具备安全性保障的故障容忍算法，而我们关注的一致性问题，建议我们在一致性描述增加一个术语的描述
18000编辑于 2025-07-14 - 来自专栏程序猿DD
我说分布式事务之消息最终一致性事务（二）：RocketMQ的实现
上一篇《我说分布式事务之消息最终一致性事务（一）：原理及实现》中，我们讲解了可靠消息最终一致性的实现原理及如何基于一款开源的消息中间件，实现一个可靠消息服务的思路。 本文，我们讲解如何利用开源消息中间件RocketMQ的特性–事务消息，实现基于消息一致性的最终一致的分布式事务。 原理简介 RocketMQ提供了类似X/Open XA的分布事务功能，通过MQ的事务消息能达到分布式事务的最终一致。 从上述事务消息设计中可以看到，RocketMQ事务消息较好的解决了事务的最终一致性问题，事务发起方仅需要关注本地事务执行以及实现回查接口给出事务状态判定等实现，而且在上游事务峰值高时，可以通过消息队列， 事务消息不仅适用于上游事务对下游事务无依赖的场景，还可以与一些传统分布式事务架构相结合，而MQ的服务端作为天生的具有高可用能力的协调者，使得我们未来可以基于RocketMQ提供一站式轻量级分布式事务解决方案
3K20发布于 2019-05-10 - 来自专栏编程一生
分布式事务一致性实现的方式总结
所以今天总结一下分布式事务的实现方法，下次组内周会给大家统一一下概念。 刚性事务和柔性事务 刚性事务：严格遵循ACID原则（原子性、一致性、隔离性、持久性）的事务。基本上指的是本地数据库事务。 数据一致性（consistency）:这里的一致性是强一致性，又叫线性一致性。即一个写操作成功，而读出的必须是写操作后的新数据。而写操作失败读出的必须是写操作前的旧数据。 核心思想是即使无法做到强一致性，但可以使用一些技术手段达到最终一致。 分布式事务一致性实现方案 为了解决分布式一致性问题，前人在性能和数据一致性的权衡过程中总结了许多经典的协议和算法。比较著名的有：2PC、3PC、TCC、Paxos、Raft、Zab、ISR。 实现比较复杂，Zookeeper就是用这个来实现的分布式一致性。
91610发布于 2018-07-02
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号