Redis基础知识（学习笔记18--主从集群）
一.主从相关的配置
1.1 masterauth
# If the master is password protected (using the "requirepass" configuration # directive below) it is possible to tell the replica to authenticate before # starting the replication synchronization process, otherwise the master will # refuse the replica request. # # masterauth <master-password> #
因为我们要搭建主从集群，且每个主机都有可能会是Master，如果设置验证属性requirepass。一定要每个主机的密码都设置为相同的。此时每个配置文件中都要设置两个完全相同的属性：requirepass与masterauth。其中requirepass用户指定当前主机的访问密码，而masterauth用于指定当前slave访问master时向master提交的访问密码，用于让master验证请求者身份是否合法。
1.2 repl-disable-tcp-nodelay
# Disable TCP_NODELAY on the replica socket after SYNC? # # If you select "yes" Redis will use a smaller number of TCP packets and # less bandwidth to send data to replicas. But this can add a delay for # the data to appear on the replica side, up to 40 milliseconds with # Linux kernels using a default configuration. # # If you select "no" the delay for data to appear on the replica side will # be reduced but more bandwidth will be used for replication. # # By default we optimize for low latency, but in very high traffic conditions # or when the master and replicas are many hops away, turning this to "yes" may # be a good idea. repl-disable-tcp-nodelay no
该属性用于设置是否禁用TCP特性tcp-nodelay。设置为yes则禁用tcp-nodelay，此时master与slave间的通信会产生延迟，但使用的TCP包数量较少，占用的网络带宽会较小。相反，如果设置为no，则网络延迟会变小，但使用的TCP包数量会较多，相应占用的网络带宽会变大。
知识点补充---tcp-nodelay
为了充分复用网络带宽，TCP总是希望发送尽可能大的数据块。为了达到该目的，TCP中使用了一个名为Nagle的算法。
Nagle算法的原理是，网络在接收到要发送的数据后，并不直接发送，而是等待着数据量足够大（由TCP网络特性决定）时再一次性发送出去。这样，网络上传输的有效数据的比例就等到了大大提升，无效数据的传输极大减少，于是就节省了网络带宽，缓解了网络压力。
tcp-nodelay 则是TCP协议中Nagle算法的开关。
1.3 pidfile
# If a pid file is specified, Redis writes it where specified at startup # and removes it at exit. # # When the server runs non daemonized, no pid file is created if none is # specified in the configuration. When the server is daemonized, the pid file # is used even if not specified, defaulting to "/var/run/redis.pid". # # Creating a pid file is best effort: if Redis is not able to create it # nothing bad happens, the server will start and run normally. # # Note that on modern Linux systems "/run/redis.pid" is more conforming # and should be used instead. pidfile /var/run/redis_6379.pid
如果是多实例安装（一台机器上安装多个redis实例），记得要修改这个参数。
当然，另外一些参数配置
端口号（port）、dbfilename、appendfilename、logfile、replica-priority
简单说下 replica-priority
# The replica priority is an integer number published by Redis in the INFO # output. It is used by Redis Sentinel in order to select a replica to promote【提升；晋升；】 # into a master if the master is no longer working correctly. # # A replica with a low priority number is considered better for promotion, so ##越小优先级越高 # for instance if there are three replicas with priority 10, 100, 25 Sentinel # will pick the one with priority 10, that is the lowest. # # However a special priority of 0 marks the replica as not able to perform the ##特殊的优先级的值为0 # role of master, so a replica with priority of 0 will never be selected by ##0丧失了称为master的可能性 # Redis Sentinel for promotion. # # By default the priority is 100. replica-priority 100
1.4 个性化的配置依赖参数include
################################## INCLUDES ################################### # Include one or more other config files here. This is useful if you # have a standard template that goes to all Redis servers but also need # to customize a few per-server settings. Include files can include # other files, so use this wisely. # # Note that option "include" won't be rewritten by command "CONFIG REWRITE" # from admin or Redis Sentinel. Since Redis always uses the last processed # line as value of a configuration directive, you'd better put includes # at the beginning of this file to avoid overwriting config change at runtime. # # If instead you are interested in using includes to override configuration # options, it is better to use include as the last line. # # Included paths may contain wildcards. All files matching the wildcards will # be included in alphabetical order. # Note that if an include path contains a wildcards but no files match it when # the server is started, the include statement will be ignored and no error will # be emitted. It is safe, therefore, to include wildcard files from empty # directories. # # include /path/to/local.conf # include /path/to/other.conf # include /path/to/fragments/*.conf # ################################## MODULES #####################################
例如我们想独立出一个配置文件，但是呢，只想修改几个或者少部分参数项，这时候，可以include进基本的配置文件，只把需要修改的参数，重写下即可。
二. 设置主从关系
2.1 查看
先查看下主从关系，查看指令
> info replication
在主节点上执行，
返回值 role 代表当前节点的角色；
connected_slaves的数值代表 从节点 的个数；
如果有slave节点的话，会以slave0、slave1 呈现出具体的slave信息（ip:port:state:offset:lag）。
而在从节点上执行的话，返回值是不一样的:
返回值role 代表集群角色，其他的返回值还有master_ip、master_port、master_link_status、master_last_io_seconds_age、master_sync_in_process、slave_read_only等等。
需要注意的是从节点是不可以执行写命令的，否则报错
（error）READONLY You can't write against a read only replica.
2.2 设置命令
在从节点上执行命令，如下
> slaveof host(主节点ip) port（主节点的端口号）
只执行上面的命令，如果从节点重启的话，主从关系就会失效，即丢失已设置的主从关系。
2.3. 分级管理
若redis主从集群中的slave较多时，他们的数据同步过程会对master形成较大的性能压力。此时，可以对这些slave进行分级管理。
设置方式很简单，只需要让低级别slave指定其slaveof的主机为上一级slave即可。不过，上一级slave的状态仍为slave,只不过，其是更上一级的slave。
调整主从关系，不需要关闭已有关系，再重建，而是直接执行 slaveof host port 进行调整即可。
2.4 容灾冷处理
在master/slave的redis集群中，若master出现了宕机怎么办？有两种处理方式，一种是通过手工角色调整，使slave晋升为master的冷处理；一种是使用哨兵模式，实现redis集群的高可用HA，即热处理。
无论master是否宕机，slave都可以通过下面的命令，将自己提升为master。
> slaveof no one
如果其原本就有下一级的slave，那么，其就直接变为了这些slave的真正的master了。而原来的master就会失去了这个原来的slave。
三. 主从复制原理
3.1 主从复制过程
当一个redis节点（slave）接收到类似slaveof 127.0..1 6379 的指令后直至其可以从master持续复制数据，大体经历了如下几个过程：
（1）保存master地址
当slave接收到slaveof <master_ip> <master_port>指令后，slave会立即将新的master的地址保存下来。
（2）建立连接
slave中维护着一个定时任务，该定时任务会尝试着与该master建立socker连接。
（3）slave发送ping命令
连接成功后，slave会发送ping命令，进行首次通信。如果slave没有收到master的回复，则slave就会主动断开连接，下次的定时任务会重新尝试连接。
（4）对slave身份验证
master 在接收到slave的ping命令后，并不会立即对其进行回复，而是先对Salve进行身份验证。如果验证不通过，则会发送消息拒绝连接；。验证通过，master 向slave发送连接成功响应。
（5）master持久化
slave在成功接收到master的响应后，slave向master发出数据同步请求。master在接收到数据同步请求后，fork出一个子进程，让子进程以异步方式立即进行数据持久化。
（6）数据发送
持久化完毕后，master再fork出一个子进程，让子进程以异步方式将数据发送给slave。slave会将接收到的数据不断写入到本地的持久化文件中。
在slave数据同步过程中，master的主进程仍在不断地接受着客户端的写操作，且不仅将新的数据写入到master内存，同时也写入到了同步缓存。当master的持久化文件中的数据发送完毕后，master会再将同步缓存中新的数据发送给slave，由slave将其写入到本地持久化文件中。数据同步完成。
（7）slave恢复内存数据
数据同步完毕后，slave就会读取本地持久化文件，将其恢复到本地内存数据，然后就可以对外提供服务了。
（8）持续增量复制
对外服务中master持续接收到写操作，会以增量方式发送给slave，以保证主从数据的一致性。
流程概况如下
考虑到数据发送过程中，仍由数据进来，补充如下：
3.2 数据同步演变过程
（1）sync 同步
redis 2.8 版本之前，首次通信成功后，slave会向master发送sync数据同步请求，然后master就会将其所有数据全部发送给slave，由slave保存到其本地的持久化文件中。这个过程称为全量复制。
但这里存在一个问题：在全量复制过程中可能会出现网络抖动而导致复制过程中断。当网络恢复后，slave与master重新连接成功，此时slave会重新发送sync请求，然后会从头开始全量复制。
由于全量复制过程非常耗时，所以期间出现网络抖动的概率很高。而中断后的从头开始不仅需要消耗大量的系统资源、网络带宽，而且可能会出现长时间无法完成全量复制的情况。
（2）psync
redis 2.8 版本之后，全量复制采用了psync（Partial Sync，不完全同步）同步策略。当全量复制过程出现由于网络抖动而导致复制过程中断时，当重新连接成功后，复制过程可以“断点续传”。即从断点位置开始继续复制，而不用从头再来。这样大大提升了性能。
为了实现psync，整个系统做了三个大的变化：
A. 复制偏移量
系统为每个需要传送数据进行了编号，该编号从0开始，每个字节一个编号。该编号称为复制偏移量。参与复制的主从节点都会维护该复制偏移量。
可以通过 命令info replication 的返回结果中的 slave_repl_offset （从节点）或 master_repl_offset（主节点 代表已发送出去的数据）值查看。
B.主节点复制ID
当master启动后，就会动态生成一个长度为40位的16进制字符串作为当前master的复制ID，该ID是在进行数据同步时slave识别master使用的。通过 info replication 的master_replid属性可查看到该ID。
特别注意：master redis 重启，动态生成的复制ID就会变化。
C.复制积压缓冲区
当master有连接的slave时，在master中就会创建并维护一个队列backlog，默认大小为1MB，该队列称为复制积压缓冲区。master接收到了写操作，数据不仅会写入到了master主存，写入到了master中为每个slave配置的发送缓存，而且还会写入到复制积压缓冲区。其作用就是用于保存最近操作的数据，以备“断点续传”时做数据补偿，防止数据丢失。
D. psync 同步过程
psync是一个由slave提交的命令，其格式为psync <master_replid> <repl_offset> ，表示当前slave要从指定中的repl_offset+1处开始复制。 repl_offset表示当前slave已经完成复制的数据的offset。该命令保证了“断点续传”的实现。
在第一次开始复制时，slave并不直到master的动态ID，并且一定时从头开始复制，所以其提交的psync命令为PSYNC ? -1。即master_replid 为问号（？），repl_offset为-1。
如果复制过程中断后，slave与master成功连接，则save再次提交psync命令。此时psync命令的repl_offset参数为其前面已经完成复制的数据的偏移量。
其实，并不是slave提交psync命令后就可以立即从master处开始复制，而是需要master给出响应结果后，根据响应结果来执行。master根据slave提交的请求及master自身情况会给出不同的响应结果。响应结果有三种可能：
- FULLRESYNC <master_replid> <repl_offset>：告知slave当前master的动态ID及可以开始全量复制了，这里的repl_offset一般为0。
- CONTINUE：告知slave可以按照你提交的repl_offset后面位置开始“续传”了。
- ERR：告知slave，当前master的版本低于redis 2.8 ,不支持psync，你可以开始全量复制。
psync过程概况如下
E. psync存在的问题
- 在psync数据同步过程中，若slave重启，在slave内存中保存的master的动态ID与续传需要的offset都会消失，“断点续传”将无法进行，从而只能进行全量复制，导致资源浪费。
- 在psync数据同步过程中，master宕机后slave会发生“易主”，从而导致slave需要从新master进行全量复制，形成资源浪费。
（3）psync 同步的改进
Redis 4.0 对psync进行了改进，提出了“同源增量同步”策略。
A. 解决slave重启问题
针对“slave重启时master动态ID丢失问题”，改进后的psync将master的动态ID直接写入到了slave的持久化文件中。
slave重启后直接从本地持久化文件中读取master的动态ID，然后向master提交获取复制偏移量的请求。master会根据提交请求的slave地址，查找到保存在master中的复制偏移量，然后向slave回复FULLRESYNC <master_replid> <repl_offset>，以告知slave其马上要开始发送的位置。然后master开始“断点续传”。
B. 解决slave易主问题
slave易主后需要和新master进行全量复制，本质原因是新master不认识slave提交的psync请求中的“原master的动态ID”。如果slave发送psync <原master_replid> <repl_offset> 命令，新的master能够识别出该slave要从原master复制数据，而自己的数据都是从该master复制来的。那么新master就会明白，其与该slave"师出同门"，应该接收其“断点续传”同步请求。
而新master中恰好保存的有“原master的动态ID”。由于改进后的psync中每个slave都在本地保存了当前的master的动态ID，所以当slave晋升为新的master后，其本地仍保存有之前master的动态ID。而这一点也恰恰为解决“slave易主”问题提供了条件。通过master的info replication 中master_replid2 可以查看到。如果尚未发送易主，则该值为40个0。
(4) 无盘操作
Redis 6.0 对同步过程又进行了改进，提出了“无盘全量同步”与“无盘加载”策略，避免了耗时的IO操作。
- 无盘全量同步：master的主进程fork出的子进程直接将内存中的数据发送给slave,无需经过磁盘。
- 无盘加载：slave在接收到master发送来的数据后不需要将其写入到磁盘文件，而是直接写入到内存，这样slave就可快速完成数据恢复。
(5) 共享复制积压缓冲区
Redis 7.0 版本对复制积压缓冲区进行了改进，让各个slave的发送缓冲区共享复制积压缓冲区。这使得复制积压缓冲区的作用，除了可以保障数据的安全性外，还作为所有slave的发送缓冲区，充分利用了复制积压缓冲区。
学习参阅特别声明
【Redis视频从入门到高级】
【https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】