单点Redis的缺点：
1.单点故障
2.容量有限
3.IO压力
故我们需要使用某些方式对Redis服务进行拆分，使其可以解决这些问题
AKF拆分原则(可适用在mysql,微服务等)
1.横向X轴：把redis进行主从或者主备，使redis可以解决单点故障实现读写分离
2.纵向Y轴：把不同的数据分散在不同的Redis节点上
3.Z轴：按照优先级，和业务逻辑等再次拆分
AKF
Redis主从数据同步（一致性）模型：
讨论一下redis可用的
-
同步阻塞模型，保证强一致性，在数据同步时不对外提供服务，最终阻塞到所有节点数据完全一直，会破坏可用性，比如在数据同步时存储一些数据不成功
Redis强一致性模型 -
异步，弱强一致性，会丢失数据
Redis异步模型 -
最终一致性方案，可以通过kafka等消息中间件，完成数据同步
Redis最终一致性模型
Redis实现高可用的推导：
主从、主备的概念：
主从：主节点和从节点同时提供服务，比如主节点提供写服务，从节点提供读服务，完成读写分离
主备：只有主节点提供服务，从节点同步主节点的数据，主节点宕机，从节点顶上
-
此时无论使用主从还是主备，都有一个主的概念，此时主机都是单点的，所以需要实现主节点的高可用
Redis主从，主备模型
如果实现高可用，我们可以用最简单的方式，比如人工监控，当主节点宕机，把从节点设置为主节点，根据这种思路，我们需要有一种程序帮我们实现这个功能，起到一个监控节点的作用。此时监控的程序也会有单点问题，我们也需要对监控程序做集群。
使用监控集群
问题的抛出：当我们使用监控集群时，需要集群中有多少台监控节点做出对主节点的相应才有效呢？（如图3台）
- 如果3台：需要所有监控节点判断redis状态OK，此时某个节点出现网络波动或者其他因素印象，将导致redis服务不可用(强一致性)
- 如果1台：只需要一个节点判断redis状态OK，此时每一个节点判断的结果可能不同(统计不准确)，导致网络分区或称脑裂
结论：2台 - 即n/2+1，过半
过半性
此时要注意的是，尽量使用单数节点 - 4节点和3节点对比
1.4节点的成本更高，机器数量
2.4节点比3节点更容易出现问题
