为了解决Redis的单点故障问题我们可以搭建一个Redis集群将数据备份到集群的其他节点上如果一个节点Redis宕机由其他节点顶上。主从集群搭建Redis的主从集群是一个“一主多从”的读写分离集群。集群种的Master节点负责处理读写请求而Slave节点只能处理读请求。所以要将集群搭建为读写分离模式。主要原因是对于数据库集群写操作压力小压力大多数来自读请求所以一个节点负责写操作即可。下面要搭建的读写分离集群包含一个Master和两个Slave。他们的端口号分别是6380、6381、6382。设置公共配置文件redis.conf在redis安装目录种mkdir一个目录命名为cluster。然后将redis.conf文件复制到cluster目录中。该文件会被其他配置文件包含所以该文件中需要设置每个Redis节点相同的公共的属性。修改这个redis.confmasterauth由于主从集群中每个主机都可能是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.confreplica-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一个子进程让子今年初以异步方式将数据发给slaveslave将数据不断写入到本地持久化文件中。在数据同步过程中master仍在执行客户端的写操作。且不仅将新数据写入到master内存呢同时也写入到同步缓存。当master的持久化文件中的数据发送完毕后master会将同步缓存的数据发送给slave然后slave佳能其写入到本地持久化文件中。数据同步完成。slave恢复内存数据数据同步完成后slave读取持久化文件将其恢复到本地内存然后对外提供服务。持续增量复制之后master会持续不断的将新的数据以增量方式发送给slave以保证主从数据的一致性。数据同步演变过程sync同步Redis2.8之前首次通信成功后slave会向master发送sync数据同步请求。master就会将全部数据发送给slaveslave将数据保存到本地持久化文件内。这个过程称为全量复制。但是有一个问题在全量复制过程中可能会出现过程中断当网络恢复后slave与master重新连接成功此时slave向master又发送同步请求又开始从头全量复制。全量复制过程非常耗时期间网络抖动概率高。从头开始非常耗资源而且可能会出现长时间无法完成全量复制的情况。psync同步Redis2.8版本之后全量复制采用了psyncpartial sync不完全同步同步策略。当全量复制过程出现由于抖动而导致复制过程中断时当重新连接后复制过程可以“断点续传”。从断开位置继续复制不用从头再来。这就提高了性能。为了实现psync系统做了三个变化复制偏移量系统为每个要传送的数据进行了编号编号从0开始每个字节一个编号。此编号称为复制偏移量。参与复制的主从节点都会维护该复制偏移量offset。master每发送一个字节数据就会累计可以通过info replication 命令查看 master_repl_offset 属性。同时slave会定时向master 上报自身已完成的复制偏移量所以master也会保存slave的复制偏移量。slave在接收到master的数据后也会累计接收的偏移量。通过info replication 的slave_repl_offset 查看。主节点复制ID当master启动后会生成一个40位的字符串作为他的复制id。此id是在进行数据同步时slave识别master使用的。通过info replication 的master_replid 属性查看。复制积压缓冲区当master连接slave时在master中会创建并维护一个队列backlog默认1MB该队列称为复制积压缓存区。master接收到写操作数据会先写入master主存写入到master为每个slave配置的发送缓存还会写入到复制挤压缓冲区。作用是保存最近操作的数据以备”断点续传“时做数据补偿防止数据丢失。psync同步过程psync存在的问题数据同步过程中若slave重启slave保存master的id和续传offset都会消失“断点续传”将无法进行从而只能进行全量复制导致资源浪费。数据同步过程中master宕机或slave“易主”导致slave要从新的master进行全量复制造成资源浪费。psync的改进Redis4.0同源增量同步策略解决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操作。说人话就是不写入持久化文件了直接进行数据同步。无盘全量同步master的主进程fork出子进程直接将内存中的数据发给slave不经过磁盘。无盘加载slave接收到master发来的数据后不写入磁盘文件而是直接写入内存这样就能快速完成数据恢复。共享复制积压缓冲区Redis7.0 让所有slave的发送缓冲区共享复制积压缓冲区。这使得复制积压缓冲区的作用除了保障数据安全外还充分利用了复制积压缓冲区。文章转载自E_STOP原文链接https://www.cnblogs.com/alineverstop/p/19985718体验地址http://www.jnpfsoft.com/?from58