主从复制的方式
- 命令slaveof。
优点：无需重启。缺点：不便于管理
// 命令行使用
slaveof ip port // 使用命令后自身数据会被清空，但取消slave只是停止复制，并不清空
- 修改配置。
优点：统一配置。缺点：需要重启
// 配置文件中配置
slaveof ip port
slave-read-only yes //只允许从节点进行读操作
全量复制
用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作，当数据量较大时，会对主从节点和网络造成很大的开销
Redis全量复制过程
全量复制过程：
- Redis内部会发出一个同步命令，刚开始是Psync命令，Psync ? -1表示要求master主机同步数据
- 主机会向从机发送run_id和offset，因为slave并没有对应的 offset，所以是全量复制
- 从机slave会保存主机master的基本信息
- 主节点收到全量复制的命令后，执行bgsave（异步执行），在后台生成RDB文件（快照），并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令
- 主机发送RDB文件给从机
- 发送缓冲区数据
- 刷新旧的数据。从节点在载入主节点的数据之前要先将老数据清除
- 加载RDB文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。
全量复制开销
- 主节点需要bgsave
- RDB文件网络传输占用网络io
- 从节点要清空数据
- 从节点加载RDB
- 全量复制会触发从节点AOF重写
部分复制
部分复制是Redis 2.8以后出现的，用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销，需要注意的是，如果网络中断时间过长，造成主节点没有能够完整地保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制
Redis部分复制过程
部分复制过程：
- 如果网络抖动（连接断开 connection lost）
- 主机master 还是会写 repl_back_buffer（复制缓冲区）
- 从机slave 会继续尝试连接主机
- 从机slave 会把自己当前 run_id 和偏移量传输给主机 master，并且执行 pysnc 命令同步
- 如果master发现你的偏移量是在缓冲区的范围内，就会返回 continue命令
- 同步了offset的部分数据，所以部分复制的基础就是偏移量 offset。
服务器运行ID(run_id)：每个Redis节点(无论主从)，在启动时都会自动生成一个随机ID(每次启动都不一样)，由40个随机的十六进制字符组成；run_id用来唯一识别一个Redis节点。 通过info server命令，可以查看节点的run_id。
Redis大概主从同步是怎么实现的？
全量同步：
master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件，与此同时，服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程
处理完毕后，会将该rdb文件传递给slave服务器，而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后master服务器会将在此期间缓存的
命令通过redis传输协议发送给slave服务器，然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。
部分同步：
从redis 2.8版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master服务器和slave服务器之间都是进行全量数据同步，但是从redis 2.8开
始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了
一份同步日志和同步标识，每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave服务器隔断时间
（默认1s）主动尝试和master服务器进行连接，如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中，那么就从slave发送的偏移量开始继续上次的同步
操作，如果slave发送的偏移量已经不再master的同步备份日志中（可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作），则
必须进行一次全量更新。在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。
无磁盘复制
1 2 3 4 |
|