ZhiguoXue_IT2023-07-26 来自北京业界内落地实用基本都是mq保证最终一致性，但是据说银行系统是强一致性，作者认为呢作者回复: 我持怀疑态度。我个人理解，分布式事务里面，如果事务协调者，事务参与者没有什么 redo 和 undo log 之类的东西，我个人认为它们不可能达成强一致性。但是问题又来了，事务协调者还要考虑 ACID 中的 AID 问题，不仅仅是一致性。举个例子，在意图保证强一致性的场景里面，你要不要考虑隔离性的问题？一个分布式事务能不能看到另外一个分布式事务的修改？ 所以，综合来说，我持怀疑态度。之前听过一点银行的技术分享，他们说的强一致性其实都是最终一致性，总是有不一致的问题。也可能是我孤陋寡闻了。
1
Geek80042023-08-30 来自中国香港自动故障处理的机制不是很明白.针对这句话“修复数据本身分成两种，一种是用已经提交的数据库的数据来修复没有提交成功的数据库的数据；另外一种则是用没有提交成功的数据库的数据来还原已经提交的数据库的数据。 ”只有一份数据,假如我db1 rollback失败,此时db0之前已经提交了数据,我怎么用已提交的数据修复未提交的?他们数据没有冗余呀作者回复: 你这个场景我其实没有理解。就是如果 db0 是提交的话，那么 db1 也是提交，不会出现 db0 提交，db1 回顾的场景。 如果 db0 提交成功了，但是 db1 没有提交成功，那么就用 db0 的数据去修复 db1。
peter2023-07-27 来自北京请教老师几个问题： Q1：根据文章内容，不管哪种分布式事务解决方案，都做不到ACID，都无法保证不出问题。那么，在实际的应用中，分布式事务的成功率一般能达到多少？ Q2：AT是概念还是具体框架？ Q3：单库但有分表，是否存在分布式事务？ Q4：两个SQL可以共用一个事务，前提是这两个SQL是属于一个Session吗？不同Session的SQL不能共用一个事务吧。 Q5：对数据库进行修复会影响业务吗？如果会影响，会采取哪些措施？作者回复: 1. 这个要看业务。成功率是一个不够准确的定义，你应该说取得一致性的时间是多长，以及没有办法达成一致的比率有多高。实际上，你应该做到和你的可用性一致。比如说正常，我们都会要求最终不一致的数据，每天应该控制在个位数。太多了你手工修复很要命的。 2. 我个人认为，是 seata 里面引入的。我比较孤陋寡闻，没见着别的地方哟用。我自己理解的话喜欢把它说成是 SAGA 的自动化的特殊形态。 3. 嘿嘿，如果你的分库分表中间件做得好，那么就没有。有些分库分表中间件是语句维度来调度的，所以搞不好也引入了分布式事务。 4. 对的 5. 主要是小心并发。比如说你数据出错了，你准备去修复。但是你修复之前，可能另外一个请求又把错误的数据更新为新数据了，但是这个新数据是对的。所以最好是在修复的时候要根据更新时间、版本号之类的来判断一下，避免出现并发覆盖的问题。
进击的和和2023-07-26 来自四川老师你好 协调者让参与者执行事务，但是并不提交，协调者返回执行情况 这里是不是参与者返回执行情况呢。 我在两阶段提交那里说到在提交阶段，协调者会不断重试直到把 Commit 请求发送给协调者；协调者如果在提交阶段中途崩溃，也要确定是否需要提交或者回滚。那么你就应该可以理解，在重试成功之前，或者在协调者恢复过来重新提交或者回滚之前，数据是不一致的。这句话好像有点小问题吧。 两阶段提交如果a参与者成功了,b参与者失败了,那么是不是只能人工处理或者有个修复数据的脚步进行修复呢? 关于容错,如果协调者挂了,那么参与者1是否可以询问其他参与者情况呢作者回复: 1. 是参与者返回执行情况。 2. b 参与者如果在准备阶段就失败了，那么直接回滚，这个应该没什么疑问。问题是在 commit 阶段，如果 b 参与者 commit 失败了怎么办。那么按照两阶段提交协议的要求，b 参与者这时候是不能 commit 失败的，b 要不断重试，或者用别的手段保证自己的成功。但是，显然这也是一个不现实的要求，所以 b commit 最终失败之后，肯定要人工介入的。这你也可以看出来，又出现了不一致。从理论上来说，协调者在发现 b 死活不能提交成功之后，那么 a 提交的数据应该也要处于一种不可用的状态，可惜的是，我们也做不到。 3. 参与者可以考虑询问。但是这里有一个问题，就是你问几个人呢？比如说十个节点里面，你问了六个人，三个人告诉你提交，三个人告诉你不知道，这时候你是提交还是不提交？那三个不知道的，又该怎么办？所以整体这需要一个比较复杂的机制。