当前位置：首页 > 问答 > 正文

Redis里怎么快点儿读二进制数据，性能和方法聊聊

符海莹
问答
2026-01-08 17:49:19
3

关于如何在Redis里快速读取二进制数据,核心思路其实就一句话：尽量减少数据在网络上传输的大小和减少Redis服务器端的计算压力，二进制数据本身已经是紧凑的格式了，所以我们的优化重点不在数据本身，而在于“怎么拿”和“拿什么”。

核心方法：选择合适的数据结构和命令

Redis不是简单的键值存储,它提供了多种数据结构，对于二进制数据，选择哪种结构至关重要。

String（字符串）类型：最简单直接
- 适用场景：你的二进制数据是一个完整的、不可分割的整体，比如一张图片、一个PDF文件、一个序列化后的对象。
- 操作方法：直接使用 SET 和 GET 命令，这是最基础的方法。
- 性能分析：
  - 优点：极其简单，命令消耗小，对于单个不是特别巨大的（例如几MB以内）二进制块，速度很快。
  - 缺点：如果数据非常大（比如几十MB甚至上百MB的视频文件），一个 GET 操作会一次性将整个数据块从Redis服务器传输到客户端，这会占用大量网络带宽，导致网络延迟成为瓶颈，同时也会在客户端和服务器端消耗大量内存来承载这个完整的数据块，根据Redis官方文档的隐性建议，过大的Key会影响服务器稳定性。
Hash（哈希）类型：化整为零
- 适用场景：你的二进制数据逻辑上可以分成多个小块，一个大的文件可以被分成多个1MB的块。
- 操作方法：将每个数据块存储为Hash中的一个Field，一个文件file:123，你可以用 HSET file:123 chunk1 <二进制数据1> chunk2 <二进制数据2> 来存储，读取时，可以用 HGET file:123 chunk1 读取特定块，或者用 HGETALL file:123 读取全部（慎用，有和超大String同样的问题）。
- 性能分析：
  - 优点：实现了“按需读取”，你不需要整个文件时，可以只读取其中一个或几个块，极大减少网络传输量，这对于处理大文件的部分内容非常高效。
  - 缺点：管理起来稍复杂，你需要自己在客户端维护分块和合并的逻辑，如果总是需要读取整个Hash，使用 HGETALL 的性能收益会消失，甚至可能比String的 GET 更差，因为命令本身更复杂。
List（列表）类型：流水线式读取
- 适用场景：二进制数据是顺序的、流式的，或者是由多个片段自然组成的，比如监控视频的帧数据、连续的日志流。
- 操作方法：使用 LPUSH/RPUSH 将二进制数据片段依次存入列表，使用 LRANGE 命令批量读取一个范围内的片段，或者使用 LPOP/RPOP 进行消费式读取。
- 性能分析：
  - 优点：非常适合流式处理。LRANGE 命令可以一次获取多个片段，减少了网络往返次数（RTT）。
  - 缺点：无法随机访问中间的某个特定片段（虽然LRANGE可以，但需要知道索引），更适合FIFO（先进先出）或LIFO（后进先出）的场景。

关键技巧：使用管道（Pipeline）

无论你选择哪种数据结构,管道（Pipeline） 都是提升读取性能的“大杀器”，它的原理很简单：在通常模式下，客户端发送一个命令，等待Redis返回结果，再发送下一个命令，这个等待时间（网络延迟）在多次操作中会累积起来，非常可观。

管道允许客户端一次性将多个命令打包发送给Redis服务器,服务器依次处理所有命令后，再将结果一次性打包返回给客户端，这样就将多次网络往返时间（RTT）压缩成了两次（一次发送，一次接收）。

Redis里怎么快点儿读二进制数据，性能和方法聊聊

举例：如果你需要从Hash中读取10个不同的字段，不使用管道需要10次网络往返，使用管道，只需要1次网络往返，对于高延迟的网络环境（比如客户端和服务器不在同一个机房），性能提升是数量级的。

根据Redis之父Salvatore Sanfilippo（antirez）在博客中的说明，使用管道可以将性能提升至原来的5到10倍，尤其是在操作数量多、网络延迟高的情况下。

需要谨慎使用或避免的方法

避免使用KEYS命令：如果你需要查找存储了二进制数据的键，绝对不要在生产环境使用 KEYS * 命令，它会扫描数据库中的所有键，会导致Redis服务器暂时卡顿，应该使用 SCAN 命令及其游标方式进行迭代查询，它是非阻塞的。
大Key预警：反复强调，尽量避免存储非常大的单个String值（例如超过10MB），Redis是内存数据库，操作大Key会导致内存分配和网络传输问题，影响整体性能和稳定性。“化整为零”的Hash或List策略是更好的选择。

实战策略总结

综合起来,给你几个实战建议：