1、复制过程
复制过程大致分为6个过程：
流程图如下：
1）保存主节点信息
执行slaveof后从节点只保存主节点的地址信息便直接返回，这时建立复制流程还没有开始，在从节点执行info replication可以看到如下信息：
master_host:xxx
master_port:xxx
master_link_status:down
从统计信息可以看出，主节点的ip和port被保存下来，但是主节点的连接状态master_link_status是下线状态。执行slaveof后Redis会打印如下日志：
SLAVE OF 127.0.0.1: enabled (user request from 'id=65 addr=127.0.0.1:58090
fd= name= age= idle= flags=N db= sub= psub= multi=- qbuf= qbuf-free=
obl= oll= omem= events=r cmd=slaveof')
2）从节点内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。从节点会建立一个socket套接字，专门用于接受主节点发送的复制命令。如连接成功，打印日志如下：
* Connecting to MASTER 127.0.0.1:
* MASTER <-> SLAVE sync started
如果从节点无法建立连接，定时任务会无限重试直到连接成功或执行slaveof no one取消复制。
连接失败，可以在从节点执行info replication查看master_link_down_since_seconds指标，它会记录与主节点连接失败的系统时间。此时日志如下
# Error condition on socket for SYNC: {socket_error_reason}
3） 发送ping命令
连接建立成功后从节点发送ping请求进行首次通信，ping请求主要目的如下：
- 检测主从之间网络套接字是否可用
- 检测主节点当前是否可接受处理命令
如果发送ping命令后，从节点没有收到主节点的pong回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制链接，下次定时任务时任务会重连。
从节点与主节点建立连接流程如图
从节点发送ping命令流程
4）权限验证
如果主节点设置了requirepass参数，则需要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。
5）同步数据集
主从复制链接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分是耗时最长的步骤。Redis在2.8版本以后采用新复制命令psync进行数据同步，原来的sync命令也同样支持，为了新旧版本的兼容性。新同步划分为两种情况：全量同步和部分同步。
6）命令持续复制
当主节点把当前数据同步给从节点或，便完成了复制的建立流程，接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。
2、数据同步
Redis在2.8及以上版本使用psync命令完成主从数据同步，同步过程分为全量复制和部分复制。
全量复制：一般用于初次复制场景，Redis早期支持的复制功能只有全量复制，它会把从节点全部数据一次性发送给从节点，当数据较大时，会对主从节点和网络造成很大的开销。
部分复制：用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的开销。
部分复制是对老版复制的重大优化，有效避免了不必要的全量复制操作。因此当使用复制功能时，尽量采用2.8以上版本的Redis。
psync命令运行需要以下组件支持：
- 主从节点各自复制偏移量
- 主节点复制积压缓冲区
- 主节点运行id
1）复制偏移量
参与复制的主从节点都会维护自身复制偏移量，主节点处理完写入命令后，会把命令的字节长度做累加记录，统计信息在info replication中的master_repl_offset指标中。
从节点每秒上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量。均可以通过info replication查看。
127.0.0.1:> info replication
# Replication
role:master
...
master_repl_offset: ------------------------------------ 127.0.0.1:> info replication
connected_slaves:
slave0:ip=127.0.0.1,port=,state=online,offset=,lag=
从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在info replication中的slave_repl_offset指标中：
127.0.0.1:> info replication
# Replication
role:slave
...
slave_repl_offset:
通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。
提示：可以通过主节点的统计信息，计算出master_repl_offset - slave_offset字节量，判断主从节点复制相差的数据量，根据这个差值判定当前复制的健康度。
2）复制积压缓冲区
复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1MB，当主节点有连接的从节点时被创建，这时主节点响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区。
由于缓冲区本质上是先进先出的定长队列，所以能实现保存最近已复制数据的功能，用于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息也保存在主节点的info replication中：
127.0.0.1:> info replication
# Replication
role:master
...
repl_backlog_active: // 开启复制缓冲区
repl_backlog_size: // 缓冲区最大长度
repl_backlog_first_byte_offset: // 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen: // 已保存数据的有效长度。
3）主节点运行ID
每个Redis节点启动后都会动态分配一个40位的十六进制字符串作为运行ID。运行ID的主要作用是用来唯一识别Redis节点，比如从节点保存主节点的运行ID识别自己正在复制的是哪个主节点。如果只使用ip+port的方式识别主节点，那么主节点重启变更了整体数据集（如替换RDB/AOF），从节点再基于偏移量复制数据将是不安全的，因此当运行ID变化后从节点将做全量复制。可以运行info server命令查看当前节点的运行ID：
127.0.0.1:> info server
# Server
redis_version:3.0.
...
run_id:545f7c76183d0798a327591395b030000ee6def9
需要注意的是Redis关闭再启动后，运行ID会随之改变。Redis不改变ID重启，可以使用redis-cli debug reload
注意：debug reload命令会阻塞当前Redis节点主线程，阻塞期间会生成本地RDB快照并清空数据之后再加载RDB文件，因此对于大数据量的节点和无法容忍阻塞的应用场景，谨慎使用。
4）psync命令
从节点使用psync命令完成部分复制和全量复制功能，命令格式：psync {runid} {offset}
- runid：从节点所复制主节点的运行id
- offset：当前从节点已复制的数据偏移量
psync运行流程
流程说明：
1）从节点发送psync命令给主节点，参数runid是当前从节点保存的主节点运行ID，参数offset是当前从节点保存的复制偏移量，如果是第一次复制则为-1。
2）主节点根据psync参数和自身数据情况决定响应结果：
- 如果回复 FULLRESYNC {runid} {offset}，那么从节点触发全量复制
- 如果回复CONTINUE，从节点将触发部分复制流程
- 如果回复ERR，说明主节点版本低于2.8，无法识别psync命令，从节点将发送旧版的sync命令触发全量复制流程。
3、全量复制
全量复制是Redis最早支持的复制方式，也是主从第一次建立复制时必须经历的阶段。触发全量复制的命令是sync和psync。
全量复制流程：
流程说明：
1）发送psync命令进行数据同步，由于是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，所有发送psync-1
2）主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应。
3）从节点接收主节点的响应数据保存运行ID和偏移量offset，执行到当前步骤时从节点打印如下日志：
Partial resynchronization not possible (no cached master)
Full resync from master: 92d1cb14ff7ba97816216f7beb839efe036775b2:
4）主节点执行bgsave保存RDB文件到本地，主节点bgsave相关日志如下：
M * Full resync requested by slave 127.0.0.1:
M * Starting BGSAVE for SYNC with target: disk
C * Background saving started by pid
C * RDB: MB of memory used by copy-on-write
M * Background saving terminated with success
提示：Redis 3.0之后在输出的日志开头会有MSC等标识，对应的含义是：M=当前为主节点日志，S=当前为从节点日志，C=子进程日志。
save和bgsave的区别：save直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave 在子进程被调用，所以 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。
5）主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件，接收完RDB后从节点可以在日志中查看主节点发送的数据量：
::03.057 * MASTER <-> SLAVE sync: receiving bytes from master
注意：对于数据量大的主节点，比如生成的RDB文件超过6GB以上传输文件这一步操作非常耗时，速度取决于主从节点之间的网络带宽，针对数据量较大的节点，建议调大repl-timeout参数防止出现全量同步数据超时。
关于无盘复制：为了降低主节点的磁盘开销，Redis支持无盘复制，生成的RDB文件不保存到硬盘而是直接通过网络发送给从节点，通过repl-diskless-sync参数控制，默认关闭。无盘复制适用于主节点所在机器磁盘性能较差但网络带宽较充裕的场景。注意无盘复制目前依然处于试验阶段。
6）对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。默认配置为client-output-buffer-limit slave 256MB 64MB 60.如果60秒内缓冲区消耗持续大于64MB或者直接超过356MB时，主节点将直接关闭复制客户端连接，造成全量同步失败，日志如下：
M May ::33.669 # Client id= addr=127.0.0.1: age= idle= flags=S
qbuf= qbuf-free= obl= oll= omem= events=r cmd=psync
scheduled to be closed ASAP for overcoming of output buffer limits.
因此需要根据主节点数据量和写命令并发量调整client-output-buffer-limit slave配置，避免全量复制期间客户端缓冲区溢出。
7）从节点接收完主节点传送来的全部数据后清空自身旧数据，该步骤对应如下日志：
::02.234 * MASTER <-> SLAVE sync: Flushing old data
8）从节点清空数据后开始加载RDB文件，对于较大的RDB依然耗时。对于读写分离的场景，可以设置slave-serve-stale-data参数为no，关闭命令执行，在完成同步前不响应读命令。
9）从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，它会立刻做bgrewriteaof操作，为了保证全量复制后AOF持久化文件立刻可用。
RDB和AOF区别：RDB是将Redis某一时刻的数据持久化到磁盘上，类似于快照；AOF是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复，默认每秒钟fsync一次。
4、部分复制
部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync {runid} {offset}命令实现，当从节点正在复制主节点时，如果出现异常情况，从节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点，这样就可以保持主从节点复制的一致性。
部分复制过程：
流程说明：
1）当主从节点之间网络出现中断时，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制链接。
2）主从连接中断期间主节点依然响应命令，写命令保存在复制积压缓冲区，默认最大缓存1MB。
3）当主从节点网络恢复后，从节点会再次连接主节点。
4）连接恢复后，由于从节点保存了自身已复制的偏移量和主节点的运行ID，因此会把他们当做psync参数发送给主节点，要求进行部分复制操作。
5）主节点接收到psync命令后首先核对参数runid，如果一致，说明之前复制的是当前主节点，之后根据参数offset在自身复制积压缓冲区查找，找到发送+CONTINUE响应。
6）主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。
5、哨兵模式
Redis Sentinel通过三个定时监控任务完成对各个节点的发现和控制：
1）每隔10秒，每个sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。通过解析info replication可以找到相应的从节点。此定时任务作用于三个方面：
- 通过向主节点执行info命令，获取从节点的信息。
- 当有新的节点加入时，可以立刻感知出来。
- 节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息。
2）每隔2秒，每隔sentinel节点会向Redis数据节点的__sentinel__:hello频道上发送该sentinel节点对于主节点的判断以及当前sentinel节点的信息，同时每隔sentinel节点也会订阅该频道，来了解其他sentinel节点以及他们对主节点的判断，因此此任务主要作用如下：
- 发现新的sentinel节点
- sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。
3）每隔1秒，每隔sentinel节点会向主节点、从节点、其他sentinel节点发送一条ping命令做一次心跳检测。
6、Redis集群
6.1 数据分布
Redis Cluster把数据集划分到多个节点，每个节点负责整体数据的一个子集。Redis Cluster槽范围是0~16383，槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展，每个节点会负责一定数量的槽。
6.2 集群功能限制
1）key批量操作支持有限。如mset、mget，目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key不被支持。
2）key事务操作支持有限。同理只支持多key在同一节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。
3）key作为数据分区的最小粒度，因此不能将一个大的键值对象如hash、list等映射到不同的节点。
4）不支持多数据空间。单机支持16个数据库，集群只有db0。
5）复制结构只支持一层。