经典面试题【Redis】

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接： https://blog.csdn.net/qq_40012791/article/details/95453681

（一）如何访问 Redis 中的海量数据，服务才不会挂掉？

1、事故产生
因为我们的用户token缓存是采用了【user_token:userid】格式的key，保存用户的token的值。我们运维为了帮助开发小伙伴们查一下线上现在有多少登录用户。直接操作上线 redis，执行 keys * wxdb（此处省略）cf8* 这样的命令，导致redis锁住，导致 CPU 飙升，引起所有支付链路卡住，等十几秒结束后，所有的请求流量全部挤压到了 rds 数据库中，使数据库产生了雪崩效应，发生了数据库宕机事件。

我们线上的登录用户有几百万，数据量比较多；keys算法是遍历算法，复杂度是O(n)，也就是数据越多，时间越高。数据量达到几百万，keys这个指令就会导致 Redis 服务卡顿，因为 Redis 是单线程程序，顺序执行所有指令，其它指令必须等到当前的 keys 指令执行完了才可以继续。

2、哪些危险命令
keys：客户端可查询出所有存在的键。
flushdb：删除 Redis 中当前所在数据库中的所有记录，并且此命令从不会执行失败。
flushall：删除 Redis 中所有数据库中的所有记录，不只是当前所在数据库，并且此命令从不会执行失败。
config：客户端可修改 Redis 配置。

3、禁用或重命名危险命令
看下 redis.conf 默认配置文件，找到 SECURITY 区域，如以下所示。

看说明，添加 rename-command 配置即可达到安全目的。

1）禁用命令

rename-command KEYS     ""
rename-command FLUSHALL ""
rename-command FLUSHDB  ""
rename-command CONFIG   ""

2）重命名命令

rename-command KEYS     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
rename-command FLUSHALL "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
rename-command FLUSHDB  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
rename-command CONFIG   "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

上面的 XX 可以定义新命令名称，或者用随机字符代替。经过以上的设置之后，危险命令就不会被客户端执行了。

4、解决方案

（1）、我们可以采用Redis的另一个命令scan。

我们看一下scan的特点：

• 复杂度虽然也是 O(n)，但是它是通过游标分步进行的，不会阻塞线程

• 提供 count 参数，不是结果数量，是Redis单次遍历字典槽位数量(约等于)

• 同 keys 一样，它也提供模式匹配功能;

• 服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数;

• 返回的结果可能会有重复，需要客户端去重复，这点非常重要;

• 单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零

 scan命令格式 

 命令解释 

scan 游标 MATCH <返回和给定模式相匹配的元素> count 每次迭代所返回的元素数量。

• SCAN命令是增量的循环，每次调用只会返回一小部分的元素。所以不会让Redis假死；

• SCAN命令返回的是一个游标，从0开始遍历，到0结束遍历；

 举例 

从0开始遍历，返回了游标6，又返回了数据，继续scan遍历，就要从6开始；

（2）、使用有序集合

每当一个用户上线时， 我们就执行 ZADD 命令， 将这个用户以及它的在线时间添加到指定的有序集合中：

ZADD "online_users" <user_id> <current_timestamp>

通过使用 ZSCORE 命令检查指定的用户 ID 在有序集合中是否有相关联的分值， 我们可以知道该用户是否在线：

ZSCORE "online_users" <user_id>

而通过执行 ZCARD 命令， 我们可以知道总共有多用户在线：

ZCARD "online_users"

使用有序集合储存在线用户的强大之处在于， 它是本文介绍的所有方案当中， 能够执行最多聚合操作的一个方案， 原因在于， 这一方案既可以通过有序集合的成员（也即是用户的 ID）进行聚合操作， 也可以根据有序集合的分值（也即是用户的登录时间）进行聚合操作。

首先， 通过 ZINTERSTORE 和 ZUNIONSTORE 命令， 我们可以对多个记录了在线用户的有序集合进行聚合计算：

