Redis主从

主从同步
主从架构设计的思路大概是：

在多台数据服务器中，只有一台主服务器，而主服务器只负责写入数据，不负责让外部程序读取数据。存在多台从服务器，从服务器不写入数据，只负责同步主服务器的数据，并让外部程序读取数据。
主服务器在写入数据后，即刻将写入数据的命令发送给从服务器，从而使得主从数据同步。应用程序可以随机读取某一台从服务器 的数据， 这样就分摊了读数据的压力。
当从服务器不能工作的时候，整个系统将不受影响： 当主服务器不能工作的时候，可以方便地从从服务器中选举一台来当主服务器 。

　　读数据就可以随机从从服务器上读取，当从服务器是多台的时候，那么单台服务器的压力就大大降低了，这十分有利于系统性能的提高， 当主服务器出现不能工作的情况时，也可以切换为其中的一台从服务器继续让系统稳定运行，所以也有利于系统运行的安全性。当然由于 Redis 自身具备的特点，所以其也有实现主从同步的特殊方式。

主服务器

　　首先，明确主机。当能确定哪台机子是主机的时候，关键的两个配置是 dir和dbfilename 选项， 当然必须保证这两个文件是可写的。

       对于 Redis 的 默认配置而言， dir 的默认值为“.／”，而对于 dbfilename 的默认值为“ dump.rbd ”。换句话说，默认采用 Redis当前目录的 dump.rbd 文件进行同步。

从服务器

　　其次 ， 在明确从机之后，进一步配置所要关注的只有 slaveof这个配置选项，配置格式是 ：

slaveof server port

　　其中 server 代表主机，port代表端口。

　　当从机 Redis 服务重启 时，就会同步对应主机的数据。当不想让从机继续复制主机的数据时，可以在从机的 Redis 命令客户端发送slaveof no one 命令，从机就不会再接收主服务器的数据更新。

　　又或者原来主服务器已经无法工作，而你可能需要去复制新的主机，这个时候执行 slaveof sever port 就能让从机复制另外一台主机的数据。

　　在实际的 Linux 环境中，配置文件 redis.conf 中还有一个 bind 的配置 ， 默认为 127 .0 .0.1，也就是只允许本机访 问 ，把它修改为 bind 0.0.0.0，其他的服务器就能够访 问了 .

Redis主从同步过程

　　

　　

　　无论如何要先保证主服务器的开启，开启主服务器后，从服务器通过命令或重启配置项可以同步到主服务器。
　　当从服务器启动时，读取同步的配置，根据配置决定是否使用当前数据响应客户端，然后发送 SYNC 命令。当主服务器接收到同步命令的时候，就会执行 bgsave 命令备份数据，但是主服务器并不会拒绝客户端的读／写，而是将来自客户端的写命令写入缓冲区 。从服务器未收到主服务器备份的快照文件的时候，会根据其配置决定使用现有数据响应客户端或者拒绝。
　　当 bgsave 命令被主服务器执行完后，开始向从服务器发送备份文件，这个时候从服务器就会丢弃所有现有的数据，开始载入发送的快照文件。
　　当主服务器发送完备份文件后，从服务器就会执行这些写入命令。此时就会把bgsave 执行之后的缓存区内的写命令也发送给从服务器，从服务完成备份文件解析，就开始像往常一样，接收命令，等待命令写入。
　　缓冲区的命令发送完成后，当主服务器执行一条写命令后，就同时往从服务器发送同步写入命令，从服务器就和主服务器保持一致了。而此时当从服务器完成主服务器发送的缓冲区命令后，就开始等待主服务器的命令了。
　　以上 5 步就是 Redis 主从同步的过程。

只是在主服务器同步到从服务器的过程中，需要备份文件，所以在配置的时候一般需要预留 一些内存空间给主服务器，用以腾出空间执行备份命令。 一般来说主服务器使用50%～65%的内存空间 ，以为 主从复制留下可用的内存空间。

缺点
　　主从切换技术的方法是： 当主服务器右机后，需要手动把一台从服务器切换为主从服务器，这就需要人工干预，既费时费力，会造成一段时间内服务不可用

redis复制常见的问题

1、读写分离：

好处：流量可以分摊到不同的从节点上

可能遇到的问题：

①复制数据的延迟：例如从节点发生阻塞，就会到值复制数据的延迟

②读到过期的数据

③从节点也有可能发生故障

2、配置不一致

例如maxmemory不一致，容易丢失数据，或者发生诡异的情况

数据结构优化参数（例如has-max-ziplist-entries）：会出现内存不一致的情况

3、规避全量复制

①第一次全量复制：第一次不可避免，但是我们可以使用小的主节点，或者在半夜低峰的时刻做全量复制

②节点运营的ID不匹配：例如主节点重启，runid就会变化，我们可以使用自动故障转移，例如哨兵或者集群

③复制积压缓冲区不足：网络中断，部分复制功能无法满足，这个时候可以增大复制缓冲区配置rep_backlog_size。

4、规避复制风暴

①单主节点复制风暴：由于主节点从起，多个从节点要复制，会产生复制风暴，解决办法是：更换复制0拓扑

②单机器复制风暴：由于多个主节点都部署在同一个机器上面，机器宕机后需要大量的全量复制，解决办法是：主节点分配到多台机器上面或者使用一些高可用架构，讲从节点晋升为主节点

 

参考：

https://blog.csdn.net/yangshangwei/article/details/82946858