【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部署

实验方式：

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

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

4. get IM和best

正常get key的值

5. 暂停IM所在节点

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

6. 再get IM

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

7. 再get best

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

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

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

9. 再get best

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

---

结论

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

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

---

redis cluster系列文章参考

1. 【Redis】Redis集群架构剖析(1)：认识cluster
2. 【Redis】Redis集群架构剖析(2)：槽位
3. 【Redis】Redis集群架构剖析(3)：集群处理redis-cli指令
4. 【Redis】Redis集群架构剖析(4)：槽位迁移，重新分配
5. 【Redis】Redis集群架构剖析(5)：复制与故障转移