Redis 在应用中的典型用法：缓存、消息队列、会话和计数器

学 Redis 很容易陷进命令和数据结构里：String、Hash、List、Set、Zset，AOF、RDB、主从、哨兵、集群。可真正写业务时，最先遇到的问题往往不是某条命令怎么拼，而是 Redis 到底应该放在系统的哪个位置。

相关基础内容 在“在应用中是怎么使用 Redis 的”这一节里给了几个典型方向：可以用作缓存层，存储频繁访问的数据，提高访问速度；可以用作消息队列，通过发布订阅模式传递消息；可以存储会话数据、计数器等。这几句不长，但基本覆盖了很多后端系统最常见的 Redis 使用方式。

这篇就按这几个场景展开。Redis 很快，但它不是万能仓库；Redis 有发布订阅，但不等于专业可靠消息队列；Redis 存会话和计数很方便，但仍然要考虑过期、持久化和故障恢复。把这些边界想清楚，比单纯背“Redis 能做什么”更有用。

资料 说 Redis 可以用作缓存层，存储频繁访问的数据，提高访问速度。这是 Redis 最常见也最容易理解的用法。应用先查 Redis，命中就直接返回；未命中再查 MySQL 或其他后端服务，并把结果写回 Redis。

缓存层真正缓存的不是“所有数据”，而是高频、可重建、读取成本高的数据。比如首页配置、热门商品、用户资料摘要、文章详情、接口聚合结果。它们被重复访问，放进 Redis 能减少数据库压力，也能降低请求延迟。

但缓存层要守住边界。订单状态、余额、库存扣减这类强一致事实，最终仍要以 MySQL 为准。Redis 可以加速读取，也可以辅助限流和计数，但不能随手变成业务事实的唯一来源。

缓存层是否有效，不能只看 Redis 里有多少 key。真正要看命中率、回源量、平均延迟和内存使用。命中率高，说明 Redis 挡住了大量重复请求；命中率低，说明请求大多还是打到数据库，缓存层收益有限。

失效策略也很关键。TTL 太短，数据还没被重复访问就过期；TTL 太长，用户可能长期看到旧数据。更新频繁的数据，要结合 Cache Aside、删除缓存、短 TTL 或主动刷新；变化少的数据，可以设置更长的过期时间。

缓存层还要避免冷数据长期占用内存。上一篇讲过，只有热数据缓存才有价值。Redis 内存有限，冷数据进来太多，会挤掉真正该保留的热点数据。

已有内容提到 Redis 可以用作消息队列，通过发布订阅模式传递消息。发布订阅的模型很直观：发布者把消息发到某个频道，订阅者监听频道并接收消息。它适合做轻量异步通知，比如配置变更通知、缓存刷新通知、简单事件广播。

这里要特别注意边界。Redis Pub/Sub 更像“在线广播”，不是完整的可靠消息队列。订阅者不在线时，消息通常不会为它长期保存；消费失败、重试、顺序保证、消息堆积、死信处理这些能力，也不是 Pub/Sub 的核心目标。

所以，如果只是让几个在线服务收到通知，Redis 发布订阅很轻便。如果是订单支付、库存扣减、账单生成这类关键异步链路，就应该使用专业消息队列，并设计确认、重试、幂等和补偿。Redis 可以传消息，但不能把所有异步可靠性都交给 Pub/Sub。

同时提到 Redis 可以存储会话数据。登录态、Session、Token 映射、验证码、临时授权信息，都很适合 Redis。原因很简单：读写频繁，数据量通常不大，需要过期时间，访问延迟敏感。

会话数据放进 Redis 后，应用可以快速校验用户状态。比如请求带着 token，服务到 Redis 查 token 对应的用户 id、权限摘要或登录状态。只要 Redis 命中，应用就不用每次都查数据库或重建登录上下文。

但会话数据必须设计 TTL。验证码应该几分钟过期，登录态可能几小时或几天过期，临时授权可能更短。没有过期时间，会话 key 会持续膨胀；过期时间太短，用户体验会受影响。

Redis 保存会话很方便，但故障时会影响用户体验。Redis 数据丢失，用户可能被迫重新登录；Redis 不可用，接口可能无法校验登录态。这个问题不能到事故时才想。

如果会话可以接受重新登录，设计会简单很多。Redis 只做会话存储，故障后用户重新认证即可。如果业务不希望会话大面积丢失，就要结合持久化、主从、哨兵或集群，甚至把关键登录信息和刷新令牌放到更可靠的存储里。

会话数据还有安全边界。不要在 Redis 里长期保存过多敏感信息。能存 id 和状态，就别把完整用户资料都塞进去。过期、刷新、踢下线、设备管理，都要围绕会话生命周期设计。

文中说 Redis 可以存储计数器。计数器是 Redis 的典型优势场景，因为 INCR、DECR 这类命令天然适合高频短操作。页面 PV、点赞数、评论数、短信发送次数、接口限流次数，都可以用 Redis 先承接。

计数器的关键是原子性。多个请求同时对同一个 key 做 INCR，Redis 会按命令顺序处理，不会出现应用层先读再写导致的覆盖问题。相比每次都回 MySQL 更新计数字段，Redis 的写入路径更轻。

不过，计数结果最终要不要落库，要看业务。PV 这类统计可以批量异步落库；点赞数如果要展示实时数字，可以 Redis 实时加，再定期同步；涉及额度、余额、库存的计数，就不能只靠 Redis 自增，需要数据库或业务规则兜底。

计数器看起来只是一个数字，但 key 设计不好也会膨胀。比如按用户、按天、按接口、按活动、按设备都建计数 key，很快会出现大量短期 key。没有 TTL，这些 key 会一直留在 Redis 里。

限流类计数器通常需要过期时间。比如一分钟内最多请求多少次，可以按分钟窗口设置 key，并让它自动过期。统计类计数器则要考虑汇总和清理，把明细计数定期合并到数据库或离线系统。

计数器还要考虑精确性。Redis 自增很快，但如果实例故障、AOF 策略较弱、数据还没同步，就可能丢一小段计数。对展示类统计可以接受，对财务类计数就不行。

缓存层、消息队列、会话数据、计数器看起来不同，但共同点是：Redis 适合高频、短路径、内存友好、可以明确过期或补偿的数据。它不适合承载复杂事务、长期事实、强一致账务和难以恢复的核心状态。

使用 Redis 前，可以先问四个问题：这份数据是否高频访问？是否可以重建？是否需要严格一致？故障时能接受什么损失？这四个问题比“Redis 能不能做”更重要。

Redis 的正确用法不是把业务都搬进内存，而是让内存层承接最适合它的那部分压力。缓存加速读取，Pub/Sub 做轻量通知，会话状态设置 TTL，计数器处理高频递增。边界清楚，Redis 才会越用越稳。

如果被问在应用中怎么使用 Redis，可以按 相关的几个方向回答：第一，用作缓存层，存储频繁访问的数据，提高访问速度；第二，可以用作消息队列，通过发布订阅模式传递消息；第三，可以存储会话数据；第四，可以做计数器。

然后补充每类场景的边界：缓存层适合高频可重建数据，最终事实仍以 MySQL 为准；发布订阅适合轻量通知，不等同于可靠消息队列；会话数据要设置合理过期时间，并考虑故障后的登录体验；计数器适合高频原子递增，但关键业务计数要考虑落库和补偿。

最后强调，Redis 的价值来自内存访问快和数据结构方便，但不能替代数据库、专业 MQ 或完整事务系统。把它放在合适位置，比把它用在所有地方更重要。