redis 配置主从复制模式

从节点 ：

replicaof 192.168.33.131 6379 ### 从本机6379的实例中复制数据，5.0版本之前使用slaveof

replica-read-only yes ### 配置从节点只读 5.0版本之前使用slave-read-only

原理：

Redis 虽然读、写速度快，但是也会产生读压力特别大的情况。

为了分担读压力，Redis 支持主从复制，Redis 的主从结构 --- 采用一主多从或级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步

全量同步 ：

redis 全量复制一般发生在 slave 节点初始化阶段，这时 Slave 需要将 master 上的所有数据都复制一份

过程：

1、从节点连接主节点，并发送 sync 命令
2、主节点接收到 sync 命令后，开始执行 bgsave 命令生成 rdb 文件，并使用 buffer 记录此后执行的所有写命令
3、主节点 bgsave 执行完之后，向所有从节点同步快照文件，并在发送期间继续记录被执行的写命令
4、从节点收到快照文件后，丢弃所有旧数据，并载入收到的快照 
5、主节点快照发送完毕后，通过 socket 开始向从节点发送 buffer 中的写命令
6、从节点完成对快照的载入，开始接收写命令请求，并执行来自主节点 buffer 的写命令；

增量同步：

slave 节点初始化后，开始正常工作时主节点发生的写操作同步到从节点的过程

过程：主节点每执行一个写命令就会向从节点发送相同的写命令，从节点接收并执行收到的写命令

redis 主从同步策略：

主从刚建立连接时，进行全量同步；全量同步结束后，进行增量同步；

无论如何，首先尝试进行增量同步，如不成功，则进行全量同步；

注：主从复制风暴问题 ：

一旦多个 Slave 节点断线，需要重启时，因为只要 Slave 启动，就会发送 sync 请求和主节点进行全量同步，而多个同时出现时，可能导致 Master IO 剧增，而宕机

让部分从节点与从节点同步数据，减少主节点的压力

Redis 主从复制的几点重要内容：

1）Redis 是异步复制，Redis 2.8 开始，从节点会周期性的应答，完成增量数据同步
2）一个主服务器可以有多个从服务器；
3）从节点也可以接受其他从节点的连接；多个从节点可以连接到一个主服务器，多个从节点也可以连接到一个从节点，形成一个图状结构
4）Redis 主从复制不阻塞主节点；也就是说当若干个从节点在进行初始同步时，主节点仍然可以处理请求。
5）主从复制也不阻塞从节点；
### 当从节点同主节点失去连接或者主从复制正在进行，从机库有两种运行方式：
### 1) slave-serve-stale-data 设置 yes(默认)，从节点会继续响应客户端的请求；
### 2) slave-serve-stale-data 设置 no，除去 INFO 和 SLAVOF 命令之外的任何请求都会返回一个错误”SYNC with master in progress”
当从节点进行初始同步时，它使用旧版本（RDB快照或者AOF日志）的数据应答查询请求或者给客户端返回一个错误信息。
但是，当初始同步完成后，需要删除旧的数据集和加载新的数据集，在这个短暂的时间内，从节点会阻塞连接请求
6）主从复制可以增强扩展性；多个从节点处理只读请求（或者繁重的排序操作），或者处理数据冗余。
7）主从复制备份数据，作为一种数据持久化方式，免除了主服务器把数据写入磁盘的IO消耗；
### 主节点的 redis.conf 文件中配置（注释掉所有“保存“命令），然后连接一个配置为“进行保存”的从服务器即可。但是这个配置要确保主服务器不会自动重启（要获得更多信息请阅读下一段）

Redis大概主从同步是怎么实现的？

全量同步：
master 节点开启一个后台进程（fork一个子进程）用于将 redis 内存数据生成一个rdb文件，与此同时，服务器缓存所有来自客户端的写命令（包含增、删、改）；
当后台写RDB文件处理完毕后，将该 rdb 文件发送给 slave 服务器，而 slave 服务器会将 rdb 文件保存在磁盘，并通过读取该 RDB 文件将数据加载到内存；
在此之后，master 节点会将在此期间缓存的命令通过 redis 传输协议发送给 slave 节点，然后 slave 节点将这些命令依次重放，使得本地的数据集上最终达到数据的一致性；

