redis 主从复制和数据丢失
从节点启动时复制的完整流程
- slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始，master host和ip是从哪儿来的，redis.conf里面的slaveof配置的
- slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接
- slave node发送ping命令给master node
- 口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
- master node第一次执行全量复制，将所有数据发给slave node
- master node后续持续将写命令，异步复制给slave node
数据同步相关的核心机制
第一次slave连接msater的时候，执行的全量复制：
offset
- master和slave都会维护一个offset，master会在自身不断累加offset，slave也会在自身不断累加offset，slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset
- 这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况
backlog
- Backlog是一个固定大小的环形缓冲区，用于存储主服务器接收到的写命令，默认是1MB大小
- 当从服务器与主服务器断开连接时，从服务器会尝试重新连接。在重新连接过程中，从服务器会向主服务器请求丢失的写命令。backlog用于存储这些写命令，确保从服务器可以恢复数据一致性，避免全量同步的开销，offset就是保存在backlog中的
master run id
info server，可以看到master run id
如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化（master节点重新加载旧的RDB文件），那么slave node应该根据不同的run id区分，run id不同就做全量复制，如果需要不更改run id重启redis，可以使用redis-cli debug reload命令
psync
从节点使用psync从master node进行复制，psync runid offset， master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复制
全量复制过程
- master执行bgsave，在本地生成一份rdb快照文件
- master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数，对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
- master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node， client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
- slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
- 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
其中，rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间
增量复制过程
- 如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
- master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
- msater就是根据slave发送的psync中的offset来从backlog中获取数据的
无磁盘化复制
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了
repl-diskless-sync
该参数默认值为no，也即从节点请求全量复制的时候，主节点上不开启无盘复制，先通过bgsave做持久化，然后传输RDB文件到从节点。
全量同步的可以通过两种方式进行：
基于磁盘的复制： Redis主节点会创建一个新的进程，在磁盘上写入RDB文件。之后，父进程会逐步将文件传输给副本。
无磁盘复制： Redis主节点创建的新进程会直接将RDB文件写入副本的套接字，完全不涉及磁盘操作。
在使用基于磁盘的复制时，当RDB文件正在生成时，其他的副本可以排队，并能在当前子进程完成RDB文件生成后立刻使用这个文件。
repl-diskless-sync-delay
默认值为5，单位为秒，该参数只有开启了repl-diskless-sync 为yes的时候才会生效
- 在使用无磁盘复制时，一旦传输开始，新到达的副本会被排队，直到当前传输结束，新的传输才会开始。
- 当使用无磁盘复制时，主节点会等待一个时间段repl-diskless-sync-delay（以秒为单位）再开始传输，这样做的目的是希望多个副本能够在这段时间内到达，从而使传输过程可以并行化。
过期key处理
slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。
两种数据丢失的情况
异步复制导致的数据丢失
因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了
脑裂导致的数据丢失
脑裂，也就是说，某个master所在机器突然脱离了正常的网络（出现网络分区），跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
数据丢失问题减少
减少异步复制的数据丢失
min-slaves-max-lag 10 表示一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内。
减少脑裂的数据丢失
min-slaves-max-lag 10 和 min-slaves-to-write 1 表示要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。
这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失，上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求。因此在脑裂场景下，最多就丢失10秒的数据。