# 计算出 7 天之内都有上线的用户，并将它储存到 7_days_both_online_users 有序集合当中
ZINTERSTORE 7_days_both_online_users 7 "day_1_online_users" "day_2_online_users" ... "day_7_online_users"

# 计算出 7 天之内总共有多少人上线了
ZUNIONSTORE 7_days_total_online_users 7 "day_1_online_users" ... "day_7_online_users"

此外， 通过 ZCOUNT 命令， 我们可以统计出在指定的时间段之内有多少用户在线， 而 ZRANGEBYSCORE 命令则可以让我们获取到这些用户的名单：

# 统计指定时间段内上线的用户数量
ZCOUNT "online_users" <start_timestamp> <end_timestamp>

# 获取指定时间段内上线的用户名单
ZRANGEBYSCORE "online_users" <start_timestamp> <end_timestamp> WITHSCORES

通过这一方法， 我们可以知道网站在不同时间段的上线人数以及上线用户名单， 比如说， 我们可以用这个方法来分别获知网站在早晨、上午、中午、下午和夜晚的上线人数。

（3）、使用集合

如果我们只想要记录在线用户的名单， 而不想要储存用户的上线时间， 那么也可以使用集合来代替有序集合， 对在线的用户进行记录。

在这种情况下， 每当一个用户上线时， 我们就执行以下 SADD 命令， 将它添加到在线用户名单当中：

SADD "online_users" <user_id>

通过使用 SISMEMBER 命令， 我们可以检查一个指定的用户当前是否在线：

SISMEMBER "online_users" <user_id>

而统计在线人数的工作则可以通过执行 SCARD 命令来完成：

SCARD "online_users"

通过集合运算操作， 我们可以像有序集合方案一样， 对不同时间段或者日期的在线用户名单进行聚合计算。 比如说， 通过 SINTER 或者 SINTERSTORE 命令， 我们可以计算出一周都有在线的用户：

SINTER "day_1_online_users" "day_2_online_users" ... "day_7_online_users"

此外， 通过 SUNION 命令或者 SUNIONSTORE 命令， 我们可以计算出一周内在线用户的总数量：

SUNION "day_1_online_users" "day_2_online_users" ... "day_7_online_users"

而通过执行 SDIFF 命令或者 SDIFFSTORE 命令， 我们可以知道哪些用户今天上线了， 但是昨天没有上线：

SDIFF "today_online_users" "yesterday_online_users"

又或者工作日上线了， 但是假日没有上线：

# 计算工作日上线名单
SINTERSTORE "weekday_online_users" "monday_online_users" "tuesday_online_users" ... "friday_online_users"
# 计算假日上线名单
SINTERSTORE "holiday_online_users" "saturday_online_users" "sunday_online_users"
# 计算工作日上线但是假日未上线的名单
SDIFF "weekday_online_users" "holiday_online_users"

（4）、使用 HyperLogLog

虽然使用有序集合和集合能够很好地完成记录在线人数的工作， 但以上这两个方案都有一个明显的缺点， 那就是， 这两个方案耗费的内存会随着被统计用户数量的增多而增多： 如果你的网站用户数量比较多， 又或者你需要记录多天/多个时段的在线用户名单并进行聚合计算， 那么这两个方案可能会消耗你大量内存。

另一方面， 在有些情况下， 我们只想要知道在线用户的人数， 而不需要知道具体的在线用户名单， 这时有序集合和集合储存的信息就会显得多余了。

在需要尽可能地节约内存并且只需要知道在线用户数量的情况下， 我们可以使用 HyperLogLog 来对在线用户进行统计： HyperLogLog 是一个概率算法， 它可以对元素的基数进行估算， 并且每个 HyperLogLog 只需要耗费 12 KB 内存， 对于用户数量非常多但是内存却非常紧张的系统， 这一方案无疑是最佳之选。

在这一方案下， 我们使用 PFADD 命令去记录在线的用户：

PFADD "online_users" <user_id>

使用 PFCOUNT 命令获取在线人数：

PFCOUNT "online_users"

