Redis主从复制哨兵集群搭建解析

redis集群三种模式

redis群集有三种模式，分别是主从同步/复制、哨兵模式、Cluster

主从复制：主从复制是高可用redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。

缺陷：故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。

哨兵：在主从复制的基础上，哨兵实现了自动化的故障恢复。

缺陷：写操作无法负载均衡;存储能力受到单机的限制;哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

集群：通过集群，Rdis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

Redis复制相关配置和参数介绍

Redis的复制配置主要包括以下几个参数：

bind：指定主节点的IP地址，从节点会连接到该IP地址上。
port：指定主节点的端口号。
requirepass：指定主节点的认证密码，从节点需要提供正确的密码才能连接到主节点。
slaveof：指定从节点连接的主节点的IP地址和端口号。
masterauth：指定从节点连接主节点的认证密码。

Redis复制过程

主节点将写操作写入内存缓冲区，并将写操作发送给从节点。
从节点接收到写操作后，将其写入自己的内存中。
从节点周期性地向主节点发送SYNC命令，主节点接收到SYNC命令后会执行BGSAVE命令生成RDB快照文件。
主节点将RDB快照文件发送给从节点，从节点接收到RDB快照文件后会将其加载到自己的内存中。
从节点将主节点发送过来的写操作的增量数据进行合并，从而保持与主节点的数据同步。

主从配置示例

主节点配置文件 redis.conf

bind 127.0.0.1
port 6379
requirepass foobared

从节点配置文件 redis.conf

bind 127.0.0.1
port 6380
requirepass foobared
slaveof 127.0.0.1 6379
masterauth foobared

启动主节点

redis-server redis.conf

启动从节点

redis-server redis.conf

验证复制是否成功

redis-cli -h 127.0.0.1 -p 6379
auth foobared
SET key1 value1
redis-cli -h 127.0.0.1 -p 6380
auth foobared
GET key1

主从节点的角色转换

当主节点发生故障或下线时，可以将从节点提升为新的主节点，实现故障转移。
通过在从节点上执行SLAVEOF no one命令，可以将从节点转变为主节点。
在角色转换后，原来的主节点恢复正常后可以作为新的从节点连接到新的主节点上。

主从复制

主从复制原理

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点 (或没有从节点)，但一个从节点只能有一个主节点。

主从复制作用

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 (即写 Redis
数据时应用连接主节点，读 Redis 数据时应用连接从节点)，分担服务器负载；尤其是在写少读多的场景下，通
过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制流程

若启动一个Slave机器进程，则它会向Master机器发送一个“sync command”命令，请求同步连接。
无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中(执行rdb操作)，同时 Master 还会记录修改数据的所有命令并缓存在数据文件中。
后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。
Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个Slave发来的同步请求，则Master 会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的 Slave端机器都正常。

同步复制&异步复制

Redis的主从复制分为同步复制（synchronous replication）和异步复制（asynchronous replication）。

同步复制：在进行写操作时，主节点会将数据先保存到自身的内存中，然后再通过网络发送给所有从节点，并等待所有从节点都确认接收成功才返回结果。这样可以保证数据的完全一致性，但由于需要等待所有从节点的确认，导致了写入速度变慢。
异步复制：与同步复制不同，异步复制只需要主节点将数据发送给从节点，而无需等待从节点的确认。因此，写入速度更高效，但也容易造成数据不一致的情况。当主节点故障切换或者重新连接上线时，如果没有及时处理未被从节点确认的数据，就会导致部分数据丢失。

# 开启同步复制模式
replica-serve-stale-data yes
repl-diskless-sync no
repl-disable-tcp-nodelay no
repl-backlog-size 1mb
repl-timeout 60

# 开启异步复制模式
replica-serve-stale-data yes
repl-diskless-sync yes
repl-disable-tcp-nodelay yes
repl-backlog-size 1mb
repl-timeout 60

replica-serve-stale-data参数用来控制从节点在主节点断开连接期间是否能提供服务；
repl-diskless-sync参数用来指定是否使用磁盘持久化机制进行同步复制；
repl-disable-tcp-nodelay参数用来关闭TCP_NODELAY选项，加快传输速度；
repl-backlog-size参数用来限制从节点的复制积压大小；
repl-timeout参数用来设置超时时间。

Wait指令

Redis 的复制是异步进行的,wait 指令可以让异步复制变身同步复制，确保系统的强一致性(不严格)。wait 指令是Redis3.0版本以后才出现的。

> set key value
oK
>wait 1 0
(integer)1

wait提供两个参数，第一个参数是从库的数量N，第二个参数是时间t，以毫秒为单位。它表示等待wait 指令之前的所有写操作同步到N个从库(也就是确保N个从库的同步没有滞后)，最多等待时间t。
如果时间t=0，表示无限等待直到N个从库同步完达成一致。假设此时出现了网络分区，wait指令第二个参数时间t=0，主从同步无法继续进行， wait指令会永远阻塞，Redis 服务器将丧失可用性。

