为了解决Redis的单点故障问题，我们可以搭建一个Redis集群，将数据备份到集群的其他节点上，如果一个节点Redis宕机，由其他节点顶上。
Redis的主从集群是一个“一主多从”的读写分离集群。集群种的Master节点负责处理读写请求，而Slave节点只能处理读请求。所以要将集群搭建为读写分离模式。
主要原因是，对于数据库集群，写操作压力小，压力大多数来自读请求，所以，一个节点负责写操作即可。
下面要搭建的读写分离集群包含一个Master和两个Slave。他们的端口号分别是6380、6381、6382。
在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出现宕机怎么办？
有两种处理方式：
无论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，以保证主从数据的一致性。
Redis2.8之前，首次通信成功后，slave会向master发送sync数据同步请求。
master就会将全部数据发送给slave，slave将数据保存到本地持久化文件内。这个过程称为全量复制。
但是有一个问题：在全量复制过程中可能会出现过程中断，当网络恢复后，slave与master重新连接成功，此时slave向master又发送同步请求，又开始从头全量复制。
全量复制过程非常耗时，期间网络抖动概率高。从头开始非常耗资源，而且可能会出现长时间无法完成全量复制的情况。
Redis2.8版本之后，全量复制采用了psync（partial sync，不完全同步）同步策略。
当全量复制过程出现由于抖动而导致复制过程中断时，当重新连接后，复制过程可以“断点续传”。从断开位置继续复制，不用从头再来。这就提高了性能。
为了实现psync，系统做了三个变化：
系统为每个要传送的数据进行了编号，编号从0开始，每个字节一个编号。此编号称为复制偏移量。参与复制的主从节点都会维护该复制偏移量offset。
master每发送一个字节数据就会累计，可以通过info replication 命令查看 master_repl_offset 属性。
同时，slave会定时向master 上报自身已完成的复制偏移量，所以master也会保存slave的复制偏移量。
slave在接收到master的数据后，也会累计接收的偏移量。通过info replication 的slave_repl_offset 查看。
当master启动后，会生成一个40位的字符串作为他的复制id。此id是在进行数据同步时slave识别master使用的。
通过info replication 的master_replid 属性查看。
当master连接slave时，在master中会创建并维护一个队列backlog，默认1MB，该队列称为复制积压缓存区。
master接收到写操作数据，会先写入master主存，写入到master为每个slave配置的发送缓存，还会写入到复制挤压缓冲区。作用是保存最近操作的数据，以备”断点续传“时做数据补偿，防止数据丢失。
解决slave重启问题
针对“salve重启后master的id丢失问题”，psync将maste的rid直接写入到slave的持久化文件。
slave重启后从本地文件获取master的id，然后向master提交获取复制偏移量的请求。
master根据复制偏移量开始向slave进行“断点续传”。
解决slave易主问题
这个问题的本质是新的master的id和slave提交的psync的原master的id不一致。如果新master能够识别出slave发送给master的psync请求，那么就应该进行“断点续传”。
新master中恰好保存了原master的id。所以当slave晋升为新master后，接收到了给原master发送的同步请求，新master也能进行处理。
Redis6.0 提出了“无盘全量同步”和“无盘加载”策略，避免了耗时io操作。（说人话就是不写入持久化文件了，直接进行数据同步）。
Redis7.0 让所有slave的发送缓冲区共享复制积压缓冲区。这使得复制积压缓冲区的作用除了保障数据安全外，还充分利用了复制积压缓冲区。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。