前言
在分布式开发中,我认为具备CAP理论与了解Raft、Zab等分布式一致性协议是十分有必要的,例如分布式锁的选择,你是选择Redis的主备集群(AP模型)还是选择ZK、etcd(CP模型)呢?关于分布式锁的文章 点击这里查看 ,如果不具备这些理论知识,我觉得是无法灵活选择且用好分布式锁的,不同业务场景有不同AP、CP模型的需求,例如为什么Nacos的配置中心使用CP模型,但注册中心却使用AP模型呢?这都是不同的场景有着不同的考量。说了那么多,那么为什么CAP总是在CP与AP之间讨论?接着往下看。
CAP理论
CAP理论是在分布式集群环境下讨论的,为什么分布式集群环境下会存在CAP问题呢?举个例子,假设我们后端存储服务使用Redis中间件,如果只部署一台Redis服务器,那么这台Redis如果挂了,整个存储服务都挂了,那么我们就想要提高它的可用性,怎么办呢?最简单的方法就是加机器:
- 可用性:我部署两台Redis机器在一个集群中(主备集群),如果此时有一台Redis挂了我客户端照样可以访问另一台Redis,保证了一定程度的可用性(保证允许一台Redis宕机)
同时这两台主备Redis需要时刻保持数据同步,这样在一台宕机之后另一台也能保持原有的查询服务:
- 一致性:如果我客户端在A节点的Redis设置了一个M值,然后A节点宕机,此时换B节点的Redis上,如果B节点正好同步了这个M值,就保证了一致性,但是有可能B节点的Redis还没来得及同步这个M值,我客户端在B节点读不到M值,这就存在了一致性问题
那什么是分区容错性呢(P)?
- 分区容错性:这两台主备Redis发生了分区(A、B节点互相连接不上),那就做不了数据同步了,但此时集群依然向外开放服务,此时集群具有分区容错性,如果发生分区,集群就不能对外服务,则集群不具有分区容错性(P特性)
分区容错性,代表当分布式节点发生分区(A、B节点互相连接不上)此时的分布式系统是否还提供服务(是否容错),如果没有了P,代表发生分区之后整个分布式集群不能使用,这显然是不行的。下面看看保证P与不保证P的集群是什么样的:
- 如果没了P,理论上集群不容许任何一个节点发生分区,当没有分区发生时确实可以保证AC(谁能保证集群系统的节点百分百不会出问题呢?能保证也不需要讨论AC问题了),当发生分区时整个集群不可用,没有现实意义(如图1)
- 如果保证P,说明集群就只能从A和C选择其一(如图2)
综