【redis】Redis 是 AP 架构还是 CP 架构？

最近刚好在看 CAP 理论，加上之前分析的 redis cluster，就在想 redis 的 cluster 是什么模式的，AP 还是 CP？

首先还是简单讲下 CAP，具体的可见 。

CAP 分别是：致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）。

作为一个分布式系统分区容错性一定是需要考虑的，因此 P 一定是有的。但有一点需要注意，分区容错性是允许某部分或者一些节点或者数据丢失的情况下，系统仍能继续工作。这个一些取决于分布式系统里面各自的算法，常见的共识算法。至于 C 和 A 则根据场景来的，CP 更强调数据的一致性，如果有节点挂掉，则所有节点返回失败的信息。AP 更强调服务的可用性，如果有节点挂掉，则节点返回自身写入的最新信息。

本文档就从 redis 的 get 和 set 这两个指令来实验一下，或者验证一下 redis cluter 是 AP 还是 CP。

实验

实验目的：验证一下 redis cluter 是 AP 还是 CP，查看集群节点挂掉之后能否正常提供服务

实验架构：比较简单，就是 3 个 master 搭建起来的 cluster(docker 部署)，没有添加 slave。redis cluster 部署https://xie.infoq.cn/article/0c93d5412b20d5f94e8a725c0

实验方式：

1. set IM和best两个 key 到不同的 2 个节点上

2. 删除一个IM所在节点

3. 分别 get IM和bestkey 的数据，看返回

4. 删除另一个没有 set 的节点

5. get bestkey 的数据，看返回

实验预期：第三步的时候，IM获取不到，best获取得到。第五步的时候，best获取不到了。

实验具体实施

部署 redis cluster 就不细说了

1. 查看 cluster 的 slots，看槽分布

2. 确认要 set 的 key 是否落在 2 个节点里面

3. set IM和best
   

4. best落在 set 执行指令的当前节点，所以不需要 redirected。IM是在第三个节点，所以会需要 redirected 过去。

4. getIM和best
   

5. 正常 get key 的值

5. 暂停IM所在节点

6. 暂停后，查看 cluster info，会发现集群状态是 ok，但有时候收到 fail 的数据，就表示有一个节点下线了

6. 再 get IM
   

7. 这次 get IM，最还是知道IM在之前的节点里面，但是节点已经挂了，就访问不到，符合我们的预期。

7. 再 get best
   

8. 获取正常无下限的节点的数据，显示是正常的，可以正常获取。这可以作为 redis 是 AP 的一个理由，在一个集群中，如果出现分区故障，其他节点还是可以返回当前节点写入的最新数据的。

8. 再下线没有写入 key 的节点

9. 再下线后，集群就剩下一个节点了，这个节点显然不能支撑起这个集群。通过 cluster info 可以看到集群的状态已经从原本的 ok 变成 fail 了。

9. 再 get best
   

10. 这时候，直接就会显示 CLUSTERDOWN，集群已经挂掉了。这个我认为是共识算法无法投票出可用的 master，已经无法让集群提供正确的服务了。

结论

可以看到 redis cluster 在一个节点下线后，是可以提供正常节点的服务的，因此是 AP 架构的。但是在多个节点下线，导致分布式集群不可用的时候，整个集群就不能用了。

当然这只是一个角度来说明 redis cluster 是 AP，还有很多方面可以去分析 redis cluster 是一个 AP 架构。

redis cluster 系列文章参考

1. Redis 集群架构剖析(1)：认识 cluster
   

2. Redis 集群架构剖析(2)：槽位
   

3. Redis 集群架构剖析(3)：集群处理redis-cli指令
   

4. Redis 集群架构剖析(4)：槽位迁移，重新分配
   

5. Redis 集群架构剖析 (5)：复制与故障转移