本文写于 9 年前（2017 年 5 月），部分内容可能已经过时。
Redis的Scale out一直是大家关注的，因为它的单进程单线程模型，scale out基本是势在必行。对于读多写少的应用，最简单的方式就是利用Redis的Replication机制，master提供写，slave提供读。但是在 3.21 之前，由于slave所有写操作都来自于master，被动清理的key并不会发送DEL命令到slave，所以会导致一个key在master已经过期了，但是在slave上还能查到。这对于通过read only slave进行redis读扩展来说是一个不可接受的事情。
Redis的作者很早就意识到这个问题了2，而且在3.2之后也对这个问题进行了彻底的修复1。不过随着Redis 3.0集群的出现，redis的scale out有了更多的选择。
Footnotes
本文由 arganzheng 创作，采用 CC BY 4.0 许可协议。在保留原文作者、署名以及完整原文链接（https://arganzheng.life/key-expired-in-redis-slave.html）的前提下，欢迎各种形式的转载、翻译或商业引用。
COMMENTS
评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。