分布式系列七: 分布式事务理论
事务是将一组操作作为一个整体执行, 这组操作要么成功,要么失败, 不存在部分成功的情况, 分布式事务是为了解决在分布式环境下各节点之间的数据一致性问题.
数据库本地事务
事务四大特性:
-
原子性(Atomicity): 事务的一组操作要么全部执行成功, 要么其中有失败后回退到初始状态. 不存在部分执行部分失败的状态. 回退是通过事务的回滚机制(Rollback)完成.
-
一致性(Consistency): 事务执行前后的数据必须一致. 举例来说就是, 下单过程中库存和扣款二者必须对应.
-
隔离性(Isolation): 事务之间的执行是隔离的, 不能相互影响. 操作相同的数据时, 每个事务都有各自的完整数据空间. 不能读取到事务执行中间状态的数据.
-
持久性(Durability): 事务执行结束后, 它对数据库的更新将是永久的. 不管系统崩溃断电,数据的状态不会发生变化.
MySql的InnDB引擎支持事务, MySql的事务是通过Redo,Undo日志以及锁机制来完成. 分开来说, 事务的隔离性通过锁来实现, 持久性通过Redo来实现, 原子性和一致性通过Undo来实现.
分布式事务产生原因
在分布式环境下, 数据库(Resource)和应用(Service)均可能被拆分为多个节点, 而操作可能需要在多个节点间一致地完成.
分布式事务相关的理论
-
CAP理论: Consistency, Availability, Partition tolerance; 当错误发生时, 三者不能同时满足, 而分区容错是必须满足的条件, 于是只能在CP和AP之间选择. 这也是现在分布式框架的特性, 比如Eureka满足AP, zookeeper满足CP.
-
BASE理论: Basically Available: 出现故障时, 允许损失部分功能, 保证核心功能可用; Soft States: 允许出现中间状态, 这个状态不影响系统可用性; Eventually consistent: 最终经过一小段时间后, 所有节点的数据达到一致. BASE放弃了事务执行中间的强一致性, 允许中间一小段时间出现中间状态, 但最终需要达成一致.
柔性事务(遵循BASE): 最终一致性, TCC事务, 补偿机制.
X/Open DTP 模型
三个角色:
- AP: application
- RM: Resource Manager 一般是数据库, 需要始兴县XA定义的接口.
- TM: Transaction Manager
2pc & 3pc
- 2pc: two phase commit precommit -> docommit
缺点: (1)单点故障, 事务管理器宕机可能导致阻塞, 二阶段事务无法提交; 资源管理器宕机,导致没有接收到commit,导致阻塞(2)同步阻塞;(3)数据不一致
- 3pc: three phase commit cancommit -> precommit -> docommit
解决了2pc中的阻塞问题, 因为引入了超时机制.
XA 和 JTA
XA是X/Open定义的规范, JTA是java事务规范的实现.
互联网分布式事务解决方案
互联网对数据的绝对一致性要求没有传统行业高
- 避免分布式事务;
- 最终一致性解决方案;(基于BASE),
使用MQ解决:
消息丢失使用持久化解决;
重复消费问题(幂等性)问题使用状态锁或者幂等校验解决).
模式:
1. 查询模式, 提供一个接口返回是否成功的状态; 衰减查询
2. 补偿模式: (1)自动恢复,就是自动重试或回滚; (2)通知运营, 人工干预;(3)通知技术,监控预警(数据恢复)
3. TCC事务(DTS事务架构--淘宝) 框架: tcc-transaction;butetcc
trying: 冻结账户余额, 商户不动
commit: 扣减账户余额, 商户账户增加
cancel: 解除冻结 - 最大努力通知: 重复通知, 直到处理