1. 如何保证Redis高可用和高并发?
   Redis主从架构，一主多从，可以满足高可用和高并发。出现实例宕机自动进行主备切换，配置读写分离缓解Master读写压力。

2. Redis高可用方案具体怎么实施？
   使用官方推荐的哨兵(sentinel)机制就能实现，当主节点出现故障时，由Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。它有四个主要功能：

   • 集群监控，负责监控redis master和slave进程是否正常工作。
   • 消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
   • 故障转移，如果master node挂掉了，会自动转移到slave node上。
   • 配置中心，如果故障转移发生了，通知client客户端新的master地址。

3. 你能说说Redis哨兵机制的原理吗？
   通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决。每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否活着，如果发现对方在指定时间内未回应，则暂时认为对方宕机。若哨兵群中的多数sentinel都报告某一master没响应，系统才认为该master真正宕机，通过Raft投票算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。

4. 主观下线和客观下线的区别是什么？

   • 主观下线

单个sentinel认为某个服务下线（有可能是接收不到订阅、网络不通等等原因）。sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master、从服务、其他sentinel）发ping命令，通过判断ping回复是有效还是无效回复来判断实例是否在线（对该sentinel来说是“主观在线”）。

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

• 客观下线

当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，如果其他的哨兵也认为主节点主观线下了，则当认为主观下线的票数超过了quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，

5. 部署Redis哨兵要注意哪些问题？
   哨兵至少需要3个实例，来保证自己的健壮性。

6. Redis主从架构数据会丢失吗，为什么？
   有两种数据丢失的情况：

   1. 异步复制导致的数据丢失：因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了。
   2. 脑裂导致的数据丢失：某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master。这个时候，集群里就会有两个master，也就是所谓的脑裂。此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了。因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据。

7. Redis主从复制的工作原理？

   1. 一个Slave实例，无论是第一次连接还是重连到Master，它都会发出一个SYNC命令；
   2. 当Master收到SYNC命令之后，会做两件事：(a) Master执行BGSAVE，即在后台保存数据到磁盘（rdb快照文件）；(b) Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）；
   3. 当Master在后台把数据保存到快照文件完成之后，Master会把这个快照文件传送给Slave，而Slave则把内存清空后，加载该文件到内存中；
   4. 而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步；
   5. Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致；

8. 由于主从延迟导致读取到过期数据怎么处理？

   1. 通过scan命令扫库：当redis中的key被scan的时候，相当于访问了该key，同样也会做过期检测，充分发挥redis惰性删除的策略。这个方法能大大降低了脏数据读取的概率，但缺点也比较明显，会造成一定的数据库压力，否则影响线上业务的效率。
   2. redis加入了一个新特性来解决主从不一致导致读取到过期数据问题，增加了key是否过期以及对主从库的判断，如果key已过期，当前访问的master则返回null；当前访问的是从库，且执行的是只读命令也返回null。

9. Redis Key的过期策略有哪些？

   1. 惰性删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key，很明显，这是被动的。
   2. 定期删除：由于惰性删除策略无法保证冷数据被及时删掉，所以 redis 会定期主动淘汰一批已过期的key。
   3. 主动删除：当前已用内存超过maxMemory限定时，触发主动清理策略。主动设置的前提是设置了maxMemory的值。

参考文章：

https://www.jianshu.com/p/d8ed8de5b1fa
https://my.oschina.net/u/3023401/blog/2208181
https://www.cnblogs.com/leeSmall/p/8398401.html
https://blog.csdn.net/ssllkkyyaa/article/details/84107474
https://www.cnblogs.com/itdragon/p/7932178.html

本文链接：https://www.codingbrick.com/archives/126.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。