这篇开始进行redis集群和主从复制的原理详解，前几篇我们都是分享的redis在单节点环境中运行的操作，而实际互联网项目中一般都是部署的redis集群，主从复制、主备等环境，今天我们开始详细分享：
1、单实例部署redis的弊端分析：
1）单点故障：即如果该服务挂了，redis也就完全不能用了。
2）容量有限：一台服务的容量一般不大，存储的内容大小有限。
3）压力：所有的读写操作都在改服务上进行，压力回比较大。
2、怎么解决这些弊端呢？
1）集群部署一主多从，主挂了，某个从节点变成主节点。
2）多主多从可以解决容量问题，或者一个项目中不同的业务类型用不同的redis。
3）集群可以设置一写多读，比如主写从读。
如图所示：
x横轴代表集群，y轴代表不同业务采用不同redis,z轴代表多主多从。
3、理论上说，解决一个问题可能回出现新的问题：
比如 主从复制时一致性问题，可用性问题，分区容错性问题，即所谓的CAP理论；一般采用AP或者CP模式，不会满足三项。一主两从的业务场景分析：
1）强一致性，破坏可用性
2）弱一致性，有丢失数据风险
3）最终数据一致性：
注意： 有可能取到不一致的数据 ，主要强调：强一致性。
4、对redis监控的设计思想：
1）三台监控
2）四台监控
3）五台监控
都给出OK 算强一致性，部分给出结果：
5、总结用基数台监控或者搭建集群的原因：
1）一般人认为，技术台容易选举leader，在集群环境下，不容易出现脑裂。这只是一个表象，核心原因是下面几点。
2）奇数台和偶数台承担的风险一样，比如3、4台承担的风险都是1，而4台的成本更大！
3）同时，偶数台发生风险的概率更大，比如3、4台中，4台发生风险的概率更大一些。
6、演示：
创建：
分别 启动：6379、6380、6381，并打开客户端
成功：
开客户端：
7、主从设置：
帮助命令
6379为主：即6380追随6379
6379的日志：
6380日志：
此时主从设置好了，6379 主，6380从
8、测试保存，主从复制：
6379保存：
复制到6380:
默认情况下从是禁止写入的：
此时 6381还没有设置，即数据没有同步过来：
6381先设置一个数据：
然后设置从：
在看6381的数据时：
发现自己6381的老的数据清除了，有的是从主节点复制过来的。日志见证：
也发现了RDB文件：
另外从挂了：
再重启之后依然同步主的增量数据。
ctrl+c 6379主挂了,从可以立刻发现：
6380自己主设置：
6381去追随：
这是人工切换主从节点，比较土！
9、哨兵监控、选举：
1）原理图：
核心配置：
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-backlog-size 1mb
#增量复制
min-replicas-to-write 3
min-replicas-max-lag 10
2）添加配制文件：vi 26379.conf
3）内容：
复制拷贝到每个节点上
都改一下：
5） 启动：
启动：.。。。。127.0.0.1 6379
启动：
监听命令查看
继续：
启动哨兵：
6)都配置：
查看：
查看：
查看：
10、主挂了：
1）选6381为主：
6380 也同步到数据，紧跟6381数据变化。
2）并且哨兵改了配置文件：
发现其他哨兵的原理图：
到此，集群的原理和演示分享完毕，下次分享容量，分片模式等敬请期待！
