因为不会Redis的scan命令,我被开除了
那个深夜,我登上了公司的服务器,在Redis 命令行里敲入 keys* 后,线上开始报警,服务瞬间被卡死,我只能举起双手,焦急地等待几千万key被慢慢扫描,束手无策万念俱灰的时候,我收到了leader的短信:你明天不用来上班了。 虽然上面是我的臆想,事实上很多公司的运维也会禁用这些命令,来防止开发出错。但我在群里依然看到有同学在问“为什么Redis不能用 keys?我觉得挺好的呀”时,为了不让上面的情况发生,我决定写下这篇文章。 如何才能优雅地遍历Redis?作为一种可以称为数据库的组件,这是多么理所因当的要求。终于,Redis在2.8.0版本新增了众望所归的 scan操作,从此再也不用担心敲入了keys*, 然后等着定时炸弹的引爆。 学会使用 scan并不困难,那么问题又来了,它是如何遍历的?当遍历过程中加入了新的key,当遍历过程中发生了扩容,Redis是如何解决的?抱着深入学习的态度,以及为了能够将来在面试官面前谈笑风生,让我们一起来借此探索Redis的设计原理。 引言 开门见山,首先让我们来总结一下 scan的优缺点。 优点: 提供键空间的遍历操作,支持游标,复杂度O(1), 整体遍历一遍只需要O(N) 提供结果模式匹配 支持一次返回的数据条数设置,但仅仅是个hints,有时候返回更多 弱状态,所有状态只需要客户端需要维护一个游标 缺点: 无法提供完整的快照遍历