《Redis 核心技术与实战》学习笔记 04

学习极客时间《Redis 核心技术与实战》专栏过程中的一些学习笔记，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自《Redis 核心技术与实战》专栏

06 | 数据同步：主从库如何实现数据一致？

从主从模式到“主-从-从”级联模式，验证了那句计算机领域的名言，没有什么问题是不能通过增加一个中间层解决的。

对于课后题，我觉的在主从复制的过程中，不使用 AOF 主要是考虑 AOF 记录中变化量会比较多，而且重复。

看完专栏正文之后，还看了不少留言，果然是高手多多、火花四溢。

07 | 哨兵机制：主库挂了，如何不间断服务？

Redis 的哨兵机制应该在其他的分布式系统中也有使用，不知道有多少异同。

先回答课后题，如果主库挂了，那么客户端如果恰好连接的是主库，那么读、写操作应该是都无法进行的，其中读操作应该可以重定向到从库；如果连接的是从库，并且是读操作，那么应该没有影响。

如果想要应用程序感知服务的中断，特别是写服务，那么在客户端（smart？）或者是代理 proxy 上，也得有一个缓存机制，短时间存储写命令，并且在 Redis 服务选主结束之后，将写命令同步过去，这中间可能有一段时间是不一致的。

08 | 哨兵集群：哨兵挂了，主从库还能切换吗？

哨兵是一个运行在特定模式下的 Redis 实例，不服务请求操作，只完成监控、选主和通知的任务。

如果哨兵集群只有 2 个实例，那么一个哨兵想要成为 Leader，就必须获得两票，那么这个时候，就很容易平分（死锁）。

有一个疑问，哨兵是单独部署还是和 Redis 的节点部署在一起？我觉得可能是部署在一起的。

对于课后题，因为没有实战经验，只能当做思考练习来做。

我觉的在“一主四从” + 5 个哨兵实例的集群，如果 3 个哨兵实例故障，而 quorum 的值是 2，似乎能够判断出主库“客观下线”，但是在选主的时候，有可能会遇到问题。

哨兵似乎并不是越多越好，最好是单数，但是多了之后也容易起冲突。

如果调大 down-after-milliseconds 的值，那么可能在主库“客观下线”之后很长一段时间没有办法确认，影响主从切换，进而影响业务。