MySQL事务与分布式CAP定理
1、MySQL事务
MySQL的事务是一组操作的集合,它是一个不可分割的工作单位。事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求,即这些操作要么同时成功,要么同时失败。
在MySQL中进行事务控制:
-- 开启事务:会将后续执行的SQL语句当做一个事务进行管理,如果所有SQL语句都执行成功,则应提交,如果有一个执行失败,则应回滚
start transaction; -- 或者begin;
-- 提交事务:事务成功后提交事务
commit;
-- 回滚事务:事务失败后,进行回滚,恢复数据
rollback;
2、MySQL事务的四大特性
事务的四大特性(ACID):
- 原子性(Atomicity):事务是不可分割的最小单元,要么全部成功,要么全部失败。
- 一致性(Consistency):事务完成时,必须使所有的数据都保持一致。
- 隔离性(Isolation):数据库系统提供的隔离机制,保证事务在不受外部并发操作影响下的独立环境运行。
- 持久性(Durability):事务一旦提交或回滚,它对数据库中的数据的改变永久的。
3、CAP定理
可参考文档:CAP定理
解决分布式事务问题,需要一些分布式系统的基础知识作为理论指导,首先就是CAP定理。
1998年,加州大学的计算机科学家 Eric Brewer 提出,分布式系统有三个指标:
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance(分区容错性)
它们的第一个字母分别是 C、A、P。Eric Brewer认为任何分布式系统架构方案都不可能同时满足这3个目标,这个结论就叫做 CAP 定理。
3.1 一致性(Consistency)
Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致。
3.2 可用性(Availability)
Availability (可用性):用户访问分布式系统时,读或写操作总能成功。
只能读不能写,或者只能写不能读,或者两者都不能执行,就说明系统弱可用或不可用。
3.3 分区容错性(Partition tolerance)
Partition,就是分区,就是当分布式系统节点之间出现网络故障导致节点之间无法通信的情况;
Tolerance,就是容错,即便是系统出现网络分区,整个系统也要持续对外提供服务。
3.4 CAP的矛盾
在分布式系统中,网络不能100%保证畅通,也就是说网络分区的情况一定会存在。而我们的系统必须要持续运行,对外提供服务。所以分区容错性(P)是硬性指标,所有分布式系统都要满足。而在设计分布式系统时要取舍的就是一致性(C)和可用性(A)了。
这时有两种选择:
- 允许用户任意读写,保证可用性。但由于节点数据无法完成同步,就会出现数据不一致的情况。满足AP;
- 不允许用户写,可以读,直到网络恢复,分区消失。这样就确保了一致性,但牺牲了可用性。满足CP。
可见,在分布式系统中,A和C之间只能满足一个。
为了解决CAP的矛盾,提出了BASE理论。
既然分布式系统要遵循CAP定理,那么问题来了,我到底是该牺牲一致性还是可用性呢?如果牺牲了一致性,出现数据不一致该怎么处理?
人们在总结系统设计经验时,最终得到了一些心得:
- Basically Available (基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
- Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
- Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。
以上就是BASE理论。
简单来说,BASE理论就是一种取舍的方案,不再追求完美,而是最终达成目标。因此解决分布式事务的思想也是这样,有两个方向:
- AP思想:各个子事务分别执行和提交,无需锁定数据。允许出现结果不一致,然后采用弥补措施恢复,实现最终一致即可。例如AT模式就是如此
- CP思想:各个子事务执行后不要提交,而是等待彼此结果,然后同时提交或回滚。在这个过程中锁定资源,不允许其它人访问,数据处于不可用状态,但能保证一致性。例如XA模式