同步相关知识点

原文

节点运行ID

每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运行ID。
运行ID的主要作用是用来唯一识别Redis节点。从节点保存主节点的运行ID识别自己正在复制的是哪个主节点。当运行ID变化后从节点将做全量复制。
Redis关闭再启动后，运行ID会随之改变，可以使用debug reload命令重新加载RDB并保持运行ID不变，从而有效避免不必要的全量复制。debug reload命令会阻塞当前Redis节点主线程，阻塞期间会生成本地RDB快照并清空数据之后再加载RDB文件。因此对于大数据量的主节点和无法容忍阻塞的应用场景，谨慎使用。

psync命令

从节点使用psync命令完成部分复制和全量复制功能，命令格式：

psync {runId} {offset}

参数含义如下：

runId：从节点所复制主节点的运行id。
offset：当前从节点已复制的数据偏移量。

psync命令运行流程：

1）从节点（slave）发送psync命令给主节点，参数runId是当前从节点保存的主节点运行ID，参数offset是当前从节点保存的复制偏移量，如果是第一次参与复制则默认值为-1。

2）主节点（master）根据psync参数和自身数据情况决定响应结果：
如果回复+FULLRESYNC{runId}{offset}，那么从节点将触发全量复制流程。
如果回复+CONTINUE，从节点将触发部分复制流程。
如果回复+ERR，说明主节点版本低于Redis2.8，无法识别psync命令，从节点将发送旧版的sync命令触发全量复制流程。

同步过程

在从节点执行slaveof命令后，复制过程便开始运作。复制的完整流程如下所示：

1）保存主节点（master）信息。执行slaveof后从节点只保存主节点的地址信息便直接返回，这时建立复制流程还没有开始。

2）从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。从节点会建立一个socket套接字，专门用于接受主节点发送的复制命令。

3）发送ping命令。连接建立成功后从节点发送ping请求进行首次通信，ping请求主要目的如下：

检测主从之间网络套接字是否可用。
检测主节点当前是否可接受处理命令。
如果发送ping命令后，从节点没有收到主节点的pong回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

4）权限验证。如果主节点设置了requirepass参数，则需要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。

5）同步数据集。主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。Redis在2.8版本以后采用新复制命令psync进行数据同步，原来的sync命令依然支持，保证新旧版本的兼容性。新版同步划分两种情况：全量同步和部分同步。

6）命令持续复制。当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

同步类型

Redis在2.8及以上版本使用psync命令完成主从数据同步。

psync命令运行需要以下组件支持：

主从节点各自复制偏移量。
主节点复制积压缓冲区。
主节点运行id。

复制偏移量
参与复制的主从节点都会维护自身复制偏移量。主节点（master）在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在info relication中的master_repl_offset指标中。
从节点（slave）每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量。从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。

复制积压缓冲区
复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区。

由于缓冲区本质上是先进先出的定长队列，所以能实现保存最近已复制数据的功能，用于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息保存在主节点的info replication中：

127.0.0.1:6379> info replication# Replicationrole:master...repl_backlog_active:1 //  开启复制缓冲区repl_backlog_size:1048576 //  缓冲区最大长度repl_backlog_first_byte_offset:7479 //  起始偏移量，计算当前缓冲区可用范围repl_backlog_histlen:1048576 //  已保存数据的有效长度。

增量同步/部分复制

Redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一遍向主节点反馈自己同步到哪里了 (偏移量)。

因为内存的 buffer 是有限的，所以 Redis 主库不能将所有的指令都记录在内存 buffer
中。Redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，那么当网络状况恢复时，Redis 的主节点中那些没有同步的指令在 buffer 中有可能已经被后续的指令覆盖掉了，从节点将无法直接通过指令流来进行同步，这个时候就需要用到更加复杂的同步机制 —— 快照同步。

部分复制使用 psync {runId} {offset} 命令实现。当从节点（slave）正在复制主节点（master）时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点，这样就可以保持主从节点复制的一致性。

部分复制的流程：

1）当主从节点之间网络出现中断时，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制连接。

2）主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内部存在的复制积压缓冲区，依然可以保存最近一段时间的写命令数据，默认最大缓存1MB。

3）当主从节点网络恢复后，从节点会再次连上主节点。

4）当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参数发送给主节点，要求进行部分复制操作。

5）主节点接到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+CONTINUE响应，表示可以进行部分复制。

6）主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

快照同步/全量复制

快照同步是一个非常耗费资源的操作，它首先需要在主库上进行一次 bgsave 将当前内存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点。
从节点将快照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以务必配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。

全量复制的完整运行流程：

1）从发送psync命令进行数据同步，由于是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，所以发送psync-1。

2）主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应。

