最近刚好在看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部署
实验方式：
- set
IM和best两个key到不同的2个节点上 - 删除一个
IM所在节点 - 分别get
IM和bestkey的数据，看返回 - 删除另一个没有set的节点
- get
bestkey的数据，看返回
实验预期：第三步的时候，IM获取不到，best获取得到。第五步的时候，best获取不到了。
实验具体实施
部署redis cluster就不细说了
查看cluster的slots，看槽分布
确认要set的key是否落在2个节点里面
set
IM和bestbest落在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的一个理由，在一个集群中，如果出现分区故障，其他节点还是可以返回当前节点写入的最新数据的。
再下线没有写入key的节点
再下线后，集群就剩下一个节点了，这个节点显然不能支撑起这个集群。通过cluster info可以看到集群的状态已经从原本的ok变成fail了。
再get
best这时候，直接就会显示CLUSTERDOWN，集群已经挂掉了。这个我认为是共识算法无法投票出可用的master，已经无法让集群提供正确的服务了。
结论
可以看到redis cluster在一个节点下线后，是可以提供正常节点的服务的，因此是AP架构的。但是在多个节点下线，导致分布式集群不可用的时候，整个集群就不能用了。
当然这只是一个角度来说明redis cluster是AP，还有很多方面可以去分析redis cluster是一个AP架构。
redis cluster系列文章参考
- 【Redis】Redis集群架构剖析(1)：认识cluster
- 【Redis】Redis集群架构剖析(2)：槽位
- 【Redis】Redis集群架构剖析(3)：集群处理redis-cli指令
- 【Redis】Redis集群架构剖析(4)：槽位迁移，重新分配
- 【Redis】Redis集群架构剖析(5)：复制与故障转移