主从复制
redis 主从复制的核心原理
当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。
如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，
同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，
接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。
slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据
过程原理
- 当从库和主库建立MS关系后，会向主数据库发送SYNC命令
- 主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存起来
- 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis
- 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令
- 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致
docker下redis集群搭建
修改redis的配置文件：
cluster-enabled yes
如果是单台机器。修改每个redis服务的端口号。
启动每个机器。
执行命令：加入各个节点，注意替换自己的ip地址
redis-cli --cluster create 10.5.0.3:6391 10.5.0.3:6392 10.5.0.3:6393 10.5.0.3:6394 10.5.0.3:6395 10.5.0.3:6396 --cluster-replicas 1连接测试： redis-cli -c -h 172.30.0.4 -p 6396 （-c 会在set和get的时候自动寻找对应的节点存储）
执行 cluster nodes 查看节点信息。
Redis哈希槽
一个 redis 集群包含2^14（16384）个哈希槽（hash slot），数据库中的每个数据都属于这16384个哈希槽中的一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。集群中的每一个节点负责处理一部分哈希槽。
所有的master节点都会有一个槽区比如0～1000，槽数是可以迁移的。master节点的slave节点不分配槽，只拥有读权限。但是注意在代码中redis cluster执行读写操作的都是master节点，并不是你想 的读是从节点，写是主节点。第一次新建redis cluster时，16384个槽是被master节点均匀分布的。
为什么是16384（2^14）个？
在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用bitmap压缩后是2k（2 * 8 (8 bit) * 1024(1k) = 2K），也就是说使用2k的空间创建了16k的槽数。
虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) = 8K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。