部分同步：部分同步过程中，master 节点会将本地记录的同步备份日志中记录的指令依次发送给 slave 节点从而达到数据一致
redis 2.8 版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master 节点和 slave 节点之间都是进行全量数据同步；
redis 2.8开始，部分同步的实现依赖于 master 节点内存中给每个 slave 节点维护了一份同步日志（backlog,默认1M）和同步标识；
每个 slave 节点在跟 master 节点进行同步时，都会携带自己的同步标识和上次同步的最后位置，当主从连接断掉之后，slave 节点（隔断时间默认1s）主动尝试和 master 节点进行连接；
如果 slave 节点携带的偏移量标识还在 master 节点上的同步备份日志中，那么就从 slave 发送的偏移量开始继续上次的同步操作；
如果 slave 节点携带的偏移量标识已经不再 master 的同步备份日志中（可能由于主从连接断掉的时间比较长或在断掉的短时间内 master 节点接收到大量的写操作），此时必须进行一次全量更新。

主从同步中需要注意几个问题：

1）全量同步过程中，master 将数据保存在 rdb 文件，然后发送给 slave，但是如果 master 上的磁盘空间有限怎么办呢？

此时全部同步对于 master 来说将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的，由 master 直接开启一个 socket 将 rdb 文件发送给 slave 服务器。
（无盘复制一般应用在磁盘空间有限但是网络状态良好的情况下）
### 是否使用无盘复制 Diskless replication，默认 no 
repl-diskless-sync no 

### 无盘复制延时开始秒数，默认5秒，意思是当 PSYNC 触发的时候，master 延时多少秒开始向 slave 传送数据流，以便等待更多的 slave 连接可以同时传送数据流
### 因为一旦 PSYNC 开始后，如果有新的 slave 连接 master，只能等待下次 PSYNC。配置为 0 ，则为取消等待，立即开始 
repl-diskless-sync-delay 5 

### 复制流的内存缓冲区大小，用于增量同步，当主从连接断开时，master 保存在复制流内存缓冲区的数据大小限制，默认是1mb。如果至少有 1 个 slave 连接的话，缓冲区就会被释放 
repl-backlog-size 1mb

### 复制流的内存缓冲区过期时间，默认 3600秒，就是说无论保存在复制流内存缓冲区的数据大小是否超过限制，当主从连接断开超过上述时间，缓冲区就会释放
repl-backlog-ttl 3600  

2）主从复制结构，一般 slave 服务器不能进行写操作，是为了更容易的保证主和各个从之间数据的一致性，如果 slave 服务器上数据进行了修改，那么要保证所有主从服务器都能一致，可能在结构上和处理逻辑上更为复杂
配置让从服务器支持写操作：
### 2.8版本开始，可以配置与 master 连接的 slave 的最少数量，默认是0没有限制，如果配置>0，需要结合下面的选项一起使用，只有同时满足这2个选项，slave 才能接收写操作 
min-slaves-to-write 3

### 允许 master-slave 的心跳最大间隔，默认是10秒，需要结合 min-slaves-to-write 选项一起使用
min-slaves-max-lag 10 
 
3）主从节点之间会定期进行通话，如果 master 设置了密码，不给 slave 设置密码，就会导致 slave 不能跟 master 进行任何操作；
 
4）slave 节点上过期键的处理，是由 master 节点负责键的过期删除处理，然后将相关删除命令以数据同步的方式同步给 slave 节点，slave 节点根据删除命令删除本地的key

redis 执行lua脚本，可以实现事务操作：

eval "return {KEYS[1],KEYS[1],ARGV[1],ARGV[2]}" 2 key1 key2 first second

注：lua 脚本不能出现死循环或者耗时计算，否则redis会阻塞，将不会接受其他命令，单线程执行脚本命令