Redis 面试知识点笔记（七）pipeline及主从同步、集群

问：redis的pipeline有什么好处？

前面作测试数据的时候用到 cat /tmp/redisTest.txt | /redis-5.0/src/redis-cli -h 127.0.0.1 -p 6379 --pipe

就是一个pipeline管道批量执行指令，能够节省屡次IO往返的时间，可是若是指令间有依赖建议分批发送

问：redis的同步机制？

主从同步原理，通常集群都是一个主多个从，主负责写，从负责读。开始主节点会启动命令开始全量同步，而后会启动增量同步。

全同步过程：

1. Slave发送sync命令到Master
2. Master启动一个后台进程，将Redis中的数据快照保存到文件中（bgsave）
3. Master将保存的数据快照期间接收到的写命令也缓存起来（增量数据缓存）
4. Master完成写操做以后，将该文件发送给Slave
5. 使用新的AOF文件替换掉旧的AOF文件，而后写入内存中，恢复数据快照
6. Master将这期间收集的增量写命令也发送给Slave，Slave完成同步

增量同步过程：

1. Master接收到用户的操做指令，判断是否须要传播到Slave
2. 将操做记录追加到AOF文件
3. 将该操做传播到其余Slave ,对齐住从库，往响应的缓存写入指令
4. 将缓存中的数据发送给Slave

主从的弊端就是主服务器挂掉以后就不能进行写操做了，因此就有了sentinel 哨兵

解决主从同步Master宕机后的主从切换问题：

• 监控：检查主从服务器是否运行正常
• 提醒：经过API向管理员或者其余应用程序发送故障通知
• 自动故障迁移：主从切换

流言协议Gossip，在杂乱无章中寻求一致（区块链中有用到）：

• 每一个节点都随机地与对方通讯，最终全部节点的状态达成一致
• 种子节点按期随机向其余节点发送节点列表以及传播的消息
• 不保证信息必定会传播给全部节点，可是最终会趋于一致

 

Redis的集群原理

问：如何从海量数据里快速找到所需？

• 分片：按照某种规则去划分数据，分散存储在多个节点上
• 常规的按照哈希（按哈希值取模）划分没法实现节点的动态增减（当动态增长或减小节点的时候会致使大量的key没法命中）

一致性哈希算法（哈希环）：对2^32次方取模，将哈希值的空间组织成虚拟圆环

当NodeC宕机了(在一致性哈希算法中，若是一台服务器不能够，其影响的只是此服务器到哈希环的前一台服务器（逆时针方向上的第一台）之间的数据，其余数据不受影响，新增的数据也会到下一个节点，顺时针的下一台)

新增服务器NodeX （新增一台服务器，受影响的只是新服务器到其环的前一台服务器，逆时针第一台之间的数据）

Hash环数据倾斜问题（大部分数据缓存到一个服务器上，分配不均匀）

一致性哈希又引入了虚拟节点解决数据倾斜的问题（一个节点计算多个hash值，结算结果位置放置一个虚拟节点，具体作法能够在节点后面增长编号来实现）

在实际应用中把虚拟节点设置成32或更大，即便是不多的服务节点也能很好的数据分布。