分布式的基本理论

fisherMartyn bio photo By fisherMartyn

简介

在分布式系统设计中经常听到关于CAP和BASE等词汇,包括数据库系统中的ACID。学习事务系统(ACID)和分布式系统(CAP/BASE)设计的基本理论能够更好的指导系统的设计。在这里讲一些自己的总结和理解。

ACID

ACID是数据库管理系统为保证事务可靠性所必须具备的特性。理解ACID,理解隔离级别是设计数据库系统、分析数据库系统的必要条件。

概念

关于ACID的概念、说明、和反例描述如下(非官方描述,有个人的理解):

A(原子性),事务中的操作必须全部成功或者全部失败;不允许出现事务中一部分成功、另一部分失败的情况。

C(一致性),事务的执行不能破坏数据库系统的完整性;不允许出现事务执行中发生故障,只有部分事务写入了数据库的情况。

I(隔离性),并发环境中,一个事务的执行不能被其它事务干扰,需要相互隔离;不允许出现一个事务的执行因为其它的并发事务而导致出现未预期的结果。

D(持久性),事务提交完成后,数据库系统的变更是持久化的;不允许出现事务提交后,系统宕机,数据库重新启动后事务的提交丢失。

隔离级别

ACID中的I需要特别说明,在标准SQL中,规定了隔离性的不同级别。不同隔离级别的系统之间差距很大,隔离级别和系统吞吐量之间也有直接的权衡关系。另外,如果不理解隔离级别,在实际的事务相关的代码开发中肯定不符合预期的问题。

未授权读:隔离级别最低,有脏读;例如事务A和B同时开始,事务A修改了部分数据但未提交,这时事务B能读到这部分数据

授权读:事务中可以读取已经提交的数据,无脏读,但不可重复读;例如事务A和B同时开始,事务A修改了数据,A提交前B不能读到这部分数据,A提交后,事务B能读到这部分数据

可重复读:事务中,多次读取同一个数据都是事务一开始的数据(未明确说明是否有幻读);例如事务A和B同时开始,事务A进行了修改并提交。这时事务B重新读取,只能读到事务开始时的数据

串行化:最严格的隔离级别,所有事务串行执行;例如事务A和B所涉及相关的数据必须串行读写,另一个事务会阻塞

不同的隔离级别是为了与吞吐量之间进行权衡,低隔离级别往往能够提交事务的吞吐量,降低并发冲突;但较低的隔离级别在事务性编程时又要特别注意。具体的选择要根据业务的特点来进行。

CAP

ACID是单机数据库系统设计的准则,但数据库事务系统往往是单机系统。但随着分布式系统的发展,数据会分散在不同位置的机器上,因此出现了CAP和BASE这样的分布式系统的经典理论。

CAP理论定义:一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个需求,最多只能满足两项。

盗一张网络上CAP的图(版权属于www.dodobook.net)

C 一致性:分布式系统多个数据副本之间应该保持一致,某个副本更新后,全局应该一致;不允许副本部分更新,从其它副本读到的不是更新后的数据;

A 可用性:分布式系统对于用户的每一个操作必须在有限的时间内返回结果;不允许请求时由于系统阻塞等原因,发生超时;

P 分区容错:分布式系统对于网络分区故障(非全局故障)时仍然能提供一致性和可用性的服务;不允许分布式系统节点的加入/退出导致系统不可用或者不一致;

CAP定理的应用首先体现在两项基本需求的选择上:

放弃C:放弃强一致性,系统无法保证实时一致;例如Cassandra

放弃A:放弃可用性,同步或者故障时,系统不可用;例如MongoDB/Redis

放弃P:放弃分区容错性,分区故障时不可以保证CA,最简单的场景是单机系统;例如关系型数据库系统;

需要注意,CAP定理说明,放弃其中一项需求,才能获得其它两项完整的基本需求。注意这里说的是”完整”的基本需求,因为在其中两者之间,还可以通过弱化完整需求来权衡,也就是下面要说的BASE。

BASE

BASE是CAP原理权衡的结果。CAP中,考虑到分布式应用,必须需要分区容错性(P),那么如何在C和A中做权衡,是BASE要解决的问题。BASE三要素:

BA:基本可用,在系统出现不可预知的故障时,允许损失部分可用性。例如损失响应时间、或者损失部分功能可用性。

S:弱状态,在系统中数据间存在中间状态,且中间状态的存在并不影响系统的基本可用性。例如允许系统在不同副本间同步存在延时。

E:最终一致性,系统中所有副本的数据在一段时间的同步后,最终达到一致的状态。例如MySQL的主从同步是最终一致

目前电商系统,基本采用的都是BASE原理,在有损可用性和有损一致性之前进行权衡。

总结

本文粗浅的进行了ACID、CAP、BASE的介绍,掺杂了一些自己的理解。对于分布式基本理论的理解,对了解自己的系统的设计原因/不足分析、进行实际的编码、系统设计和不同系统之间的探讨(撕逼)都有十分重要的意义。

参考

  1. 《从Paxos到ZooKeeper分布式一致性原理与实践》

  2. CAP理论十二年回顾:”规则”变了

  3. CAP原理