Skip to content

Commit ac55f1d

Browse files
committed
[docs update]完善 Redis常见面试题总结(下) Redis hotkey(热Key)
1 parent cf282ce commit ac55f1d

File tree

9 files changed

+199
-37
lines changed

9 files changed

+199
-37
lines changed

docs/database/redis/redis-common-blocking-problems-summary.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -111,7 +111,7 @@ Redis 集群可以进行节点的动态扩容缩容,这一过程目前还处
111111

112112
## Swap(内存交换)
113113

114-
什么是 Swap?Swap 直译过来是交换的意思,Linux 中的 Swap 常被称为内存交换或者交换分区。类似于 Windows 中的虚拟内存,就是当内存不足的时候,把一部分硬盘空间虚拟成内存使用,从而解决内存容量不足的情况。因此,Swap 分区的作用就是牺牲硬盘,增加内存,解决 VPS 内存不够用或者爆满的问题。
114+
**什么是 Swap?** Swap 直译过来是交换的意思,Linux 中的 Swap 常被称为内存交换或者交换分区。类似于 Windows 中的虚拟内存,就是当内存不足的时候,把一部分硬盘空间虚拟成内存使用,从而解决内存容量不足的情况。因此,Swap 分区的作用就是牺牲硬盘,增加内存,解决 VPS 内存不够用或者爆满的问题。
115115

116116
Swap 对于 Redis 来说是非常致命的,Redis 保证高性能的一个重要前提是所有的数据在内存中。如果操作系统把 Redis 使用的部分内存换出硬盘,由于内存与硬盘读写的速度并几个数量级,会导致发生交换后的 Redis 性能急剧下降。
117117

docs/database/redis/redis-questions-02.md

Lines changed: 135 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -186,6 +186,11 @@ Redis 从 2.6 版本开始支持执行 Lua 脚本,它的功能和事务非常
186186

187187
## Redis 性能优化(重要)
188188