因为 HyperLogLog 也提供了计算交集的 PFMERGE 命令， 所以我们也可以用这个命令计算出多个给定时间段或日期之内， 上线的总人数：

# 统计 7 天之内总共有多少人上线了
PFMERGE "7_days_both_online_users" "day_1_online_users" "day_2_online_users" ... "day_7_online_users"
PFCOUNT "7_days_both_online_users"

（五）、使用位图（bitmap）

回顾上面介绍的三个方案， 我们可以得出以上结论：

• 使用有序集合或者集合能够储存具体的在线用户名单， 但是却需要消耗大量的内存；
• 而使用 HyperLogLog 虽然能够有效地减少统计在线用户所需的内存， 但是它却没办法准确地记录具体的在线用户名单。

那么是否存在一种既能够获得在线用户名单， 又可以尽量减少内存消耗的方法存在呢？ 这种方法的确存在 —— 使用 Redis 的位图就可以办到。

Redis 的位图就是一个由二进制位组成的数组， 通过将数组中的每个二进制位与用户 ID 进行一一对应， 我们可以使用位图去记录每个用户是否在线。

当一个用户上线时， 我们就使用 SETBIT 命令， 将这个用户对应的二进制位设置为 1 ：

# 此处的 user_id 必须为数字，因为它会被用作索引
SETBIT "online_users" <user_id> 1

通过使用 GETBIT 命令去检查一个二进制位的值是否为 1 ， 我们可以知道指定的用户是否在线：

GETBIT "online_users" <user_id>

而通过 BITCOUNT 命令， 我们可以统计出位图中有多少个二进制位被设置成了 1 ， 也即是有多少个用户在线：

BITCOUNT "online_users"

跟集合一样， 用户也能够对多个位图进行聚合计算 —— 通过 BITOP 命令， 用户可以对一个或多个位图执行逻辑并、逻辑或、逻辑异或或者逻辑非操作：

# 计算出 7 天都在线的用户
BITOP "AND" "7_days_both_online_users" "day_1_online_users" "day_2_online_users" ... "day_7_online_users"

# 计算出 7 在的在线用户总人数
BITOP "OR" "7_days_total_online_users" "day_1_online_users" "day_2_online_users" ... "day_7_online_users"

# 计算出两天当中只有其中一天在线的用户
BITOP "XOR" "only_one_day_online" "day_1_online_users" "day_2_online_users"

HyperLogLog 方案记录一个用户是否在线需要花费 1 个二进制位， 对于用户数为 100 万的网站来说， 使用这一方案只需要耗费 125 KB 内存， 而对于用户数为 1000 万的网站来说， 使用这一方案也只需要花费 1.25 MB 内存。

虽然位图节约内存的效果不及 HyperLogLog 那么显著， 但是使用位图可以准确地判断一个用户是否上线， 并且能够像集合和有序集合一样， 对在线用户名单进行聚合计算。 因此对于想要尽量节约内存， 但又需要准确地知道用户是否在线， 又或者需要对用户的在线名单进行聚合计算的应用来说， 使用位图可以说是最佳之选。

（六）、总结

以下表格总结了以上四个方案的特点：

方案	特点
有序集合	能够同时储存在线用户的名单以及用户的上线时间，能够执行非常多的聚合计算操作，但是耗费的内存也非常多。
集合	能够储存在线用户的名单，也能够执行聚合计算，消耗的内存比有序集合少，但是跟有序集合一样，这个方案消耗的内存也会随着用户数量的增多而增多。
HyperLogLog	无论需要统计的用户有多少，只需要耗费 12 KB 内存，但由于概率算法的特性，只能给出在线人数的估算值，并且也无法获取准确的在线用户名单。
位图	在尽可能节约内存的情况下，记录在线用户的名单，并且能够对这些名单执行聚合操作。

因为 Redis 同时支持多种数据结构， 所以一个问题常常可以在 Redis 里面找多种不同的解法， 并且每种解法都有各自的优点和缺点。