Redis主从集群
主从集群搭建
Redis的主从集群是一个“一主多从”的读写分离集群。集群种的Master节点负责处理读写请求，而Slave节点只能处理读请求。所以要将集群搭建为读写分离模式。
主要原因是，对于数据库集群，写操作压力小，压力大多数来自读请求，所以，一个节点负责写操作即可。
下面要搭建的读写分离集群包含一个Master和两个Slave。他们的端口号分别是6380、6381、6382。
- 设置公共配置文件redis.conf
在redis安装目录种mkdir一个目录，命名为cluster。然后将redis.conf文件复制到cluster目录中。该文件会被其他配置文件包含，所以该文件中需要设置每个Redis节点相同的公共的属性。
修改这个redis.conf
masterauth
由于主从集群中每个主机都可能是Master，所以最好不要设置密码验证属性requirepass。
如果要设置，一定要每个主机的密码都相同。
此时每个配置文件中都要设置两个完全相同的属性：requirepass和masterauth。
requirepass：指定当前主机的访问密码。
masterauth：指定当前Slave访问master时提供的访问密码，用来验证slave的身份。
repl-disable-tcp-nodelay
该属性用于设置是否禁用TCP特性tcp-nodelay。
设置yes则禁用，表示关闭TCP_NODELAY，启用Nagle算法，此时master与slave间通信延迟增大，使用TCP包数量会较少，占用网络带宽小。
设置no，表示开启 TCP_NODELAY，网络延迟变小，使用TCP小包数量会较多，实时性高，占用网络带宽大。
tcp-nodelay：为了充分利用网络带宽，TCP总是希望发送尽可能大的数据库。为了达到该目的，TCP使用了一个名为Nagle算法。 Nagle算法的工作原理：网络在接收到数据后，并不直接发送，而是等待数据量足够大时再一次性发送出去。这样网络上传输的有效数据比例就得到了大大提升，无效数据传递极大减少，节省网络带宽，缓解网络压力。新建redis6380.conf、redis6381.conf、redis6382.conf
replica-priority :给slave节点设置权重优先级，数值越小，越优先被选举为主节点，0表示不参与选举。
启动三台Redis
分别使用redis6380.conf、redis6381.conf与redis6382.conf三个配置文件启动三台Redis。
redis-server redis6380.conf redis-server redis6381.conf redis-server redis6382.conf 设置主从关系：
分别使用客户端连接三台Redis，然后通过slaveof命令，指定6380的Redis为Master。
注意：slaveof命令在Redis重启之后主从关系会失效！！！
查看状态信息：
通过info replication 命令查看当前连接的Redis的状态信息。
分级管理
如果Redis集群中的slave较多，数据同步会对Master形成较大的压力。此时可以对slave分级管理。
设置方法：让低级别的slave指定其slaveof的主机为上一级slave即可，不过上一级slave的角色仍是slave。
容灾冷处理
在Redis集群中，如果Master出现宕机怎么办？
有两种处理方式：
- 手工角色调整，使Slave晋升为Master的冷处理。
- 使用哨兵模式，实现Redis集群的高可用HA，即热处理。
无论Master上是否宕机，slave都可使用slaveof no one 将自己晋升为master。
如果其原本就有下一级的slave，那么就直接变成这些slave的master了。
而原来master会时区这个新晋的slave。
主从复制原理
主从复制过程
保存master地址：slave接收到slaveof指令后，slave会立即将心的master地址保存下来。
建立连接：slave定时与master建立socket连接。如果无法建立，则会不断重试，直到连接成功或接收到slaveof no one 指令。
slave发送ping命令：建立连接后，slave会发送ping命令进行首次通信。如果slave没有收到master的回复，则slave会主动断开连接，下次的定时任务会尝试重连。
对slave身份验证：master收到slave的ping命令后，不会立即对其回复，而是先进行身份验证。如果验证失败，则发消息拒绝连接，如果验证成功，则发送给slave连接成功消息。
master持久化：首次通信成功后，slave会向master发送数据同步请求，当master接收到请求后，会fork一个子进程，让子进程以异步方式立即进行持久化。
数据发送：持久化完毕后，master再fork一个子进程，让子今年初以异步方式将数据发给slave，slave将数据不断写入到本地持久化文件中。
在数据同步过程中，master仍在执行客户端的写操作。且不仅将新数据写入到master内存呢，同时也写入到同步缓存。当master的持久化文件中的数据发送完毕后，master会将同步缓存的数据发送给slave，然后slave佳能其写入到本地持久化文件中。数据同步完成。
slave恢复内存数据：数据同步完成后，slave读取持久化文件，将其恢复到本地内存，然后对外提供服务。
持续增量复制：之后，master会持续不断的将新的数据以增量方式发送给slave，以保证主从数据的一致性。
数据同步演变过程
sync同步
Redis2.8之前，首次通信成功后，slave会向master发送sync数据同步请求。
master就会将全部数据发送给slave，slave将数据保存到本地持久化文件内。这个过程称为全量复制。
但是有一个问题：在全量复制过程中可能会出现过程中断，当网络恢复后，slave与master重新连接成功，此时slave向master又发送同步请求，又开始从头全量复制。
全量复制过程非常耗时，期间网络抖动概率高。从头开始非常耗资源，而且可能会出现长时间无法完成全量复制的情况。
psync同步
Redis2.8版本之后，全量复制采用了psync（partial sync，不完全同步）同步策略。
当全量复制过程出现由于抖动而导致复制过程中断时，当重新连接后，复制过程可以“断点续传”。从断开位置继续复制，不用从头再来。这就提高了性能。
为了实现psync，系统做了三个变化：
- 复制偏移量
系统为每个要传送的数据进行了编号，编号从0开始，每个字节一个编号。此编号称为复制偏移量。参与复制的主从节点都会维护该复制偏移量offset。
master每发送一个字节数据就会累计，可以通过info replication 命令查看 master_repl_offset 属性。
同时，slave会定时向master 上报自身已完成的复制偏移量，所以master也会保存slave的复制偏移量。