是时候把分布式存储系统的理论指导从CAP转到PACELC

作者：常平 2018-06-08 09:10:49

存储

存储软件

分布式 CAP理论是当前分布式存储系统设计的理论指导，而PACELC理论是CAP理论的扩展，分布式存储系统设计的理论依据是时候从CAP理论扩展为PACELC理论。

 CAP理论是当前分布式存储系统设计的理论指导，而PACELC理论是CAP理论的扩展，分布式存储系统设计的理论依据是时候从CAP理论扩展为PACELC理论。

PACELC在wiki上的定义是

“It states that in case ofnetwork partitioning (P) in a distributed computer system, one has to choosebetween availability (A) and consistency (C) (as per the CAP theorem), but else(E), even when the system is running normally in the absence of partitions, onehas to choose between latency (L) and consistency (C).”

简单来说这里的意思就是：”如果有分区partition (P)，系统就必须在availability 和consistency (A and C)之间取得平衡; 否则else (E) 当系统运行在无分区情况下,系统需要在 latency (L) 和 consistency (C)之间取得平衡”

[[232158]]

CAP理论认为以下三者不能同时满足：

1）一致性(Consistency): 所有的节点在同一时刻数据是完全一样的；

2）可用性(Availability): 节点失效不会影响系统的IO；

3）分区容忍性(Partition Tolerance): 系统能支持网络分区（网络连接故障），即使分区之间的消息丢失系统也正常工作；

根据业务场景的不同，不同的分布式存储系统会根据自身业务的需求在CAP三者之中进行权衡， CAP理论的意义是在分布式存储系统设计时需要权衡的因素，而非绝对的三者取其二，并且在CAP理论中没有提到时延（Latency），而时延（Latency）却是很重要的可用性(Availability)指标。

因为CAP没有考虑到系统中的Latency因素，因此定义了一个新的模型PACELC，添加了Latency，如下图：

当前分布式存储系统设计指导理论应当用PACELC理论替代CAP理论，理由如下：

1）PACELC更能满足实际操作中分布式存储的工作场景是更好的工程实现策略；

2）当partition (P)存在的场景下，需要在availability 和consistency (A and C)之间获得权衡，当时实际上分布式系统中绝大多数时间里partition (P)是不存在的，那么就需要在latency (L) 和 consistency (C)之间取得权衡；

3）availability在不存在partition (P)的场景下跟 latency关联,在partition (P)时跟reliable指标关联；

4）PACELC 可以在 latency vs consistency之间获得平衡；

5）CAP 理论忽略了 一致性和时延之间的权衡。

PACELC建立在CAP之上，二者都描述了在一致性(Consistency)，可用性(Availability)和分区容忍性(Partition Tolerance)之间的限制和权衡。而PACELC更进一步描述了即使在没有Partition的场景下，也存在Latency和Consistency之间的权衡，从而为分布式系统的Consistency模型提供了一个更为完整的理论依据。

要保证系统的高可用（high availability）那么就必须复制数据，而进行数据复制，就会出现在Consistency和Latency之间要求做个权衡。

举个PACELC的应用场景栗子，如下图：

1、在强一致性复制场景下，需要三副本都下盘才能返回ok给client端，Master向Slave 复制数据，Latancy的限制是 20ms，有时候，slave 2 硬盘或网络出现故障，Master 往 Slave 复制数据的时延超过 20ms了，这个时候如果还一致等待 slave 2 返回结果再notify 给client就会出现性能和时延抖动，而且这种抖动是经常发生的长尾效应。

2、依据PACELC理论，我们可以在 consistency和Latency之间做个权衡，比如 slave2 节点的时延超过 20ms了，就不等待slave 2 返回，master 和 slave 1 返回结果给client即可，如果 slave 2 出现 超时的 次数超过 5次那么就认为 这个节点可能出现故障，打个故障标签，进行后续的处理。