3）从节点接收主节点的响应数据保存运行ID和偏移量offset。

4）主节点执行bgsave保存RDB文件到本地。

5）主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件。对于数据量较大的主节点，RDB文件从创建到传输完毕消耗的总时间超过repl-timeout所配置的值（默认60秒），从节点将放弃接受RDB文件并清理已经下载的临时文件，导致全量复制失败。Redis支持无盘复制，生成的RDB文件不保存到硬盘而是直接通过网络发送给从节点，通过repl-diskless-sync参数控制，默认关闭。无盘复制适用于主节点所在机器磁盘性能较差但网络带宽较充裕的场景。

6）对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。默认配置为client-output-buffer-limit slave256MB64MB60，如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB时，主节点将直接关闭复制客户端连接，造成全量同步失败。

7）从节点接收完主节点传送来的全部数据后会清空自身旧数据。

8）从节点清空数据后开始加载RDB文件，对于较大的RDB文件，这一步操作依然比较耗时。对于线上做读写分离的场景，从节点也负责响应读命令。如果此时从节点正出于全量复制阶段或者复制中断，那么从节点在响应读命令可能拿到过期或错误的数据。对于这种场景，Redis复制提供了slave-serve-stale-data参数，默认开启状态。如果开启则从节点依然响应所有命令。对于无法容忍不一致的应用场景可以设置no来关闭命令执行，此时从节点除了info和slaveof命令之外所有的命令只返回“SYNC with master in progress”信息。

9）从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，它会立刻做bgrewriteaof操作，为了保证全量复制后AOF持久化文件立刻可用。

全量复制时间开销主要包括：

主节点bgsave时间。
RDB文件网络传输时间
从节点清空数据时间
从节点加载RDB的时间
可能的AOF重写时间

无盘复制

主节点在进行快照同步时，会进行很重的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。
所以从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是指主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一遍将序列化的内容发送到从节点，从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

心跳

主从节点在建立复制后，它们之间维护着长连接并彼此发送心跳命令。

主从心跳判断机制：

1）主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令查看复制相关客户端信息，主节点的连接状态为flags=M，从节点连接状态为flags=S。

2）主节点默认每隔10秒对从节点发送ping命令，判断从节点的存活性和连接状态。可通过参数repl-ping-slave-period控制发送频率。

3）从节点在主线程中每隔1秒发送replconf ack {offset}命令，给主节点上报自身当前的复制偏移量。replconf命令主要作用如下：

实时监测主从节点网络状态
上报自身复制偏移量，检查复制数据是否丢失，如果从节点数据丢失，再从主节点的复制缓冲区中拉取丢失数据。
实现保证从节点的数量和延迟性功能，通过min-slaves-to-write、min-slaves-max-lag参数配置定义。

主节点根据replconf命令判断从节点超时时间，体现在info replication统计中的lag信息中，lag表示与从节点最后一次通信延迟的秒数，正常延迟应该在0和1之间。如果超过repl-timeout配置的值（默认60秒），则判定从节点下线并断开复制客户端连接。即使主节点判定从节点下线后，如果从节点重新恢复，心跳检测会继续进行。

同步过程中数据一致性问题

在redis主从复制过程中,由于网络异常、文件写入异常等原因,从节点无法与主节点或其他从节点进行同步,进而会导致数据不一致。

造成影响：

延迟
1. 服务发起了一个写请求，Master写入完成，开始向Slave同步。
2. 服务又发起了一个读请求，此时同步未完成，读到Slave的一个不一致的脏数据
3. 数据库主从同步最后才完成。
宕机

任何数据冗余，必将引发一致性问题。

解决方案 ：

为了避免这种情况的发生,我们可以通过增加从节点的数量,使得从节点的数据保持一致。
当redis集群中某一台节点宕机时,查看是否还有剩余宕机的情况。为了保证数据的一致性,我们需要对redis集群中一台出现的宕机节点进行修复,该节点恢复正常服务。

redis集群数据不一致:为了保证数据的一致性,我们需要采用数据同步机制,确保在主节点宕机或者出现故障时,从节点能够自动切换到备用节点上,保证数据的可用性。

可以通过配置主节点的min-slaves-to-write参数，确保在至少有一定数量的从节点在线时，才执行写操作。

Redis 集群方案

twemproxy，大概概念是，它类似于一个代理方式，使用时在本需要连接 redis 的地方改为连接 twemproxy，它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 redis，将结果再返回 twemproxy。
缺点： twemproxy 自身单端口实例的压力，使用一致性 hash 后，对 redis 节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。
codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在节点数量改变情况下，旧节点数据可恢复到新 hash 节点。
Redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash槽的概念，以及自身支持节点设置从节点，具体看官方文档介绍。

Redis的过期策略以及内存淘汰机制

Redis采用的是定期删除+惰性删除策略。

定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。于是惰性删除派上用场，也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了，如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?