分布式系统与一致性协议
- CAP原理
- AP
- CP
- CA
- 总结
- BASE理论
- 一致性
- 拜占庭将军问题
分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。
分布式系统的设计目标一般包含如下:
- 可用性:可用性是分布式系统的核心需求,
- 可扩展性:增加机器后不会改变或减少改变系统行为,并且能获得近似线性性能提升
- 容错性:系统发生错误时,具有对错误进行规避以及从错误中恢复的能力
- 性能:对外服务的响应延时和吞吐率要能满足用户的需求
虽然分布式架构可以组建一个强大的集群,但实际工作中遇到的挑战要比传统单体架构大得多,具体表现如下:
- 节点之间的网络通信是不可靠的,存在网络延时和丢包等情况
- 存在节点工作出错的情况,节点自身随时也有宕机的可能
- 同步调用使系统变得不具备扩展性
CAP原理
C:Consistency(一致性)。强一致,就是所有节点上的数据时刻保持同步。原子读写,即所有读写都应该看起来是原子的,或串行的。所有的读写请求好像是经过全局排序一样,写后面的毒一定能读到前面所写的内容。
A:Availability(可用性)。任何非故障节点都应该在有限时间内给出请求的响应,不论请求是否成功。
P:Tolerance to the partition of network(分区容忍性)。当部分节点之间无法通信时,在丢失任意多消息的情况下,系统仍然能够正常工作。
在任何分布式系统中,可用性,一致性和分区容忍性是相互矛盾的,三者不可兼得,最多只能取其二。CAP理论只适用于原子读写场景,不支持数据库事务之类的场景。
P案例:G0与G1无法进行通信是可以容忍的。如果出现了分区问题,我们的分布式存储系统还需要继续运行
C案例:对系统G0写操作b,如果能读到b,则为一致性,如果读G1为a则不符合一致性,所以此时G0需要向G1发送消息。当然数据系统故障了,不返回任何数据,也是符合一致性的
A案例:只要收到用户的请求,服务器就必须给出回应。即使两个分布式节点数据不一致,需要返回数据
AP
AP满足但C不满足,如果要高可用和分区容错,那么就要放弃一致性了。因为一旦发生网络分区P,节点之间将无法通信,为了满足高可用A,每个节点只能用本地数据提供服务,这样就会导致数据的不一致性(!C)。经典案例:Eureka
CP
CP满足但A不满足,如果要求各个服务器上数据是强一致的C,然而网络分区P会导致同步时间无限延长,那么如果以来可用性就得不到保障了。经典案例:Zookeeper
坚持数据ACID(原子性,一致性,隔离性,持久性)的传统数据库以及对结果一致性非常敏感的应用(例如:金融业务)通常会做这样的选择
CA
CA满足但是P不满足,如果不存在网络分区,那么强一致性和可用性是可以同时满足的。
总结
但是在分布式系统内,实际上P是必然的,如果不选P,一旦发生分区错误,整个分布式系统完全无法使用了,这是不符合需要的,所以对于分布式系统,我们只能考虑当分区发生错误时,如果选择一致性和可用性。所以最后只有CP和AP系统了。
BASE理论
BASE:Basic Availability,Soft state,Eventually Consistency。是由CAP理论衍生出来的,即使无法做到强一致性(Strong Consistency),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。
一致性
拜占庭将军问题
描述:拜占庭帝国(Byzantine Empire)军队的几个师驻扎在敌城外,每个师都由各自的将军指挥。将军们只能通过信使相互沟通。在观察敌情之后,他们必须制定一个共同的行动计划,如进攻(Attack)或者撤退(Retreat),且只有当半数以上的将军共同发起进攻时才能取得胜利。然而, 其中一些将军可能是叛徒,试图阻止忠诚的将军达成一致的行动计划。 更糟糕的是,负责消息传递的信使也可能是叛徒,他们可能篡改或伪造消息,也可能使得消息丢失