分布式事务一致性

1、分布式事务产生的缘由 -  数据分区

1. 分库分表

实际状况：MySQL单表数据达到千万级别后，会随数据量增大，会出现性能降低的状况，这时须要分表保存数据

2. 应用垂直切分（服务化）

后端按功能切分后，须要保持库存与支付模块的数据一致性。

2、 数据分区时的一致性问题

1. 基于ACID的分布式事务解决方案 - XATransactionManager

A：原子性，在整个事务中的全部操做，要么所有完成，要么所有不作，没有中间状态。对于事务在执行中发生错误，全部的操做都会被回滚，整个事务就像从没被执行过同样。

C：一致性，事务必须始终保持系统处于一致的状态，无论在任何给定的时间并发事务有多少。

I：隔离性，事务与事务之间不会互相影响，一个事务的中间状态不会被其余事务感知。

D：持久性，一旦事务完成了，那么事务对数据所作的变动就彻底保存在了数据库中

A：准备后，仍可提交与回滚

C：准备时，一致性检查必须OK

I：提交完成前，事务结果仍然只在事务内可见

D：提交完成后，事务结果已经持久

问题

1. 准备阶段的持久成本

2. 全局事务状态的持久成本

3. 潜在故障点多

4. 准备后发生故障以后的恢复

3、解决方案

CAP原理

Consistency(一致性): 全部用户看到一致的数据

Availability(可用性): 总能找到一个可用的数据复本

Partition(分区容忍性): 即便在系统被分区的状况下，仍然知足上述两点

分布式场景下，P是必须的，A > C

BASE

BA(Basic Availability)：基本可用性

S(Soft state)：柔性状态

E(Eventuallconsistency)：最终一致性

咱们的目标

知足用户的一致性

1. 服务模式分类

• 可查询服务

• 幂等服务

• tcc服务

• 可补偿服务

2. 一致性解决方案 - 依赖事务日志的恢复/补偿/重试

• 可靠消息送达（幂等服务）

• tcc（tcc服务）

• 交易编排（可查询服务、幂等服务、可补偿服务）

3. 分布式事务一致性不能仅从技术上解决

客户充值，三方支付划扣异常，客户能够直接提现

客户提现，三方支付付款超时（成功），客户能够重复提现

要保护资金的安全

5、咱们的选择

原则

1. 保护系统资金（利益）安全

2. 保持客户体验一致性

1. 复杂的一致性要求高的集成交易 → 交易编排 lo-process

2. 简单的一致性要求不高的集成交易 → 可靠消息送达

3. 不选择TCC的理由（虽然TCC是编程式，编码方便）

• TCC的多级系统的嵌套事务很差解决

• TCC对于外部系统提供的服务要求很高，必须所有知足TCC服务要求，实际场景下不少外部服务提供方没法提供TCC服务，而且提供方的服务也没法很好地经过代理层封装为TCC服务

4. 对服务设计的要求

• 全部提供给外系统调用的服务接口，均须要记录流水号，服务接收时插入流水，服务完成时更新流水，该流水用于提供可查询的服务能力

• 全部调用外部系统接口的操做，均须要记录流水，接口调用前插入流水，调用完成时更新流水，该流水用于提供交易编排时的重试、查询和反冲

• 全部提供给外系统调用的服务接口，均系统有流水号字段，该字段在系统内部不能重复，用于提供幂等或交易重复提示的功能