图 1：本文封面，五种数据结构各配一个图形暗喻。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料，与任何公司的当前招聘无关。「Redis 最适合什么场景」这道题，面试官想听的不是背五种类型名，而是你能否把业务场景映射到正确的结构上——映射错了，性能优势立刻变成事故隐患。
想象面试现场：「说说 Redis 的几种数据结构，各自适合干什么？」
第一步，先立总纲。
Redis 官方对自己的定位是「内存型数据结构服务器」。这句话里有两个关键词：内存——所以快、但容量受内存限制；数据结构——它的价值不是「能存 key-value」，而是把常用数据结构直接做成了一等公民，很多在应用层要加锁、要循环的操作，在 Redis 里是一条原子命令。五种基础结构对号入座，是这道题的主体答案。
第二步，String：计数器与会话缓存。
String 是最基础的类型，值就是一串字节。两类场景最经典：一是计数，阅读数、库存扣减、接口限流的「每分钟一百次」，INCR 一条命令原子完成，不用读改写三步加锁；二是简单缓存，会话信息、配置项、接口响应序列化后整个塞进去，配合过期时间就是标准的缓存用法。
第三步，Hash：对象的属性存取。
一个对象有十几个字段，如果只把它整个序列化成 JSON 塞进 String，改一个字段就要读出整个值、反序列化、改完再写回——并发下还会互相覆盖。Hash 把对象的字段摊平成 field-value，HSET 改单个字段、HGET 读单个字段，互不干扰。用户资料、商品属性这类「一个实体多个属性」的结构，默认用 Hash。
第四步，List：简单队列与最新列表。
List 是按插入顺序排的字符串列表，两头进出的操作都是 O(1)。两个典型用法：LPUSH 加 BRPOP 凑成一个简单任务队列，生产者往左推、消费者阻塞地从右取；LPUSH 加 LTRIM 维护「最新 N 条」——比如站点最新动态，永远只保留前一百条。官方文档也提醒：操作 list 中间元素的命令是 O(n)，大列表上慎用；需要处理不确定长度的事件流时，可以考虑用 Stream 替代。
第五步，Set 与 ZSet：去重关系与排行榜。
Set 是无序不重复集合，添加、删除、判存在都是 O(1)。标签系统、抽奖去重天然适配；更妙的是集合运算——SINTER 求交集直接算出「共同好友」「共同关注」，应用层要写两重循环的事，这里一条命令。
ZSet 在 Set 的基础上给每个成员挂一个分数，按分数排序。排行榜是它的主场：ZADD 更新分数，ZRANGE 取前 N 名，都是引擎内完成，不用拉回应用层排序。把分数设成时间戳，ZSet 又变成延迟队列——到期的任务按分数顺序弹出来执行。
图 2：五个场景到五种结构的映射，以及 Redis 的适用边界。
第六步，讲清边界：为什么不能当通用数据库。
一是容量受内存限制，内存比磁盘贵得多，全量业务数据放进来不划算。二是没有复杂查询能力，没有 join、没有多条件组合查询，业务上的关联查询它接不住。三是持久化是取舍项，无论快照还是追加日志，都要在数据安全与性能之间做选择，可靠性设计和关系型数据库不在一个假设上。结论：Redis 最适合站在数据库前面当加速层——缓存、计数、排行、队列这些「快比全重要」的场景，而不是取代数据库。
易错点清单。
一，把对象整个序列化成 JSON 塞 String，然后困惑为什么改字段会互相覆盖。二，用 List 做排行榜，每次更新都拉回应用层重排再整体写回，白白放弃 ZSet。三，生产环境用 KEYS 命令找 key——它会扫全库阻塞实例，该用 SCAN 渐进遍历。四，不给缓存 key 设过期时间，内存涨满触发淘汰才开始排查。
回到面试现场，建议的答题节奏：先给「内存型数据结构服务器」的定位，再按场景逐个映射五种结构（每个配一句选型理由），最后主动讲清三条边界。这套答案在 AI 应用里几乎天天用：会话缓存、限流计数器、任务队列、热度排行榜，按场景选对结构，比堆机器更能降延迟。
这五种结构里，你用哪一种的次数最多？有没有过「选错结构」被教育过的经历？欢迎分享。