ホワイトハウス報道官
在 Redis 缓存业务对象时，Hash、String+JSON 与 RedisJSON 的选型需基于访问模式：高频局部更新宜用 Hash（支持原子操作），大对象频繁全量读写则推荐 JSON；嵌套结构可考虑 RedisJSON。避免误区如“Hash 必省内存”“字段级过期天然支持”，注意编码切换、HGETALL 阻塞风险及版本兼容性。核心原则：按访问模式选型，而非类型偏好。 在 Redis 做业务对象缓存时，几乎所有开发者都会面临这个经典抉择： Hash：HSET user:1001 name "张三" age 28，将对象扁平拆分为…
Redis List 因其灵活的结构常被误用，易引发阻塞连接不释放、重复消费、大列表阻塞等问题。本文聚焦三大核心：命令组合（栈/队列/环形用法）、quicklist编码机制（节点阈值调优）、阻塞操作6大边界陷阱。详解 LPUSH/RPOP、BLPOP/BRPOP等命令语义与性能边界，揭示 LTRIM、LINDEX 等高危操作风险，强调阻塞命令需独立连接与合理超时设置。结合 quicklist内存优化原理，指导生产环境正确使用 List 实现可靠队列，明确其与 Stream 的选型边界，避免踩坑。 List 是 Redis 里最容易被”想当然地用错”的类型——很多人觉得它不就是个链表嘛，LPUSH+RPOP 就是队列，BRPOP 就是阻塞队列，结果线上踩了阻塞连接不释放、消费者重复消费、大 List 阻塞、阻塞超时丢消息等一连串坑却不知道根因。 本篇只聚焦三件事：命令组合（栈/队列/环形三种用法）、quicklist…
本文聚焦Redis String类型，从开发视角深度解析其核心特性与实战应用。不涉底层源码，专注“怎么用、为何这样设计、如何避坑”。涵盖命令全集、三种编码（int/embstr/raw）边界、内存计算、与Hash对比、七类生产场景及序列化选型。揭示常见误区：误用导致内存翻倍、大Key卡主实例、计数器并发丢数、分布式锁失效等。强调原子操作的重要性，指导开发者规避“看似简单却致命”的陷阱，真正掌握Redis的基石类型。 一篇文章想写清楚，先得说清楚它不写什么。这一篇只做一件事：站在「用 String 这个类型」的视角，把它讲透。—— 系列的上一站《Redis 入门》解决了「Redis 能用」，从这篇开始，我们解决「Redis 到底能存什么、每种结构最擅长什么、什么时候会翻车」。 今天我们站在业务开发视角，告诉你每个特性会带来什么影响、怎么选型、怎么算内存。底层 SDS 的 C 源码、内存分配器细节不在本篇展开，统一放到源码精读篇章。 String 是 Redis 最基础的类型，也是几乎所有项目里第一个被用上的类型。正因为它”看起来简单”，反而成了被误用最严重的一个——编码被悄悄升级导致内存翻倍、一个大 Value 卡住整个实例、把本该用 Hash…