189+
除了下面介绍的内容之外,再推荐两篇不错的文章:
190+
191+
- [你的 Redis 真的变慢了吗?性能优化如何做 - 阿里开发者](https://mp.weixin.qq.com/s/nNEuYw0NlYGhuKKKKoWfcQ)
192+
- [Redis 常见阻塞原因总结 - JavaGuide](./redis-common-blocking-problems-summary.md)
193+
189194
### 使用批量操作减少网络传输
190195

191196
一个 Redis 命令的执行可以简化为以下 4 步:
@@ -271,15 +276,15 @@ Lua 脚本同样支持批量操作多条命令。一段 Lua 脚本可以视作
271276

272277
个人建议不管是否开启 lazy-free,我们都尽量给 key 设置随机过期时间。
273278

274-
### Redis bigkey
279+
### Redis bigkey(大 Key)
275280

276281
#### 什么是 bigkey?
277282

278283
简单来说,如果一个 key 对应的 value 所占用的内存比较大,那这个 key 就可以看作是 bigkey。具体多大才算大呢?有一个不是特别精确的参考标准:string 类型的 value 超过 10 kb,复合类型的 value 包含的元素超过 5000 个(对于复合类型的 value 来说,不一定包含的元素越多,占用的内存就越多)。
279284

280285
#### bigkey 有什么危害?
281286

282-
除了会消耗更多的内存空间,bigkey 对性能也会有比较大的影响。因此,我们应该尽量避免写入 bigkey
287+
bigkey 除了会消耗更多的内存空间和带宽,还会对性能造成比较大的影响。因此,我们应该尽量避免 Redis 中存在 bigkey
283288

284289
#### 如何发现 bigkey?
285290

@@ -313,7 +318,7 @@ Biggest string found '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28
313318
314319
从这个命令的运行结果,我们可以看出:这个命令会扫描(Scan) Redis 中的所有 key ,会对 Redis 的性能有一点影响。并且,这种方式只能找出每种数据结构 top 1 bigkey(占用内存最大的 string 数据类型,包含元素最多的复合数据类型)。
315320
316-
**2、分析 RDB 文件**
321+
**2、借助开源工具分析 RDB 文件**
317322
318323
通过分析 RDB 文件来找出 big key。这种方案的前提是你的 Redis 采用的是 RDB 持久化。
319324
@@ -322,6 +327,130 @@ Biggest string found '"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28
322327
- [redis-rdb-tools](https://github.com/sripathikrishnan/redis-rdb-tools):Python 语言写的用来分析 Redis 的 RDB 快照文件用的工具
323328
- [rdb_bigkeys](https://github.com/weiyanwei412/rdb_bigkeys) : Go 语言写的用来分析 Redis 的 RDB 快照文件用的工具,性能更好。
324329
330+
**3、借助公有云的 Redis 分析服务。**
331+
332+
如果你用的是公有云的 Redis 服务的话,可以看看其是否提供了 key 分析功能(一般都提供了)。
333+
334+
这里以阿里云 Redis 为例说明,它支持 bigkey 实时分析、发现,文档地址:<https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature>
335+
336+
![阿里云Key分析](https://oss.javaguide.cn/github/javaguide/database/redis/aliyun-key-analysis.png)
337+
338+
#### 如何处理 bigkey?
339+
340+
bigkey 的常见处理以及优化办法如下(这些方法可以配合起来使用):
341+
342+
- **分割 bigkey**:将一个 bigkey 分割为多个小 key。这种方式需要修改业务层的代码,一般不推荐这样做。
343+
- **手动清理**:Redis 4.0+ 可以使用 `UNLINK` 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 `SCAN` 命令结合 `DEL` 命令来分批次删除。
344+
- **采用合适的数据结构**:比如使用 HyperLogLog 统计页面 UV。
345+
346+
### Redis hotkey(热 Key)
347+
348+
#### 什么是 hotkey?
349+
350+
简单来说,如果一个 key 的访问次数比较多且明显多于其他 key 的话,那这个 key 就可以看作是 hotkey。例如在 Redis 实例的每秒处理请求达到 5000 次,而其中某个 key 的每秒访问量就高达 2000 次,那这个 key 就可以看作是 hotkey。
351+
352+
hotkey 出现的原因主要是某个热点数据访问量暴增,如重大的热搜事件、参与秒杀的商品。
353+
354+
#### hotkey 有什么危害?
355+
356+
处理 hotkey 会占用大量的 CPU 和带宽,可能会影响 Redis 实例对其他请求的正常处理。此外,如果突然访问 hotkey 的请求超出了 Redis 的处理能力,Redis 就会直接宕机。这种情况下,大量请求将落到后面的数据库上,可能会导致数据库崩溃。
357+
358+
因此,hotkey 很可能成为系统性能的瓶颈点,需要单独对其进行优化,以确保系统的高可用性和稳定性。
359+
360+
#### 如何发现 hotkey?
361+
362+
**1、使用 Redis 自带的 `--hotkeys` 参数来查找。**
363+
364+
Redis 4.0.3 版本中新增了 `hotkeys` 参数,该参数能够返回所有 key 的被访问次数。
365+
366+
使用该方案的前提条件是 Redis Server 的 `maxmemory-policy` 参数设置为 LFU 算法,不然就会出现如下所示的错误。
367+
368+
```bash
369+
# redis-cli -p 6379 --hotkeys
370+
371+
# Scanning the entire keyspace to find hot keys as well as
372+
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
373+
# per 100 SCAN commands (not usually needed).
374+
375+
Error: ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.
376+
```
377+
378+
Redis 中有两种 LFU 算法:
379+
380+
- **volatile-lru(least recently used)**:从已设置过期时间的数据集(`server.db[i].expires`)中挑选最近最少使用的数据淘汰。
381+
- **allkeys-lru(least recently used)**:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的 key(这个是最常用的)。
382+
383+
以下是配置文件 `redis.conf` 中的示例:
384+
385+
```properties
386+
# 使用 volatile-lfu 策略
387+
maxmemory-policy volatile-lfu
388+
389+
# 或者使用 allkeys-lfu 策略
390+
maxmemory-policy allkeys-lfu
391+
```
392+
393+
需要注意的是,`hotkeys` 命令也会增加 Redis 实例的 CPU 和内存消耗(全局扫描),因此需要谨慎使用。
394+
395+
**2、使用`monitor` 命令。**
396+
397+
`monitor` 命令是 Redis 提供的一种实时查看 Redis 的所有操作的方式,可以用于临时监控 Redis 实例的操作情况,包括读写、删除等操作。
398+
399+
由于该命令对 Redis 性能的影响比较大,因此禁止长时间开启 `monitor`(生产环境中建议谨慎使用该命令)。
400+
401+
```java
402+
# redis-cli
403+
127.0.0.1:6379> monitor
404+
OK
405+
1683638260.637378 [0 172.17.0.1:61516] "ping"
406+
1683638267.144236 [0 172.17.0.1:61518] "smembers" "mySet"
407+
1683638268.941863 [0 172.17.0.1:61518] "smembers" "mySet"
408+
1683638269.551671 [0 172.17.0.1:61518] "smembers" "mySet"
409+
1683638270.646256 [0 172.17.0.1:61516] "ping"
410+
1683638270.849551 [0 172.17.0.1:61518] "smembers" "mySet"
411+
1683638271.926945 [0 172.17.0.1:61518] "smembers" "mySet"
412+
1683638274.276599 [0 172.17.0.1:61518] "smembers" "mySet2"
413+
1683638276.327234 [0 172.17.0.1:61518] "smembers" "mySet"
414+
```
415+
416+
在发生紧急情况时,我们可以选择在合适的时机短暂执行 monitor 命令并将输出重定向至文件,在关闭 monitor 命令后通过对文件中请求进行归类分析即可找出这段时间中的 hotkey。
417+
418+
**3、借助开源项目。**
419+
420+
京东零售的 [hotkey](https://gitee.com/jd-platform-opensource/hotkey) 这个项目不光支持 hotkey 的发现,还支持 hotkey 的处理。
421+
422+
![京东零售开源的 hotkey](https://oss.javaguide.cn/github/javaguide/database/redis/jd-hotkey.png)
423+
424+
**4、根据业务情况提前预估。**
425+
426+
可以根据业务情况来预估一些 hotkey,比如参与秒杀活动的商品数据等。不过,我们无法预估所有 hotkey 的出现,比如突发的热点新闻事件等。
427+
428+
**5、业务代码中记录分析。**
429+
430+
在业务代码中添加相应的逻辑对 key 的访问情况进行记录分析。不过,这种方式会让业务代码的复杂性增加,一般也不会采用。
431+
432+
**6、借助公有云的 Redis 分析服务。**
433+
434+
如果你用的是公有云的 Redis 服务的话,可以看看其是否提供了 key 分析功能(一般都提供了)。
435+
436+
这里以阿里云 Redis 为例说明,它支持 hotkey 实时分析、发现,文档地址:<https://www.alibabacloud.com/help/zh/apsaradb-for-redis/latest/use-the-real-time-key-statistics-feature>
437+
438+
![阿里云Key分析](https://oss.javaguide.cn/github/javaguide/database/redis/aliyun-key-analysis.png)
439+
440+
#### 如何解决 hotkey?
441+
442+
hotkey 的常见处理以及优化办法如下(这些方法可以配合起来使用):
443+
444+
- **读写分离**:主节点处理写请求,从节点处理读请求。
445+
- **使用 Redis Cluster**:将热点数据分散存储在多个 Redis 节点上。
446+
- **二级缓存**:hotkey 采用二级缓存的方式进行处理,将 hotkey 存放一份到 JVM 本地内存中(可以用 Caffeine)。
447+
448+
除了这些方法之外,如果你使用的公有云的 Redis 服务话,还可以留意其提供的开箱即用的解决方案。
449+
450+
这里以阿里云 Redis 为例说明,它支持通过代理查询缓存功能(Proxy Query Cache)优化热点 Key 问题。
451+
452+
![通过阿里云的Proxy Query Cache优化热点Key问题](https://oss.javaguide.cn/github/javaguide/database/redis/aliyun-hotkey-proxy-query-cache.png)
453+
325454
### Redis 内存碎片
326455
327456
**相关问题**
@@ -518,5 +647,6 @@ Cache Aside Pattern 中遇到写请求是这样的:更新 DB,然后直接删
518647
519648
- 《Redis 开发与运维》
520649
- 《Redis 设计与实现》
521-
- Redis Transactions : https://redis.io/docs/manual/transactions/
522-
- What is Redis Pipeline:https://buildatscale.tech/what-is-redis-pipeline/
650+
- Redis Transactions : <https://redis.io/docs/manual/transactions/>
651+
- What is Redis Pipeline:<https://buildatscale.tech/what-is-redis-pipeline/>
652+
- 一文详解 Redis 中 BigKey、HotKey 的发现与处理:<https://mp.weixin.qq.com/s/FPYE1B839_8Yk1-YSiW-1Q>

docs/distributed-system/rpc/dubbo.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -435,7 +435,7 @@ Dubbo 中的 `RoundRobinLoadBalance` 的代码实现被修改重建了好几次
435435

436436
### Dubbo 支持哪些序列化方式呢?
437437

438-
![](https://oss.javaguide.cn/github/javaguide/csdn/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70-20230309234143460.png)
438+
![Dubbo 支持的序列化协议](https://oss.javaguide.cn/github/javaguide/csdn/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM0MzM3Mjcy,size_16,color_FFFFFF,t_70-20230309234143460.png)
439439

440440
Dubbo 支持多种序列化方式:JDK 自带的序列化、hessian2、JSONKryoFSTProtostuffProtoBuf 等等。
441441

@@ -456,4 +456,4 @@ Kryo 和 FST 这两种序列化方式是 Dubbo 后来才引入的,性能非常
456456

457457
Dubbo 官方文档中还有一个关于这些[序列化协议的性能对比图](https://dubbo.apache.org/zh/docs/v2.7/user/serialization/#m-zhdocsv27userserialization)可供参考。
458458

459-
![](https://oscimg.oschina.net/oscnet/up-00c3ce1e5d222e477ed84310239daa2f6b0.png)
459+
![序列化协议的性能对比](https://oscimg.oschina.net/oscnet/up-00c3ce1e5d222e477ed84310239daa2f6b0.png)

docs/distributed-system/rpc/rpc-intro.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -5,9 +5,9 @@ tag:
55
- rpc
66
---
77

8-
简单介绍一下 RPC 相关的基础概念。
8+
这篇文章会简单介绍一下 RPC 相关的基础概念。
99

10-
## 何为 RPC?
10+
## RPC 是什么?
1111

1212
**RPC(Remote Procedure Call)** 即远程过程调用,通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。
1313

@@ -136,4 +136,5 @@ Dubbo 也是 Spring Cloud Alibaba 里面的一个组件。
136136

137137
## 既然有了 HTTP 协议,为什么还要有 RPC ?
138138

139-
[HTTP 和 RPC 详细对比](http&rpc.md)
139+
关于这个问题的详细答案,请看这篇文章:[有了 HTTP 协议,为什么还要有 RPC ?](http&rpc.md)
140+

0 commit comments

Comments
 (0)