面试官让我手写跳表，而我用两种实现方式吊打了TA！

keys命令需要返回所有的符合给定模式 pattern 的 Redis 中键，为了实现这个目的，Redis 不得不遍历字典中 ht[0]哈希表底层数组，这个时间复杂度为 「O(N)」(N 为 Redis 中 key 所有的数量)。

如果 Redis 中 key 的数量很少，那么这个执行速度还是也会很快。等到 Redis key 的数量慢慢更加，上升到百万、千万、甚至上亿级别，那这个执行速度就会很慢很慢。

下面是阿粉本地做的一次实验，使用 lua 脚本往 Redis 中增加 10W 个 key，然后使用 keys 查询所有键,这个查询大概会阻塞十几秒的时间。

 

于是客户端执行一条命令实际需要四步：

1. 发送命令
2. 命令排队
3. 执行命令
4. 返回结果

由于 Redis 单线程执行命令，只能顺序从队列取出任务开始执行。

只要 3 这个过程执行命令速度过慢，队列其他任务不得不进行等待，这对外部客户端看来，Redis 好像就被阻塞一样，一直得不到响应。

所以使用 Redis 过程切勿执行需要长时间运行的指令，这样可能导致 Redis 阻塞，影响执行其他指令。

KEYS 原理

接下来开始回答第二个问题，为什么Keys 指令查询会这么慢?

回答这个问题之前，请大家回想一下 Redis 底层存储结构。

这里阿粉复制之前文章内容，Redis 底层使用字典这种结构，这个结构与 Java HashMap 底层比较类似。

 

在客户端的视角，执行一条命令分为三步：

• 发送命令
• 执行命令
• 返回结果

但是这仅仅客户端自己以为的过程，但是实际上同一时刻，可能存在很多客户端发送命令给 Redis，而 Redis 我们都知道它采用的是单线程模型。

为了处理同一时刻所有的客户端的请求命令，Redis 内部采用了队列的方式，排队执行。

 

虽然问题成功解决了，但是阿粉心里还是有点不解。

为什么keys 指令会导致其他命令执行变慢?

为什么Keys 指令查询会这么慢?

为什么Scan 指令就没有问题?

Redis 执行命令的原理

首先我们来看第一个问题，为什么keys 指令会导致其他命令执行变慢?

回答这个问题，我们首先看下 Redis 客户端执行一条命令的情况：

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!