分布式事务的挑战

多个节点，如何实现ACID，一致性，可用性，性能如何取舍都是挑战。

设计需要考虑，事务状态在哪里感知（需做高可用），以及出现故障和分区，是不断像2pc重试还是需要回滚以及回滚方式，以及业务入侵程度。同步与异步，一致性的考虑（任何时间都有可能故障，需要做分类讨论故障情况）

基于承诺的系统redolog 和一阶段的ack

元数据在，数据就在，submarine设计缺陷。

传统2pc

1.PrePare 2.Commit

坏处 1.同步阻塞 2.单点故障风险 3.悲观事务 4.数据不一致

好处：强一致性

传统3pc

加了一轮canCommit减少事务失败的可能性，但是prePare后，超时会自动commit(因为canCommit阶段)，不一致（需要后续人工接入）

通信轮次过多。

2pc和3pc在业务系统中用的不多，因为重试可能还是失败，2pc不停重试，而3pc自动提交commit

那么其实2pc和3pc还是要最终一致性兜底，只是说比后面两个更加极端情况，那么一致性不高，数据同步要求不高的情况下， 我们会优先采用下面的方案

本地消息表

一致性失去，保障可用性 BASE最终一致性

通过本地事务 + 定时消费 + MQ幂等实现

消息系统

消息系统分布式事务和本地消息表实现分布式事务的主要区别如下：

1. 实现方式：

   • 消息系统分布式事务：依赖于消息中间件（如RabbitMQ、RocketMQ等）来实现事务的最终一致性。事务的两个阶段（准备和提交）通过消息中间件进行异步解耦。
   • 本地消息表：最初由eBay提出，核心思想是将分布式事务拆分成本地事务进行处理。通过在数据库中创建一个消息表，将业务数据和消息数据在同一个本地事务中处理，然后通过脚本定期轮询本地消息表，将消息发送到消息队列中。

2. 业务侵入性：

   • 消息系统分布式事务：通常需要业务方进行改造，提供对应的本地操作成功的回查功能，具有较大的业务侵入性。
   • 本地消息表：实现逻辑简单，开发成本比较低，不需要引入复杂的分布式事务协议，降低了实现难度。

3. 性能和可靠性：

   • 消息系统分布式事务：由于依赖于网络通信，可能会有一定的延迟，对于实时性要求较高的场景，需要额外优化。
   • 本地消息表：业务操作和消息记录在同一个本地事务中执行，避免了跨网络通信的开销，提高了系统性能。同时，通过独立的消息调度器，确保消息最终一定会发送到消息队列，即使发生网络故障或服务重启，也不会丢失消息。

4. 幂等性：

   • 消息系统分布式事务：需要确保消息的幂等性，避免重复消费造成数据不一致。
   • 本地消息表：同样需要确保消息的幂等性，因为消息发送是异步进行的，可能会有一定的延迟。

5. 资源占用和性能瓶颈：

   • 消息系统分布式事务：不直接占用业务系统的数据库资源。
   • 本地消息表：与业务数据表在同一个数据库，占用业务系统资源，量大可能会影响数据库性能。

6. 通用性和独立性：

   • 消息系统分布式事务：通常作为独立的服务存在，与业务系统解耦。
   • 本地消息表：与业务耦合在一起，难于做成通用性，不可独立伸缩

Seata事务和柔性事务

AT模式

XA模式

一、Seata AT模式的隔离级别

Seata AT模式默认提供‌读未提交（Read Uncommitted）‌的隔离级别，但通过全局锁机制实现了‌读已提交（Read Committed）‌的效果。在第一阶段（Prepare）提交本地事务后，其他事务需等待全局锁释放才能读取已提交的数据，避免脏读‌12。

---

二、AT模式与XA模式的核心区别

