彻底解决分布式系统一致性的问题_读书笔记_1

2.2一致性问题

2.3解决一致性问题

2.3.1酸碱平衡理论

ACID,BASE

1.ACID(酸)

关系型数据库完全满足ACID特性

原子性,一致性,隔离性,持久性

数据库的一致性通常通过多版本控制协议(MVCC)来实现

NoSQL(非关系型数据库)不适合交易场景,主要做数据分析,报表,数据挖掘,推荐,日志处理,调用链跟踪等非核心交易场景.

2.CAP(帽子原理)

C一致性:所有节点同一时刻读取的数据都是最新的数据副本.

A可用性:好的响应性能,完全的可用性指任何故障模式下,服务都会在有限时间内处理完成并响应.

P分区容忍性:网络上有部分消息丢失,系统仍然可继续工作.

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

3.BASE(碱)

BASE与ACID原理截然不同,满足CAP原理,牺牲强一致性获得可用性,一般用于服务化系统的应用层或者大数据处理系统中,通过达到最终一致性尽量满足业务的绝大多数需求

BASE模型包含如下三个元素.

BA:基本可用

S:Soft State,软状态,状态可以在一段时间内不同步

E:Eventually Consistent,最终一致,在一定的时间窗口内,最终数据达成一致即可.

软状态是实现BASE思想的的方法,基本可用和最终一致是目标.

电商的下订单和扣库存的一致性问题,可以通过BASE思想解决

A向B转账,

• 准备

• A扣减

• B增加

• 完成

系统记录每个不好走的状态,一旦出现故障,系统能自动发现没有完成的任务

根据任务所处状态继续执行任务,最终彻底完成任务.

总结

• 使用向上扩展(强悍的硬件)并运行专业的关系型数据库能保证强一致性,能向上扩展解决的问题都不是问题.

• 如果向上扩展的成本很高,则可以对廉价硬件运行的开源关系数据库进行水平伸缩和分片,相关数据分到数据库的同一个片上,仍然能够使用关系型数据库保证事务.

• 如果无法将相关数据分到同一个分片上,就需要实现最终一致性,通过系统自动化或者人工干预来修复不一致问题.

2.3.2分布式一致性协议

OpenGroup定义了DTS(分布式事务处理模型)四个角色

• 应用程序

• 事务管理器:统管全局

• 资源管理器:事务参与者

• 通信资源管理器:事务参与者

1.两阶段提交协议的流程

• 准备阶段:协调者向参与者发起指令,参与者评估自己的状态,如果参与者评估指令可以完成,则写redo或undo日志(Write-Ahead Log的一种),然后锁定资源,执行操作但不提交

• 提交阶段:如果每个参与者都明确返回准备成功,则协调者向参与者发起提交指令,参与这提价资源变更的事务,释放锁定的资源.如果任何一个参与者明确返回准备失败,也就是预留资源或者执行操作失败,则协调者向参与者明确返回准备失败,也就是预留资源或者执行操作失败,则协调者向参与者发起中止指令,参与者取消已经变更的事务,执行undo日志,释放锁定的资源.

致命问题

• 阻塞:任何指令都要收到明确的响应,否则处于阻塞状态占用资源被一直锁定,不会被释放

• 单点故障:协调者宕机,会一直阻塞,选举新的协调者替代原有协调者,但如果协调者发送一个提交指令后宕机,而提交指令仅仅被一个参与者接收,并且参与者接收后也宕机,新上任的协调者无法处理这种情况.

• 脑裂:协调者发送提交指令,有的参与者执行,有的参与者没有接收到事务就没执行,多个参与者之间不一致.

2.三阶段提交协议

三阶段提交协议是两阶段提交协议的改进版本.它通过超时机制解决了阻塞的问题,把两个阶段增加为三个

• 询问阶段:参与者只要回答是或不是,不需要真正操作,这个阶段超时会导致中止

• 准备阶段:如果在寻味阶段所有参与者都返回可以执行操作,则协调者向参与者发送预执行请求,参与者写redo和undo日志,执行操作但不提交.....这里逻辑和两阶段提交的准备阶段相似

• 提交阶段:....

两个协议的不同点

• 增加了一个询问阶段,询问阶段可以确保尽可能早发现无法执行操作而需要中止的行为,但是它并不能发现所有这种行为,只会减少这种情况发生.

• 准备阶段以后,协调者和参与者执行的任务中都增加了超时,一旦超时,则协调这和参与者都会继续提交事务,默认为成功,这也是概率统计超时后默认为成功的正确性最大.

互联网高并发系统中,没有用两阶段提交和三阶段提交协议的场景.

3.TCC协议[Try Confirm Cancel]

简化版三阶段提交协议,极端情况TCC会出很多问题,解决而阻塞问题,但是没解决不一致和脑裂问题.但是TCC通过自动化补偿手段将需要人工处理的不一致情况降到最少.