Redis—AKF服务拆分原则、CAP理论前置、数据一致性理论与方案

监控集群也可能出现网络等问题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