监控集群也可能出现网络等问题1)、若必须满足监控集群的节点都给出OK，才能使用，则属于\"强一致性\"2)、只由集群中的部分节点给出OK（过半，防止脑裂），即可使用，另一部分的节点给出的不算数，此可以理解为势力范围3)、对照以下两组扩展，再得出下一篇幅的结论：脑裂
监控3
商品库备/从
主Redis
client
客户端
同步阻塞
网络分区脑裂并非都是不好的
商品库2备/从
等价于
3)、Z轴方向：解决Y轴方向的单机容量和访问压力的问题 当Y轴拆分的单个实例，达到一定规模之后，容量和单机访问压力也会变大。 将已经按照业务进行拆分的Redis库，再次进行拆分，如把商品库拆分成商品库1和商品库2，只要确保访问时能放到即可。
2)、方案二：弱一致性，异步非阻塞方案， 可能会有部分数据丢失
Redis备/从
监控5
MQ可靠（持久化）可用（集群）响应速度快
Redis
2)、Y轴方向：解决单机容量和访问压力的问题 将Redis按照业务进行拆分，例如商品Redis库、订单Redis库等； 可以对Y轴方向进行X轴方向的\"备/从\"操作
订单库备/从
Y
监控4
监控集群节点N=4过半节点数量：3可挂节点数量：1
监控1
因果一致性.
读己之所写
单调读一致性
Z
监控
监控2
监控集群节点N=3过半节点数量：2可挂节点数量：1
1)、方案一：强一致性，同步阻塞方案， 但会破坏可访问性
商品库
4)、补充：对于弱一致性或最终一致性方案，客户端访问时，可能出现数据尚未同步的情况，此时更新实现一致性处理
异步非阻塞
AKF设计原则-redis篇1)、X轴方向：解决单点故障问题，但存在单机容量和访问压力 按照主备设计，主机负责读写，备份机只做故障时切换： 改进：主备换成主从，主机负责写操作，各个从机负责读请求，这样备份机资源就不会浪费掉
监控集群节点N=6过半节点数量：4可挂节点数量：2
会话一致性
二、AKF拆分之后，会从单一节点变为多节点，从而带来数据同步问题
三、CAP理论简单描述 reids支持主备和主从，但推荐使用主从，无论采用哪种方案，都需要对主节点做HA， 因此，可以对主节点进程监控，监控程序也必须是集群
综合上面的四种情况，可以得出如下结论 2 在3个监控节点时，成功解决脑裂问题（允许挂1个节点） 3 在4个监控节点时，成功解决脑裂问题（允许挂1个节点） 3 在5个监控节点时，成功解决脑裂问题（允许挂2个节点） 4 在6个监控节点时，成功解决脑裂问题（允许挂2个节点） N/2+1在N个节点时，成功解决脑裂问题一般生产环境中使用奇数台，原因： 以上面四张图四种情况，同一层对比来说： 1)、N=3与N=4承担的风险一致（允许挂1个节点）、N=5与N=6承担的风险也一致； 2)、N=3发生的风险小于N=4、N=5发生的风险小于N=6因此使用奇数个节点。
3)、方案三：最终一致性，同步阻塞方案，
商品库2
HA
最终一致性（多组合实现）
单调写一致性
订单库
监控6
X
监控集群节点N=5过半节点数量：3可挂节点数量：2
