Redis数据类型选择与性能对比

Redis数据类型选择远不止“能用就行”，而是关乎性能、内存与可靠性的关键决策：HSET适合字段固定且需高频单字段读写的场景，SET则在整条数据原子替换或结构动态时更优；LIST队列缺乏可靠性机制，应优先选用STREAM实现带ACK和重试的健壮消息系统；ZSET排行榜务必避免浮点score和大范围分页，善用整数score与替代方案如STREAM；而大SET虽提供O(1)查询，但SMEMBERS极易引发内存与网络风暴——选对类型，不是语法问题，而是架构成败的起点。

字符串 SET 和哈希 HSET 存用户资料，哪个更快？

查单个字段（比如用户昵称）时，HSET + HGET 通常比 SET + JSON 解析快；但写入整条用户数据时，SET 一次存 JSON 更省网络往返。

常见错误是把所有字段塞进一个 SET 键里，结果每次改邮箱还得取、解析、改、序列化、再存——实际耗时翻倍，还容易出并发覆盖。

• 字段少且固定（如 name、age）、读写粒度细 → 用 HSET user:123 name "Alice" age "28"
• 字段动态多变（如用户扩展属性、标签列表）、或需原子性整体替换 → 用 SET user:123 '{"name":"Alice","tags":["vip"]}'
• HGETALL 返回全部字段，但网络开销大；HGET 单字段才是哈希的真正优势点

用 LIST 做消息队列？小心阻塞和丢消息

LPUSH + BRPOP 看似能当队列用，但没确认机制、不支持重试、消费者崩溃就丢数据。真要轻量级队列，优先考虑 STREAM。

性能上，LIST 的 LPOP 是 O(1)，但 LRANGE 查历史是 O(N)；而 STREAM 的 XREAD 是 O(M)，M 是返回条数，天然适合游标分页。

• 仅临时缓存最近 N 条日志（如操作审计）→ LPUSH log:recent "op=login" + LTRIM log:recent 0 99
• 需要消费组、ACK、失败重投 → 必须用 XADD stream:order ... + XGROUP CREATE
• BLPOP 超时后返回 nil，容易被当成“无任务”跳过，实际可能只是刚好空窗——得配合监控延迟指标

ZSET 排行榜卡顿？别只看 ZRANGE 复杂度

ZRANGE rank:game 0 99 WITHSCORES 看似 O(log N + M)，但当 N 达千万级、M 固定为 100，瓶颈常在内存带宽和网络序列化——特别是 score 是浮点数时，Redis 序列化开销比整数高 2–3 倍。

更隐蔽的问题是：用时间戳当 score 做“最新 TOP100”，一旦有大量写入，zset 的跳跃表会频繁调整层级，CPU 毛刺明显。

• 纯分数排序（如积分榜）→ score 用整数，避免浮点；key 设计为 rank:game:score
• 按时间倒序取最新（如热搜）→ 改用 STREAM + XREVRANGE，天然按插入顺序索引，不依赖 score 计算
• 需要分页（第 10001–10100 名）→ ZRANGE 跳过前 10000 项仍是 O(N)，此时应预生成“段缓存”，比如每万名为一个 key

集合 SET 去重和交集，内存比想象中吃得多

一个含 100 万个字符串的 SET，实际内存占用可能是原始字符串总长的 3–5 倍——因为 Redis 用 intset（小整数）或 hashtable（通用），后者每个元素额外带指针、hash 桶、rehash 预留空间。

如果只是判断“用户 A 是否在黑名单”，SET 没问题；但要是存“每个商品的百万级 SKU ID”，就得警惕：SISMEMBER 是 O(1)，可 SMEMBERS 全量拉取会打爆客户端内存。

• 成员稳定、总量可控（SADD black:user 1001 1002
• 成员超 50 万 或 含长字符串（如 UUID）→ 改用布隆过滤器（BF.ADD，需 RedisBloom 模块）省 80%+ 内存
• 求多个集合交集（SINTER）时，Redis 会自动选最小集合做基准遍历——所以别把大集合放第一个参数，否则白耗 CPU

最常被忽略的是：SET 不保证插入顺序，也不支持范围查询。以为能靠 SSCAN 分批处理就安全，其实 scan 游标不保证一致性，两次 scan 间增删可能导致漏或重复。

好了，本文到此结束，带大家了解了《Redis数据类型选择与性能对比》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！