redis集群如果保证数据一致性_从CAP理论到分布式一致性协议

前言

在分布式开发中，我认为具备CAP理论与了解Raft、Zab等分布式一致性协议是十分有必要的，例如分布式锁的选择，你是选择Redis的主备集群（AP模型）还是选择ZK、etcd（CP模型）呢？

关于分布式锁的文章

从分布式理论到如何做一个生产级别的分布式锁_|-| [- |_ |_ ()-CSDN博客_如何做一个分布式锁​blog.csdn.net

如果不具备这些理论知识，我觉得是无法灵活选择且用好分布式锁的，不同业务场景有不同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的集群是什么样的：