这篇开始进行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）并且哨兵改了配置文件：

发现其他哨兵的原理图：

?到此，集群的原理和演示分享完毕，下次分享容量，分片模式等敬请期待！?

?

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。