分布式事务解决方案课程概述(一)

前言

分布式架构系统中, 分布式事务是一个绕不过去的挑战! 微服务架构的流行, 让分布式事务问题日益突出!

场景

假设有三个平台: 电商平台, 支付平台, 银行
整个支付流程将会是这样的:
1.电商平台中创建订单: 预留库存, 预扣减积分, 锁定优惠券, 此时电商平台内各服务间会有分布式事务问题, 因为此时已经要跨多个内部服务修改数据;

2.支付平台中创建支付订单(选银行卡支付): 查询账户, 查询限制规则, 符合条件的就创建支付订单并跳转银行, 此时不会有分布式事务问题, 因为还不会跨服务改数据;

3.银行中创建交易订单: 查找账户, 创建交易记录, 判断账户余额并扣款, 通知支付平台, 如果是服务化架构的话, 此时也会有分布式事务问题.

4.支付平台收到银行扣款结果: 更改订单状态, 生成会计分录, 通知电商平台等, 此时也会有分布式事务问题.

5.电商平台收到支付平台的支付结果: 更改订单状态, 扣减库存, 扣减积分, 使用优惠券, 增加消费积分等, 系统内部各服务间调用也会遇到分布式事务问题.

支付平台收到银行扣款后的处理流程:
1.支付平台的支付网关对银行通知结果进行校验, 然后调用支付订单服务执行支付订单处理;

2.支付订单服务根据银行扣款结果更改支付订单状态;

3.调用资金账户服务给电商平台的商户账户加款, 如果是余额支付, 那将会是从用户账户扣款, 给商户账户加款;

4.调用积分服务给用户积分账户增加积分;

5.调用会计服务给会计系统写入交易原始凭证生成会计分录;

6.调用通知服务将支付结果通知电商平台;

概念

1.CAP

Consistency: 强一致性就是客户端任何时候看到各节点的数据都是一致的.
Availability: 高可用性就是系统再任何时候都可以进行读写.
Partition tolerance: 分区容错性就是在网络故障, 某些节点不能通信的时候系统仍能继续工作.
在绝大多数场景下, 都需要牺牲强一致性来换取系统的高可用性, 系统往往只需要保证最终一致性.

2.ACID

Atomicity 原子性: 就是一个事务的所有操作要么都成功, 要么都失败, 不会停留在中间某个状态;
Consistency 一致性: 事务开始之前和事务结束之后, 数据都是完整的;
Isolation 隔离性: 数据库允许多个并发事务同时对某数据进行读写, 隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致;
Durability 持久性: 事务处理结束后, 对数据的修改及时永久的, 即使系统故障也不会丢失.

3.全局事务

事务由全局事务管理器全局管理, 比如JTA
优点: 严格的ACID
缺点: 效率非常低(微服务架构下已不适用), 适用全局事务, 数据被Lock的时间跨整个事务, 直到全局事务结束.

4.BASE理论

Basic Available 基本业务可用: 指分布式系统在出现故障时, 允许损失部分可用性来保证核心功能可用.
Soft state 柔性状态: 状态允许短时间的不同步.
Eventual consistency 最终一致: 分布式系统中的所有数据经过一定时间后, 最终能够达到一致的状态.

5.幂等性

重复调用多次产生的业务结果与调用一次产生的业务结果相同