现在这世道太卷了，写点博客都有点卖艺的感觉
配置
replicaof 192.168.3.260 6379 # 从本机6379的redis实例复制数据，Redis 5.0之前使用slaveof
replica‐read‐only yes # 配置从节点只读原理
1、master的slave 作为附属 首先这个自觉性必须到位，发送一个psync 给master长官请求复制数据sir（借助的是socker长连接）
2、master长官接收到psync请求后，在后台（那当然是后台了，小附属还能占自己大主线打这些杂七杂八的活），在后台master通过bgsave生成最新的 rdb快照（回旋的镖请注意）：这期间那我的主线任务是不能停的，仍然接受着伟大客户端的请求，so客户端那些修改 的命令呐 存在内存repl buffer中（这么关键的时候多少得占点内存 了repl buffer）
3、bgsave持久化完了之后呢，master会把send rdb文件数据集发送给slave
4、slave呢清空老数据接收加载master的持久化数据，加载到内存
5、然后master再将存在内存中那些修改命令发送给slave ：send buffer，让slave去执行写命令，这样能一定程度上保证一致性
需要注意的是如果多个slave因为各种各样的原因（👻知道什么原因）和master断开了亲子关系，当他们在"认祖归宗"的时候，master可能接收到多个slave并发连接请求，master只会进行一次持久化，毕竟错的不在master ，多份也没必要，省时省力 大家都平安
当然每次都进行全量的持久化那很多情况下是没必要的，所以从2.8开始
断点续传
他来啦，他带着全村的希望走来啦
1、master在内存中创建复制数据的缓存队列，缓存最近的数据，所有人都维护了两个至关重要(甚至一绝生死)的东西，那就是 复制的数据下标offset 和 master的进程id
2、当网络断开，slave请求mater进行未完成的复制使命 **psync(offset)：**从自己记录的下标开始复制，只能是自己记录的，别人家的你又偷不来，没得手脚撒～
3、如果slave的offset在repl backlog buffer 中，master就直接从缓存中将offset之后的数据一次性同步给slave，这样多省事：既然slave觉悟高，没有落后很多那就要褒奖，相反意味着差的很多直接全量同步，这也是为了大家好，万一有多差很多，不全量那就麻烦了
4、如果mster进程id变了，不得了 原来的皇帝没了，那保守起见 直接进行全量数据复制
如果很多个从节点要求从主节点复制数据，那不得了，master要忙不过来的了(复制风暴)，分散压力就让从与从之前同步数据，而不是全部都从主复制，当臣子的主动为皇帝分担也是应该的
上面主要是为了增加趣味性，好学，为什么情感含义，不喜勿喷
主体讲完了，给大家附赠一下lua管道吧
管道
客户端一次性发送多个请求，等所有命令都发送完再一次性读取服务都响应，短短一句话就出现了两个一次性，这网络传输开销降低有多低可想而知
这一切可以归功于管道pipeline，管道执行多条命令的网络开销和执行一次的开销是一样的
注意的是处理完命令前先缓存之前命令的处理结果，所以打包的命令越多，消耗的内存越多，所以一切都需要适合而止
pipeline发送的命令都会被server立即执行，如果执行失败 失败信息会保存起来返回，不影响后面命令的执行