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

2019独角兽企业重金招聘Python工程师标准>>>

问：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或更大，即使是很少的服务节点也能很好的数据分布。

 

转载于:https://my.oschina.net/pentakill/blog/3048899