「这是我参与11月更文挑战的第16天，活动详情查看：2021最后一次更文挑战」。
上文中我们已经对 redis 的主从同步的配置文件和原理问题进行了探讨，本文将回答两个工作中经常被问到的问题，供大家赏析。
在主从复制过程中，关闭 master 的持久化会引发什么问题呢？
数据会从 master 和所有 replica 中被删除。我们用案例来说明一下：
- 我们设置节点 A 为 master 并关闭它的持久化设置，设置节点 B 和 C 为 replica；
- 当 master 崩溃时，由于系统中配置了自动重启的脚本，此时 master 会自动重启。但是由于持久化被关闭了，master 重启后其数据集合为空；
- 此时，如果 replica 从 master 中同步数据，就会导致 replica 中的数据也会变为空集合。
因此，我们在使用 Redis 复制功能时，强烈建议在 master 和 replica 中启用持久化。如果因为非常慢的磁盘性能导致的延迟问题而不启用持久化时，应该配置节点来避免重置后自动重启。
Redis 复制如何处理 key 的过期问题
Redis 的过期机制可以限制 key 的生存时间，该机制取决于 Redis 计算时间的能力。但是，即使使用 Lua 脚本将这些 key 变为过期的 key，Redis replicas 也能正确地复制这些 key。
为了实现这样的功能，Redis 不能依靠主从使用同步时钟，因为这是一个无法解决的并且会导致 race condition 和数据集不一致的问题，所以 Redis 使用三种主要的技术使过期的 key 的复制能够正确工作：
- replica 不会让 key 过期，而是等待 master 让 key 过期。当一个 master 让一个 key 到期（或由于 LRU 算法将之驱逐）时，它会合成一个 DEL 命令并传输到所有的 replica；
- 由于主驱动的原因，master 无法及时提供 DEL 命令，所以有时候 replica 的内存中仍然可能存在逻辑上已经过期的 key。为了处理这个问题，replica 使用它的逻辑时钟来报告在不违反数据一致性的前提下，读取操作的 key 不存在。用这种方法，replica 避免报告逻辑过期的 key 仍然存在。在实际应用中，使用 replica 程序进行扩展的 HTML 碎片缓存，将避免返回已经比期望的时间更早的数据项。
- 在Lua脚本执行期间，不执行任何 key 过期操作。当一个Lua脚本运行时，从概念上讲，master 中的时间是被冻结的，这样脚本运行的时候，一个给定的键要么存在要么不存在。这可以防止 key 在脚本中间过期，保证将相同的脚本发送到 replica ，从而在二者的数据集中产生相同的效果。
一旦一个 replica 被提升为一个 master ，它将开始独立地过期 key，而不需要任何旧 master 的帮助。
以上就是今天的全部内容了，如果你有不同的意见或者更好的idea，欢迎联系阿Q，添加阿Q可以加入技术交流群参与讨论呦！