redis集群和主从复制的原理详解

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

发现其他哨兵的原理图：

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