‌对比维度‌	‌AT模式‌	‌XA模式‌
‌实现层级‌	应用层/驱动层实现二阶段提交，通过代理SQL生成回滚日志实现事务控制‌12。	数据库原生支持的XA协议实现，依赖数据库层面的两阶段提交（2PC）‌12。
‌锁机制‌	第一阶段提交后立即释放本地锁，通过全局锁协调事务冲突‌23。	全程持有数据库锁（从Prepare到Commit/Rollback），锁粒度更大‌12。
‌性能‌	性能较高（仅在Prepare阶段占用锁资源）‌12。	性能较低（事务全程占用锁资源，可能引发资源阻塞）‌24。
‌侵入性‌	无代码侵入，仅需配置数据源代理‌13。	需依赖数据库XA驱动，部分场景需调整业务代码‌23。
‌一致性保证‌	最终一致性（通过全局锁保证数据可见性）‌23。	强一致性（遵循ACID原则）‌24。

---

三、优缺点对比

‌AT模式‌

• ‌优点‌：
  • 高性能：本地事务快速提交，减少锁冲突‌12。
  • 无侵入性：无需业务代码改造‌13。
• ‌缺点‌：
  • 隔离级别较低：可能存在中间态数据（需业务容忍脏读）‌23。
  • 依赖全局锁：全局锁失败可能导致事务回滚‌34。

‌XA模式‌

• ‌优点‌：
  • 强一致性：严格遵循ACID特性，适合对数据一致性要求高的场景‌24。
  • 标准化：依赖数据库原生支持，兼容性较好‌24。
• ‌缺点‌：
  • 性能瓶颈：长事务锁资源易导致阻塞‌24。
  • 侵入性：需数据库支持XA协议，部分场景需调整驱动配置‌23。

---

四、适用场景

• ‌AT模式‌：
  • 高并发、短事务场景（如电商下单、库存扣减）‌12。
  • 对最终一致性可接受的业务（如订单状态异步更新）‌23。
• ‌XA模式‌：
  • 强一致性要求的场景（如金融转账、账户余额操作）‌24。
  • 数据库原生支持XA且事务规模可控的场景‌24。

---

总结

AT模式通过牺牲部分隔离性换取高性能和易用性，适合互联网高并发场景；XA模式通过强一致性保障数据准确性，适合传统金融或核心系统‌23。

TCC模式

空回滚和Try Cancel网络乱序的悬挂。

解决方法都是：在数据库记录一下事务的状态

saga模式（一阶段提交，但是复杂）

Percolate

一种异步提交乐观事务，为snapshot隔离级别，依赖TSO服务

TinyKv project4 理论拓展_tinykv 4-CSDN博客

分布式事务生产过程中的监控

在生产环境中管理分布式事务时，需要注意以下几个方面，并监控相应的指标数据：

1. 事务一致性与隔离性：
   • 确保事务在分布式系统中保持ACID属性，特别是一致性和隔离性。
2. 通信故障：
   • 节点间的通信可靠性，防止因通信故障或延迟导致事务无法正常执行。
3. 容错性和高可用性：
   • 系统应具备容错措施和高可用性策略，如备份节点、负载均衡、故障转移等，以应对节点故障。
4. 性能和扩展性：
   • 系统性能和扩展性，优化算法、使用缓存、分布式计算等，以支持高并发和事务处理速度。
5. 监控工具与指标：
   • 使用如pg_stat_activity视图监控事务状态和执行时间等关键指标。
   • 关注事务的执行时间、锁等待时间、资源使用情况等。
6. 日志分析：
   • 配置详细日志级别，获取事务的开始和结束时间、执行的SQL语句、错误信息等。
7. 性能监控的示例：
   • 配置定期查询，如每分钟获取一次正在进行的分布式事务信息。
8. 性能优化策略：
   • 优化事务设计，减少事务范围，合理使用锁级别。
   • 索引优化，为常用字段创建合适的索引。
   • 配置参数调整，根据系统资源和负载调整关键配置参数。
9. 关键性能指标(KPI)：
   • 吞吐量：单位时间内的事务处理量。
   • 响应时间：从发起请求到收到响应的总时间。
   • 错误率：发生错误数量与总事务量的比例。
   • 资源利用率：CPU、内存、磁盘和网络资源的使用情况。
10. 分布式架构模式：
    • 客户端-服务器模式、三层架构、微服务架构、事件驱动架构等，根据业务需求选择合适的架构模式。
11. 监控系统的设计原则：
    • 实时性、全面性、可视化、自适应性。
12. 异常处理：
    • 防空回滚、幂等、防悬挂三个特性，以应对网络及业务故障等问题。