之前讲到单机redis的为了保证数据安全，必须做好数据备份等基础工作。但是如果流量越来越大，
redis的读写请求压力越来越大，到了一个极限值，性能依旧不够用我们应该如何处理？
这边文章就分为以下几步来一次介绍redis读写分离：
- 1、两个问题分析redis瓶颈
- 2、解释什么是读写分离以及读写分离流程与原理
- 3、读写分离对于数据的安全意义
- 4、docker搭建一主两从读写分离的实战（附带配置和操作流程）
- 5、总结
1、两个问题分析redis瓶颈
所以先看看一下两个问题:
- 1.redis不能支撑高并发的瓶颈在哪里？
- 第一，一台redis的性能首先和机器性能，业务复杂度，以及redis操作的复杂度这三点是密切相关的。
- 如果是单纯的String ，key，value操作，性能一般能到1-5w qps。
- 第二，当一台性能不够用，可以横向扩展机器，就能达到扩容的效果。
单机redis瓶颈.png
- 2.如何redis要支撑超过10w+的并发，那应该怎么做？
- 单机redis几乎不可能超过10w+，除非机器性能非常好，物理机，维护好，操作简单
- 所以必须能横向扩展，采取读写分离主从架构（master - slave）
- 一个主节点，只写数据
- 多个从节点，主节点把数据同步给多个从节点
- 然后读就从从节点读，分摊读压力，从节点还可以横向扩展
redis主从架构示意.png
注意：读写分离是分摊读请求的压力，如果是写请求的操作瓶颈，需要通过cluster让多节点写，
或者通过异步队列，异步完成写操作的方式解决
2、解释什么是读写分离以及读写分离流程与原理
读写分离就是基于redis replication搭建多个redis节点，然后分为master主节点，slave从节点。
master节点主要作用是接收所有写请求，写数据，然后同步到slave。然后多个slave节点，每个都有
全量的数据，分摊读请求。简单是说，就是master只负责写和同步数据到slave，slave只负责读。
这种架构适用于读多写少的系统，slave可以横向扩展，接收更多的读请求。
redis replication基本原理.png
master和slave数据同步的完整流程
首先介绍一下复制过程中的一些核心机制
-
offset
- master和slave都会维护一个offset
- 主要作用是在全量复制过程中记录上方的数据差异
- slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset
- 这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况
-
backlog
- master node有一个backlog，默认是1MB大小
- master node给slave node复制数据时，也会将数据在backlog中同步写一份
- backlog主要是用来做全量复制中断后的增量复制的
-
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命令
-
psync
- 从节点使用psync从master node进行复制，psync runid offset
- master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复
-
heartbeat
- 主从节点互相都会发送heartbeat信息
- master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
-
主从复制的断点续传
- 如果主从复制过程中，网络连接断开了，那么可以接着上次复制的地方，连续复制下去，而不是从头开始复制一份
- master node会在内存中存一个backlog，master和skave都会保存一个replica offset 还有一个master id ，offset就是保存在backlog中的，如果master和slave网络连接断掉了，slave会让master从上次的replica offset 开始继续复制。但是如果没有找到对应的offset，那么就会执行一次 resynchronhronization
数据复制流程：
-
复制的完整流程
- msater就是根据slave发送的psync中的offset来从backlog中获取数据的
- slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接。
- slave node发送ping命令给master node
- master node第一次执行全量复制，将所有数据发给slave node
- master node后续持续将写命令，异步增量复制给slave node
主从复制的完整的基本流程.png
-
全量复制
- 当slave刚连上来，或者master重启，run id不一致，就执行全量复制
- master执行bgsave，在本地生成一份rdb快照文件
- master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
- master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
- slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
- 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
- 注意：
- master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
- 对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
- client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
- rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间
- 如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟
-
增量复制
- 如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
- master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
- msater就是根据slave发送的psync中的offset来从backlog中获取数据的
-
异步复制
- master每次接收到写命令之后，先在内部写入数据，然后异步发送给slave node
redis主从复制的原理.png
3、读写分离对于数据的安全意义
- 首先，master是必须做数据持久化的，因为这里是数据来源，slave做不做无所谓了。
- 然后，没个slave都有全量数据，也就可以成为master的一个热备份，当master挂了，能顶上去
- slave顶替master在后面哨兵继续讲。
4、docker搭建一主两从读写分离的实战（附带配置和操作流程）
都是放在/data/redis/redis.conf下，dir都是容器内的/data目录。
redis的master节点配置：
port 6379
requirepass "123456"
dbfilename "dump.rdb"
dir "/data"
logfile "/data/redis.log"
save 10 5
appendonly yes
appendfsync everysec
redis的slave配置(slave的ip和端口，填写自己的master，我这里是192.168.5.48 6379)
port 6379
requirepass "123456"
slaveof 192.168.5.10 6379
masterauth "123456"
slave-read-only yes
docker启动脚本
docker run -d --name redis -p 6379:6379 -v /data/redis/:/data/ redis redis-server /data/redis.conf
启动容器后，查看replication的命令
docker exec -it redis /bin/bash
redis-cli -h 127.0.0.1 -a 123456 -p 6379
info replication
操作步骤
- 准备三台centos虚拟机（可参照我之前的文章：virtualBox+vagrant搭建多节点虚机）
- 复制master的redis配置到/data/redis/redis.conf
- 使用docker启动命令启动master的redis
- 另外两台虚拟机重复上面的操作，唯一不同的就是修改redis.conf内容为上面从节点的配置，注意修改slave of的ip和端口
-
三个redis都启动完毕，就在每台机器上执行上面查看replication命令，查看集群是否搭建完毕。下图是搭建成功的示例。
master设置成功replication信息.png
slave设置成功replication信息.png
验证数据同步：
- 首先进入master的redis-cli ，执行
set name along - 然后去从节点去执行命令：
get name,如果发现，能获取到，就说明master把数据同步给了slave
5、总结
- 当面对读多写少的业务场景，可以选择redis主从复制，读写分离的架构
- 单机是redis提高qps的瓶颈，好的架构能横向扩展
- 主从复制，读写分离的一些缺点
- 如何保证高可用？（这个后面在哨兵中讲解）
- 每个redis都是全量数据，比较浪费内存（后面cluster有解决方案）
