REDIS如何通过读写分离来承载读写分离来承载请求的QPS超过10万+【redis replication的核心机制】+redis主从架构的核心原理

1. redis如何通过读写分离来承载读请求的QPS超过10万+

· 图文理解？学习更爽？理解更快？

· 将redis缓存架构做成一主多从，主分支master node主要负责写入数据，并且将数据同步复制到其他的slave node分支节点，其余的从分支主要负责读取请求，所有的读取数据的请求全部走从节点，也就是slave node节点

【如图：redis单机支持每秒10万+QPS基本原理】

从上面的图中就可以分析出来，master node主节点主要负责的是写请求，slave node分支主要负责读请求，同样，这些配置都是在redis.conf中修改，主要修改两个位置：

1.在slave node中的redis.conf文件中搜索/slave of 在后面添加主节点的host+ip，例如slave of 192.168.0.111 6379 ；
2.执行强制的读写分离，默认就是开启的，在slave node中的redis.conf文件中有这样的一个配置，slave-read-only，这个配置打开后会拒绝所有的写请求，只提供读取的服务；
3.安全认证，在master node这个节点的redis.conf中开启口令认证require pass XXX设置连接口令，在slave node的配置文件redis.conf文件中的masterauth XXX配置相同的连接口令即可；

针对上面特地提示一个注意事项：

· 先启动主节点的redis实例后，再启动从节点实例，发现连接不上，发现slave
node这个节点一直连接不上主节点，原因修改一下每个slave node的conf文件中的bind，配置成主节点的host+ip即可；

以上基本上一个redis简单的主从架构已经搭建OK了

2.redis replication的核心机制

· redis采用异步方式复制数据到slave节点，不过从redis2.8开始，slave node分支会周期性的确认自己每次复制的数据量【这里先留个伏笔，异步复制数据会出现什么样的问题呢？是否会发生数据的丢失呢？暂时不在此文章做解答】
redis 复制的核心机制：

1.一个master node主支是可以配置多个slave node分支的;
2.slave node 也可以连接其他的slave node的;
3.slave node做数据复制的时候，是不会block(阻止，限制) master node的正常工作的;
4.slave node在做复制的时候，也不会block阻止对自己的查询操作，它会用旧的数据集来提供服务，【但是完成复制的时候，需要删除旧的数据集，加载新的数据集，这个时候可能会暂停对外的服务了】
5.slave node节点主要用来进行横向扩容，做读写分离，扩容的slave node可以提高【读】的吞吐量；

思考一个问题：上一章节讲的RDB和AOF在哪里做呢？

3.master持久化对于主从架构的安全保障的意义

如果采用了主从架构，那么必须建议开启master node的持久化机制！！！
？？？为啥你说开就开呢？？？我在slave node上面开持久化机制不是一样吗？这也是我在学习时候的疑问，直线打脸…
为啥master分支必须要开启持久化机制

不建议用slave node 作为master node的数据冷备份，这样的话，如果关闭了master的持久化机制，可能在master宕机重启的时候，数据是空的，然后经过复制，如之前操作的aof日志的优先机制【这里是上一节文章最后一个图文的解释，提一嘴：当aof和rdb双开的时候，如果没有做相关的操作，master node机器重启，会自动创建一份新的aof的空文件，那么会基于aof的空文件去恢复数据】，slave node此次数据也丢失了

· 没有开启master主支持久化可能存在的问题

1. master ->RDB,AOF都关闭了->数据就全都在内存中，宕机=挂
2. master宕机，重启，是没有本地数据可以恢复的，然后就会直接自认为自己的IDE数据是空的，master就会将空的数据集同步到slave上去，所有的slave的数据全部清空，到达100%丢失状态。

4.master node主支的各种备份方案是否要做

一段话解答【铺垫redis哨兵模式的到来】

1、 master的各种备份方案，究竟要不要做，万一说本地的所有数据文件丢失了，从备份中挑选一份rfb去恢复master，这样才能确保master主支启动的时候，是有数据的；
2、 即使采用了后续的高可用机制【铺垫redis的哨兵模式】，slave node可以自动接管master node，但是也有可能sentinel还没有检查到master failure，master node就自动重启了，还是可能导致slave分支的数据清空故障
3、 master node不关要开启持久化机制，也最好是在云上做好冷备

5. redis主从架构的核心原理(好戏来了)

1.首先slave node连接master node会出现的两种情况：全量推送和断点续传，简单文本的方式解释一下：
· slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据；

从redis2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份

· slave node 第一次连接master node，那么会发送一次full resynchroization【全量推送机制，这个来个解释稍微详细一点点的解释，有两种情况会发生全量推送full resynchroization】

1.1：开始full resynchroization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中，RDB文件生成完毕之后，master
node会将这个RDB发送给slave node，slave
node会先写入本地磁盘，然后再从本地磁盘加载到内存中，然后master会内存中缓存的写命令发送给slave，slave也会同步这些数据。
1.2：slave node如果跟master node有网络故障，断开了连接，会自动重连，master如果发现多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

上图：【redis主从架构核心原理的图解】

再来一波数据复制的完整流程图解

文字解释：

1. slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是此时复制是还没有开始的；
2. slave node 内部有一个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就和master node建立socket网络连接
3. slave node 发送ping命令给master node
4. 口令认证，如果master设置了requirepass，那么slave node必须发送masterauth的口令过去进行认证
5. master node第一次执行全量复制，将所有的数据发送给slave node
6. master node 后续持续将写命令，同步或者是异步复制给slave node

主从复制断点续传的几个机制：
1.无磁盘化复制
master直接在内存中直接创建rdb文件，然后直接发送给slave，不会再自己本地落地磁盘；
这里需要修改下配置文【redis.conf的配置文件修改】

· 第一种：repl-diskless-sync 立刻replication ·
· 第二种：repl-diskless-sync-delay XX 等待一定时长再开始复制，因为要等更多slave重新连接过来；

2.过期key处理

· slave node不会过期key，只会等待master node过期key，如果master过期了一个key或者是通过LRU内部淘汰算法淘汰了一个key，那么会自动模拟一条del命令发送给slave node分支，执行这个指令完成删除key的操作

数据同步的核心机制

1. master和slave都会维护一个offset master会在自身不断累加offset给master，slave也会在自身不断累加offset；
   slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset;
2. backlog master node有一个backlog，默认是1MB大小 master node给slave node复制数据的时候，也会将数据在backlog中同步写一份;
3. master run id info server，可以看到master run id 如果根据host+ip定位master node，是不靠谱的，如果master node重启或者是数据出现了变化，那么slave node应该根据不同的run id去分，run id不同就要做全量复制的操作，如果需要不改run id 重启redis 可以使用【redis-cli debug reload】命令;
4. psync 从节点使用psync从master node进行复制，psync runid offset master node会根据自身的情况返回响应信息，可能是 fullresync runid offset触发全量复制，可能是continue触发增量复制;

总结总结，因为字体的繁多，我也尽可能的简化了很多语言组织，写的不好的地方还请在评论区指出，多多包含；

声明：转发请备出处！谢谢！所有的原图可以找我申领，redis的生产环境的部署，集群的搭建，哨兵模式，主从分离，redis如何支撑海量数据，几十万的QPS，master node和slave node的主从分离痛点等等，包括小到linux上面的静态IP配置，网段，全部画图笔记，可以无条件分享，谢谢大家。