从前面两课走过来环境搭好了基本操作也有数了这一课终于要碰Redis里最“万能”也最容易被人低估的类型——String。说它万能是因为缓存、计数、分布式锁、共享Session、对象序列化存储随便拎一个出来都离不开它说它容易低估是因为很多人对它的理解停在SET/GET两个命令上觉得没什么可学的。实际上String背后牵着SDS结构、编码类型切换、原子操作、位图计算这些东西面试能问出一长串线上出问题排查时也总能撞到它。这一课就把它掰开揉碎从命令到原理到实战一次讲透。如果你是刚接触Redis的新手这一课能让你把String的所有核心用法一次掌握如果你已经写了一阵子Redis这一课里关于内部机制、编码切换、踩坑实录的部分大概率能帮你解释不少之前“为什么这样做就报错”的疑惑。废话不多说直接开始。1. String类型在Redis中的地位与核心特性1.1 为什么几乎所有业务都绕不开StringRedis一共提供五大基础类型——String、Hash、List、Set、ZSet但你要是在生产环境里翻一圈key会发现String类型占了绝大多数。原因很简单它足够简单、足够快又能覆盖大量业务场景。简单到什么程度一个key对应一个valuevalue可以是一个字符串、一个数字、一段JSON甚至是一张图片的二进制内容。但你别看它“只是存字符串”它背后是一套完整的动态字符串结构Redis对String的每次读写都是在内存里直接操作配合单线程事件循环吞吐量能做到非常夸张的水平。举几个最常见的例子Web应用的Session信息很多团队直接用SET session:{userId} {json} EX 3600存接口热点数据比如首页Banner、商品详情序列化成JSON后直接塞进String库存、浏览量、点赞数全量用INCR/DECR处理根本不用走数据库分布式锁里最朴素的实现也是String的SET NX EX组合。可以说String就是Redis这座魔法学院里的“基础咒语”不会用它后面学Hash和List也会觉得别扭把它吃透了后面看其他类型的源码和设计思路都会顺畅很多。1.2 String的三大特性动态字符串、二进制安全、原子性要真正理解String先记住这三个关键词。动态字符串SDS。Redis的String底层不是直接用C语言自带的char*而是自己封装了一个结构体叫SDSSimple Dynamic String简单动态字符串。它会在结构体里记录字符串的长度和剩余空间这就让它能动态扩容、能提前分配内存空间、能在缩短字符串时不必立刻释放内存。这一点在后面的“内部机制”部分我会展开细说这里你先有个印象Redis的String是“有长度、有容量管理”的高阶字符串不是裸的字节数组。二进制安全。这点很关键。C语言的字符串用\0表示结尾如果你往里面塞二进制数据只要中间出现\0数据就会被截断。但Redis的SDS通过“单独记录长度”的方式存储内容里即使有\0也不影响读取。这意味着你可以往String里放图片、放压缩包、放序列化后的对象Redis根本不关心你存的是什么它只负责把这一堆字节原样存进去、再原样取出来。原子性。Redis是单线程执行命令的所以String的INCR、DECR、SETNX这类操作天然就是原子的。不需要加锁也不会有并发竞争问题。这个特性是实现分布式锁、计数器、限流器的基础可以说“原子性”是String能玩出花来的根本原因。1.3 很容易被误会的“String只能存文本”我在面试里经常问一个问题String的value最大能存多大很多人都能回答512MB但你再追问一句“能存什么”回答就参差不齐了。String的value不是只能存纯文本。它本质是一个“字节容器”你可以往里面放普通字符串比如hello数字比如10086可以直接参与INCRBY运算JSON、XML等序列化后的文本二进制数据比如图片压缩包甚至加密后的字节流。这就引出一个非常实用的结论String其实是你手中最灵活的“管道”任何能被序列化成字节的东西都可以塞进去。但正因为它太灵活也容易用出问题。比如有人把一个几十MB的图片直接塞进Redis虽然Redis能存但会带来内存暴涨、网络传输变慢、大key阻塞等连锁问题。这个我们留到“常见问题”部分专门讲。2. String命令全景图谱从入门到进阶2.1 基础命令SET、GET、DEL、EXISTS这组命令是String的根本几乎所有业务代码都在用。但很多人只用了最基础的写法实际上SET命令的参数丰富到可以单独撑起一个分布式锁方案。先看最基础的127.0.0.1:6379 SET user:1 zhangsan OK 127.0.0.1:6379 GET user:1 zhangsan 127.0.0.1:6379 EXISTS user:1 (integer) 1 127.0.0.1:6379 DEL user:1 (integer) 1 127.0.0.1:6379 GET user:1 (nil)这里没有太多可说的但注意两点DEL返回的是删除成功的数量key不存在时返回0GET在key不存在或已过期时返回nil而不是空字符串。很多刚接触Redis的人会混淆nil和空串在代码里就容易出现判断错误。再看SET的进阶用法# 带过期时间单位是秒 SET user:1 zhangsan EX 3600 # 带过期时间单位是毫秒 SET user:1 zhangsan PX 3600000 # 只有key不存在时才设置常用于分布式锁 SET user:1 zhangsan NX # 只有key存在时才设置常用于更新 SET user:1 zhangsan XX # 组合使用 SET lock:order:1001 requestId NX PX 30000 # 保持原有TTL不被覆盖 SET user:1 newValue KEEPTTL这里的EX、PX、NX、XX、KEEPTTL是5.0以后Redis力推的原子化参数。为什么Redis官方允许在SET命令里塞这么多参数本质上是为了解决“多个命令组合执行时的非原子问题”。举个例子以前很多人写缓存是分两步先SET key value再EXPIRE key 3600。如果是单线程执行环境还好一旦有并发请求这两步之间存在时间窗口可能导致key一直不过期形成永久缓存。而SET key value EX 3600是一条命令从写入那一刻起就带上了过期时间整个操作是原子的。这组命令设计者还给了一个很贴心的KEEPTTL它在覆盖已有key的value时不会把原来的过期时间抹掉。这在缓存续期场景里非常有用——比如你只想更新内容不想重置TTL直接SET key newValue KEEPTTL就解决了。2.2 数值运算命令INCR、DECR与INCRBY家族String虽然是“字符串”类型但它能把value当成数字来运算。这就是计数器场景的基础设施。# 设置初始值 SET article:read:1001 0 # 自增1如果key不存在会自动从0开始 INCR article:read:1001 (integer) 1 # 自增指定步长 INCRBY article:read:1001 10 (integer) 11 # 自减 DECR article:read:1001 (integer) 10 DECRBY article:read:1001 5 (integer) 5 # 浮点数自增 SET article:score:1001 3.5 INCRBYFLOAT article:score:1001 0.5 4这里要特别提醒新手INCR命令要求value本身是一个能转成64位有符号整数的十进制字符串。如果value是abc或者3.14执行INCR会直接报错127.0.0.1:6379 SET name hello OK 127.0.0.1:6379 INCR name (error) ERR value is not an integer or out of range这个报错在开发中太常见了尤其是用框架自动序列化时value被包装成\100\这种带引号的JSON字符串一执行INCR就炸。后面常见问题部分我会专门说这个坑。另外一个容易忽略的细节INCRBYFLOAT虽然能做浮点运算但它不能保证精度。如果业务涉及金额计算还是得在应用层用专门的精度类型处理不要依赖Redis的浮点命令。2.3 字符串操作与位图命令APPEND、GETRANGE、SETRANGE与BIT家族这一组命令在日常业务里不常出现在CRUD代码中但在特定场景下特别好用。APPEND是在字符串末尾追加内容返回追加后的总长度127.0.0.1:6379 SET log:2026-06-01 start OK 127.0.0.1:6379 APPEND log:2026-06-01 - timeout (integer) 14 127.0.0.1:6379 GET log:2026-06-01 start - timeoutGETRANGE和SETRANGE用来做局部读取和覆盖。比如你存了一个很长的文本只想取前100个字符GETRANGE key 0 99就行。SETRANGE可以从指定偏移量覆盖内容有种操作字节数组的味道。位图命令则是String的隐藏大招。Redis的String底层是一串字节你可以把这串字节当成一个个bit来操作。# 设置第100个bit为1 SETBIT user:sign:20260601 100 1 # 获取第100个bit GETBIT user:sign:20260601 100 # 统计bit为1的数量 BITCOUNT user:sign:20260601位图最经典的应用就是用户签到。一年365天用365个bit就能表示一个用户全年的签到状态全部存储空间不到50字节。你要是把签到记录存成普通的String日期列表光存储成本就不知道高到哪里去了。命令这么多但实际用的时候不要把精力花在背命令上。我的建议是先精通SET/GET/INCR/DEL/EXISTS这类“日常五件套”再熟悉SETNX/EX/SETEX这类带附加参数的写法位图和GETRANGE这类属于“查文档就能用”的扩展能力用到时再翻也不迟。3. 五大高频应用场景深度拆解3.1 缓存场景Session共享、热点数据、短暂空值缓存String用得最多的场景肯定是缓存。但缓存也分很多种写法不是随便SET key value就完事的。Session共享。传统单体应用Session存在应用服务器内存里一旦部署多台机器用户请求落到不同机器就找不到Session了。用Redis String存Session是经典的解决方案登录成功后生成一个token以session:{token}为key把用户信息序列化成JSON存进去设置比如30分钟的过期时间。每次请求进来从Header里取token再GET一次Redis。这样无论请求落到哪台机器都能拿到同一份会话数据。热点数据缓存。比如商品详情页的数据数据库里可能几百毫秒才查出来但每天被访问几万次。这种数据很适合用String缓存。写法也很直白# 查缓存 GET product:detail:1001 # 如果缓存未命中查数据库然后写缓存 SET product:detail:1001 {json} EX 600但要注意缓存“穿透”问题往往就在这个流程里发生。所谓穿透是指一个请求查Redis没有、查数据库也没有由于没有数据可以缓存这个请求每次都会打到数据库。解决方案之一就是“空值缓存”——即使数据库没查到也写一个空对象到Redis并设置较短的过期时间比如60秒SET product:detail:999999 {} EX 60这样下次同样的请求来了Redis直接返回空对象数据库就躲过一劫。String在这里的灵活性体现得很明显value可以是任何东西哪怕是一个空JSON。热点key集中过期。还有一种场景是大量key设置了同一个过期时间到点后集体失效数据库瞬间被打爆。这被称为“缓存雪崩”。解决思路之一是在过期时间上增加随机数比如EX 600 random(0, 60)把失效时间打散。这个技巧在String缓存场景里非常实用建议直接形成习惯。3.2 计数器场景库存、限流、点赞、频控String的INCR/DECR是天然高性能计数器而且由于单线程和原子性不会出现超卖问题。库存扣减是典型场景。秒杀前先把库存加载到RedisSET stock:seckill:1001 100用户秒杀时执行DECR stock:seckill:1001DECR返回的值如果大于等于0说明扣减成功如果返回负数说明库存已扣尽需要补偿回滚。注意这里的逻辑是先扣减再根据结果判断是否要回滚而不是先判断再扣减因为先判断再扣减会存在并发窗口。访问次数限制/接口防刷也可以用String实现。比如限制某个用户一分钟最多访问10次SET rate:user:1001 1 EX 60 NX INCR rate:user:1001逻辑是key不存在时先初始化成1并设置60秒过期后续每次请求都执行INCR拿到返回值如果大于10就拒绝服务。这里SET ... NX EX保证了“初始化过期时间”是原子的不会出现初始化了但没有过期时间的bug。滑动窗口限流可以配合EXPIRE实现一个粗糙版本更精确的滑动窗口要借助ZSet但很多业务场景用固定窗口也已经能解决问题不用一味追求复杂。这个场景在现在的“agent应用”里也很常见智能体应用要统计某个用户的调用次数、累计token数或者做多轮会话的频控底层很多都是String计数器。比如每个会话维护一个agent:usage:{sessionId}每次调用INCRBY累加token消耗接近限额时自动截断。String在这类轻量统计场景里真的非常顺手。3.3 分布式锁SET NX PX、Lua脚本与误删问题分布式锁是String类型最“值钱”的场景之一也是面试高频题。最朴素的分布式锁实现其实就是一条命令SET lock:order:1001 requestId-123 NX PX 30000NX保证只有key不存在时才能设置成功相当于“加锁”PX 30000设置锁的自动过期时间防止持有锁的进程宕机后死锁value用requestId这样的唯一标识用来确认“这把锁是我的”。释放锁时不能直接DEL否则可能出现误删别人锁的问题。典型场景线程A拿到锁执行时间太长锁自动过期了线程B拿到锁线程A执行完毕直接DEL把线程B的锁给删了。所以释放锁时要先判断value是否还是自己的再删除。这个过程用Lua脚本保证原子if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end把这段脚本用EVAL执行就是业界公认的“安全释放锁”方案。当然Redis分布式锁并不完美在极端场景下主节点宕机、锁数据未同步到从节点仍可能丢失所以大型系统会引入Redlock或者更强的共识方案。但对于绝大多数中小团队的日常业务SET NX PX Lua释放锁已经够用了。3.4 其他实用场景全局ID、位图签到、对象存储除了上面三个大场景String还有一些很值得知道的用法。全局ID生成。数据库自增ID在分库分表后会冲突用Redis的INCR生成全局唯一ID是常见方案INCR global:id:order (integer) 10001注意这个ID不是严格的“趋势递增”也关系不大关键是要唯一。可以配合日期作为前缀生成类似202606010000001的订单号。位图存储。用户签到、在线状态、打卡记录这类布尔型数据用位图做最省内存。一个月用31个bit每天SETBIT user:sign:1001 day 1要统计这个月签到了几天直接BITCOUNT user:sign:1001。对象序列化存储。把整个对象序列化成JSON或protobuf塞进String这种做法虽然简单但有两点要注意。一是序列化后体积会膨胀比如一个Java对象被Jackson序列化后字段名、类型信息全都会带上原本几百字节的数据可能变成几KB二是如果对象有嵌套结构且需要频繁修改其中某个字段String反序列化后修改再整体写回效率远不如直接用Hash类型操作子字段。4. String类型的内部机制SDS与编码转换4.1 SDS结构设计为什么Redis不用C字符串Redis之所以要自己实现SDS是因为C语言原生字符串有几个硬伤第一C字符串获取长度必须遍历时间复杂度O(n)SDS在结构体里直接记录len获取长度O(1)。第二C字符串拼接时如果忘记分配内存容易缓冲区溢出SDS会在追加内容前检查剩余空间不够就扩容。第三C字符串中间不能有\0SDS以len为准二进制安全。SDS的结构大致长这样以Redis 3.2之后的版本为例struct sdshdr64 { uint64_t len; // 已使用长度 uint64_t alloc; // 分配的总容量 unsigned char flags; // 头部类型标记 char buf[]; // 字节数组 };len记录已经使用的字节数alloc记录总共分配了多少空间两者之差就是可以继续追加的“预分配空间”。之所以要预留空间是因为如果每次APPEND都重新分配内存频繁的系统调用会极大拖慢性能。SDS扩容遵循一套策略如果修改后总长度小于1MB就分配和len一样多的额外空间也就是len len 1如果修改后总长度大于等于1MB则额外分配1MB。这种“空间预分配”策略保证了一个String从创建到多次追加的过程中内存重分配次数降到很低。这也是为什么你频繁APPEND一个key时Redis不至于性能骤降的原因。4.2 三种编码类型int、embstr、rawString在Redis内部会根据value的实际情况选择不同的编码方式这直接决定了内存占用和操作效率。用OBJECT ENCODING key可以查看某个key的编码。int编码。当value是可以用8字节长整型表示的数字时String直接用整数存储不做字符串解析。比如SET num 100num的编码就是int。此时INCR/DECR直接在整数上运算性能极高。embstr编码。当value是短字符串且长度不超过44字节时Redis把SDS结构体和字符串内容分配在一次连续内存里。这样内存碎片少读写效率高。通常你SET name helloname的编码就是embstr。raw编码。当字符串长度超过44字节或者经过某些修改操作导致SDS结构需要重新分配时编码会切换成raw。raw编码下SDS结构体和buf数组分两次分配性能略低于embstr但能应对更长内容。44这个阈值的来历Redis 3.2之前是39字节3.2之后把SDS头类型细分后embstr最多能容纳44字节的数据。你可以自己验证127.0.0.1:6379 SET a 12345678901234567890123456789012345678901234 OK 127.0.0.1:6379 STRLEN a (integer) 44 127.0.0.1:6379 OBJECT ENCODING a embstr 127.0.0.1:6379 SET b 123456789012345678901234567890123456789012345 OK 127.0.0.1:6379 STRLEN b (integer) 45 127.0.0.1:6379 OBJECT ENCODING b raw注意一个特例即使value是数字如果你用了APPEND、SETRANGE这类字符串操作编码可能会从int变成raw或embstr并且不再是纯数字。这会影响后续的INCR操作。下面这个序列就能复现127.0.0.1:6379 SET num 100 OK 127.0.0.1:6379 APPEND num abc (integer) 6 127.0.0.1:6379 GET num 100abc 127.0.0.1:6379 INCR num (error) ERR value is not an integer or out of range所以业务上不要把同一个key既当计数器又当字符串拼接对象两种操作混用很容易出问题。4.3 内存优化与序列化注意事项String用多了以后内存会悄悄膨胀这里面有两个常见原因。第一个是小对象太多。Redis本身的key和value都有元数据开销一个几字节的value实际占用的内存可能有好几十字节因为每个对象头、SDS头、字典节点都要占内存。如果你有几十万个细小的key内存消耗会非常可观。这种情况可以考虑用Hash把多个字段整合到一起用Hash比存几十万个String能省下一大截内存因为Hash的底层有自己的压缩策略。第二个是序列化后体积膨胀。用Jackson/Gson把Java对象序列化成JSON字段名带引号、类型信息全部保留原本内存里可能不到1KB的对象序列化后变成几KB甚至更大。要优化可以做好几步一是用更紧凑的序列化协议比如protobuf、MessagePack二是对大JSON做压缩Redis本身就支持压缩数据但前提是你能承受压缩解压的CPU开销三是考虑结构拆分不要把一个巨大的对象全塞进一个key能拆成多个Hash的就拆。这些优化在Redis数据量小的阶段感觉不到一旦内存接近上限maxmemory触发淘汰策略淘汰谁、怎么淘汰就变成线上问题了。建议在架构设计早期就给String对象的体量留个上限别等到内存爆了才去治理。5. 常见问题与排查技巧实录5.1 INCR报错“not integer or out of range”的完整排查思路这个报错我在Redis相关的问题答疑里见过太多次了尤其在使用Spring Data Redis或者各种框架封装后特别容易踩。先看最直接的原因执行INCR/DECR/INCRBY时value不是合法的64位有符号整数。可能是以下几种情况内容本身不是数字比如abc内容超过了Long.MAX_VALUE9223372036854775807内容看起来是数字但被序列化成带引号的字符串。比如Redis Desktop Manager里看到值是100注意这个值是带双引号的它其实是JSON序列化后的字符串而不是纯数字100。用INCR必然会报错。排查步骤很简单# 查看当前值长什么样 GET rate:user:1001 # 查看value的数据类型 TYPE rate:user:1001 # 查看内部编码 OBJECT ENCODING rate:user:1001如果TYPE返回stringOBJECT ENCODING返回的却既不是int也不是embstr且GET的值一眼看去有引号那基本可以确定是序列化导致的问题。解决方案也根据原因来定如果是代码里用Jackson等库对value做了序列化导致写入的是100那么要在写入端去掉序列化直接把数值作为字符串写入如果是框架自动做的序列化可以把对应字段的类型改成String或者数值类型让它在Redis里存成纯数字如果已经积累了脏数据只能重新写入或者用一个新key。这种问题最麻烦的地方在于“看起来正常、一执行就报错”所以排查时永远先GET一下看看value的真实样子别急着查代码。5.2 大Key隐患超过1MB的String就该警惕String虽然能存512MB但你实际使用中超过1MB就得仔细想想了。大Key带来的问题有三个阻塞风险Redis是单线程GET一个几百MB的key会把整条网络链路拖慢其他请求排队等着网络风暴大key在高并发下反复读写流量翻倍地消耗带宽删除阻塞删除一个大key时释放内存也可能造成阻塞尤其在DEL时。发现大Key很简单redis-cli --bigkeys这个命令会扫描整个实例输出每种类型里最大的几个key。如果是线上实例建议在低峰期执行因为扫描本身会有一定性能开销。治理大Key的思路也很清晰把大对象拆成多个小对象比如一个巨大的文本拆成多个分段key对value做压缩减少体积删除时不要直接DEL用UNLINK异步删除来避免阻塞。UNLINK是Redis 4.0引入的它会先把key从字典中摘除然后在后台线程慢慢释放内存能有效避免DEL大key造成的卡顿。日常习惯可以逐步改成删除大对象一律UNLINK。5.3 过期时间被覆盖、缓存集体失效的坑很多人写缓存时用两种方式设过期时间方式一SET cache:key value EXPIRE cache:key 600方式二SETEX cache:key 600 value方式二比方式一好因为原子。但方式二的坑在于如果你对同一个key重复SETEX过期时间会被重置成新的值。这在有些场景下是“续期”但有些场景下会让key永远不过期形成长期缓存。举个例子缓存设计成10分钟过期但热点key每5分钟就会被重新写入一次于是它的过期时间一直被重置永远不会被淘汰。如果业务逻辑依赖“10分钟不活跃就移除”的机制这种写法就完全失效了。更隐蔽的坑是用SET key newValue覆盖旧值时如果没有加KEEPTTL原来的TTL会被清掉key会变成永久的。这会导致本来应该过期的缓存变成长久缓存直到内存被塞满触发淘汰。所以覆盖已有key时一定要想清楚要不要保留TTL需要就加KEEPTTL。5.4 工具链与调试建议可视化客户端、命令监控与性能自查最后说点工具向的。日常开发时一个趁手的Redis可视化客户端能帮你快速查看String的value长什么样排查序列化问题尤其方便。Manyou用Another Redis Desktop Manager免费开源或者Redis Insight都行主要用来看key的编码、TTL、value原始内容。命令行层面有两个实用技巧一个是MONITOR它能实时打印Redis收到的所有命令。线上实例慎用因为高流量下会刷屏且影响性能但开发环境用来抓bug非常高效。另一个是REDIS BENCHMARK压测工具。如果你想验证某个String命令的QPS比如SET和INCR的极限可以跑redis-benchmark -t set,get,incr -n 100000 -q实测下来在本地环境单纯跑SET能到10万 QPSINCR也能到接近的水平。不过这只是单机理想值线上受网络、持久化、慢查询等因素影响会低不少。排查慢命令时还可以用SLOWLOG GET看看最近慢查询如果某个大key的GET出现在慢日志里那就更验证了前面说的大Key问题。写在最后的实际操作体会我自己的经验是String用得好不好往往不是知不知道命令的问题而是有没有形成一套“操作直觉”。比如看到要存Session第一反应是SET session:{id} {json} EX {time}而不是拆成两步看到要扣库存第一反应是DECR后判断返回值而不是先GET再算再写看到要加锁第一反应是SET NX PX加唯一标识、Lua脚本释放而不是自己用SETNX加EXPIRE写两行。最后再分享一个我常用的“小动作”写代码时给所有Redis key的使用处统一封装一层key的拼接、序列化、异常兜底都收口到一个工具类里。这样万一key格式要变、序列化方式要调整改动只在一处不用到处找。String类型虽然基础但它承载了大多数Redis项目中最多的读写流量值得你用最认真的态度去设计它的key规范和缓存策略。下一课开始讲Hash你会发现有了String的基础很多设计思路都是相通的。
Redis String类型全解析：从命令操作到SDS原理与实战应用
从前面两课走过来环境搭好了基本操作也有数了这一课终于要碰Redis里最“万能”也最容易被人低估的类型——String。说它万能是因为缓存、计数、分布式锁、共享Session、对象序列化存储随便拎一个出来都离不开它说它容易低估是因为很多人对它的理解停在SET/GET两个命令上觉得没什么可学的。实际上String背后牵着SDS结构、编码类型切换、原子操作、位图计算这些东西面试能问出一长串线上出问题排查时也总能撞到它。这一课就把它掰开揉碎从命令到原理到实战一次讲透。如果你是刚接触Redis的新手这一课能让你把String的所有核心用法一次掌握如果你已经写了一阵子Redis这一课里关于内部机制、编码切换、踩坑实录的部分大概率能帮你解释不少之前“为什么这样做就报错”的疑惑。废话不多说直接开始。1. String类型在Redis中的地位与核心特性1.1 为什么几乎所有业务都绕不开StringRedis一共提供五大基础类型——String、Hash、List、Set、ZSet但你要是在生产环境里翻一圈key会发现String类型占了绝大多数。原因很简单它足够简单、足够快又能覆盖大量业务场景。简单到什么程度一个key对应一个valuevalue可以是一个字符串、一个数字、一段JSON甚至是一张图片的二进制内容。但你别看它“只是存字符串”它背后是一套完整的动态字符串结构Redis对String的每次读写都是在内存里直接操作配合单线程事件循环吞吐量能做到非常夸张的水平。举几个最常见的例子Web应用的Session信息很多团队直接用SET session:{userId} {json} EX 3600存接口热点数据比如首页Banner、商品详情序列化成JSON后直接塞进String库存、浏览量、点赞数全量用INCR/DECR处理根本不用走数据库分布式锁里最朴素的实现也是String的SET NX EX组合。可以说String就是Redis这座魔法学院里的“基础咒语”不会用它后面学Hash和List也会觉得别扭把它吃透了后面看其他类型的源码和设计思路都会顺畅很多。1.2 String的三大特性动态字符串、二进制安全、原子性要真正理解String先记住这三个关键词。动态字符串SDS。Redis的String底层不是直接用C语言自带的char*而是自己封装了一个结构体叫SDSSimple Dynamic String简单动态字符串。它会在结构体里记录字符串的长度和剩余空间这就让它能动态扩容、能提前分配内存空间、能在缩短字符串时不必立刻释放内存。这一点在后面的“内部机制”部分我会展开细说这里你先有个印象Redis的String是“有长度、有容量管理”的高阶字符串不是裸的字节数组。二进制安全。这点很关键。C语言的字符串用\0表示结尾如果你往里面塞二进制数据只要中间出现\0数据就会被截断。但Redis的SDS通过“单独记录长度”的方式存储内容里即使有\0也不影响读取。这意味着你可以往String里放图片、放压缩包、放序列化后的对象Redis根本不关心你存的是什么它只负责把这一堆字节原样存进去、再原样取出来。原子性。Redis是单线程执行命令的所以String的INCR、DECR、SETNX这类操作天然就是原子的。不需要加锁也不会有并发竞争问题。这个特性是实现分布式锁、计数器、限流器的基础可以说“原子性”是String能玩出花来的根本原因。1.3 很容易被误会的“String只能存文本”我在面试里经常问一个问题String的value最大能存多大很多人都能回答512MB但你再追问一句“能存什么”回答就参差不齐了。String的value不是只能存纯文本。它本质是一个“字节容器”你可以往里面放普通字符串比如hello数字比如10086可以直接参与INCRBY运算JSON、XML等序列化后的文本二进制数据比如图片压缩包甚至加密后的字节流。这就引出一个非常实用的结论String其实是你手中最灵活的“管道”任何能被序列化成字节的东西都可以塞进去。但正因为它太灵活也容易用出问题。比如有人把一个几十MB的图片直接塞进Redis虽然Redis能存但会带来内存暴涨、网络传输变慢、大key阻塞等连锁问题。这个我们留到“常见问题”部分专门讲。2. String命令全景图谱从入门到进阶2.1 基础命令SET、GET、DEL、EXISTS这组命令是String的根本几乎所有业务代码都在用。但很多人只用了最基础的写法实际上SET命令的参数丰富到可以单独撑起一个分布式锁方案。先看最基础的127.0.0.1:6379 SET user:1 zhangsan OK 127.0.0.1:6379 GET user:1 zhangsan 127.0.0.1:6379 EXISTS user:1 (integer) 1 127.0.0.1:6379 DEL user:1 (integer) 1 127.0.0.1:6379 GET user:1 (nil)这里没有太多可说的但注意两点DEL返回的是删除成功的数量key不存在时返回0GET在key不存在或已过期时返回nil而不是空字符串。很多刚接触Redis的人会混淆nil和空串在代码里就容易出现判断错误。再看SET的进阶用法# 带过期时间单位是秒 SET user:1 zhangsan EX 3600 # 带过期时间单位是毫秒 SET user:1 zhangsan PX 3600000 # 只有key不存在时才设置常用于分布式锁 SET user:1 zhangsan NX # 只有key存在时才设置常用于更新 SET user:1 zhangsan XX # 组合使用 SET lock:order:1001 requestId NX PX 30000 # 保持原有TTL不被覆盖 SET user:1 newValue KEEPTTL这里的EX、PX、NX、XX、KEEPTTL是5.0以后Redis力推的原子化参数。为什么Redis官方允许在SET命令里塞这么多参数本质上是为了解决“多个命令组合执行时的非原子问题”。举个例子以前很多人写缓存是分两步先SET key value再EXPIRE key 3600。如果是单线程执行环境还好一旦有并发请求这两步之间存在时间窗口可能导致key一直不过期形成永久缓存。而SET key value EX 3600是一条命令从写入那一刻起就带上了过期时间整个操作是原子的。这组命令设计者还给了一个很贴心的KEEPTTL它在覆盖已有key的value时不会把原来的过期时间抹掉。这在缓存续期场景里非常有用——比如你只想更新内容不想重置TTL直接SET key newValue KEEPTTL就解决了。2.2 数值运算命令INCR、DECR与INCRBY家族String虽然是“字符串”类型但它能把value当成数字来运算。这就是计数器场景的基础设施。# 设置初始值 SET article:read:1001 0 # 自增1如果key不存在会自动从0开始 INCR article:read:1001 (integer) 1 # 自增指定步长 INCRBY article:read:1001 10 (integer) 11 # 自减 DECR article:read:1001 (integer) 10 DECRBY article:read:1001 5 (integer) 5 # 浮点数自增 SET article:score:1001 3.5 INCRBYFLOAT article:score:1001 0.5 4这里要特别提醒新手INCR命令要求value本身是一个能转成64位有符号整数的十进制字符串。如果value是abc或者3.14执行INCR会直接报错127.0.0.1:6379 SET name hello OK 127.0.0.1:6379 INCR name (error) ERR value is not an integer or out of range这个报错在开发中太常见了尤其是用框架自动序列化时value被包装成\100\这种带引号的JSON字符串一执行INCR就炸。后面常见问题部分我会专门说这个坑。另外一个容易忽略的细节INCRBYFLOAT虽然能做浮点运算但它不能保证精度。如果业务涉及金额计算还是得在应用层用专门的精度类型处理不要依赖Redis的浮点命令。2.3 字符串操作与位图命令APPEND、GETRANGE、SETRANGE与BIT家族这一组命令在日常业务里不常出现在CRUD代码中但在特定场景下特别好用。APPEND是在字符串末尾追加内容返回追加后的总长度127.0.0.1:6379 SET log:2026-06-01 start OK 127.0.0.1:6379 APPEND log:2026-06-01 - timeout (integer) 14 127.0.0.1:6379 GET log:2026-06-01 start - timeoutGETRANGE和SETRANGE用来做局部读取和覆盖。比如你存了一个很长的文本只想取前100个字符GETRANGE key 0 99就行。SETRANGE可以从指定偏移量覆盖内容有种操作字节数组的味道。位图命令则是String的隐藏大招。Redis的String底层是一串字节你可以把这串字节当成一个个bit来操作。# 设置第100个bit为1 SETBIT user:sign:20260601 100 1 # 获取第100个bit GETBIT user:sign:20260601 100 # 统计bit为1的数量 BITCOUNT user:sign:20260601位图最经典的应用就是用户签到。一年365天用365个bit就能表示一个用户全年的签到状态全部存储空间不到50字节。你要是把签到记录存成普通的String日期列表光存储成本就不知道高到哪里去了。命令这么多但实际用的时候不要把精力花在背命令上。我的建议是先精通SET/GET/INCR/DEL/EXISTS这类“日常五件套”再熟悉SETNX/EX/SETEX这类带附加参数的写法位图和GETRANGE这类属于“查文档就能用”的扩展能力用到时再翻也不迟。3. 五大高频应用场景深度拆解3.1 缓存场景Session共享、热点数据、短暂空值缓存String用得最多的场景肯定是缓存。但缓存也分很多种写法不是随便SET key value就完事的。Session共享。传统单体应用Session存在应用服务器内存里一旦部署多台机器用户请求落到不同机器就找不到Session了。用Redis String存Session是经典的解决方案登录成功后生成一个token以session:{token}为key把用户信息序列化成JSON存进去设置比如30分钟的过期时间。每次请求进来从Header里取token再GET一次Redis。这样无论请求落到哪台机器都能拿到同一份会话数据。热点数据缓存。比如商品详情页的数据数据库里可能几百毫秒才查出来但每天被访问几万次。这种数据很适合用String缓存。写法也很直白# 查缓存 GET product:detail:1001 # 如果缓存未命中查数据库然后写缓存 SET product:detail:1001 {json} EX 600但要注意缓存“穿透”问题往往就在这个流程里发生。所谓穿透是指一个请求查Redis没有、查数据库也没有由于没有数据可以缓存这个请求每次都会打到数据库。解决方案之一就是“空值缓存”——即使数据库没查到也写一个空对象到Redis并设置较短的过期时间比如60秒SET product:detail:999999 {} EX 60这样下次同样的请求来了Redis直接返回空对象数据库就躲过一劫。String在这里的灵活性体现得很明显value可以是任何东西哪怕是一个空JSON。热点key集中过期。还有一种场景是大量key设置了同一个过期时间到点后集体失效数据库瞬间被打爆。这被称为“缓存雪崩”。解决思路之一是在过期时间上增加随机数比如EX 600 random(0, 60)把失效时间打散。这个技巧在String缓存场景里非常实用建议直接形成习惯。3.2 计数器场景库存、限流、点赞、频控String的INCR/DECR是天然高性能计数器而且由于单线程和原子性不会出现超卖问题。库存扣减是典型场景。秒杀前先把库存加载到RedisSET stock:seckill:1001 100用户秒杀时执行DECR stock:seckill:1001DECR返回的值如果大于等于0说明扣减成功如果返回负数说明库存已扣尽需要补偿回滚。注意这里的逻辑是先扣减再根据结果判断是否要回滚而不是先判断再扣减因为先判断再扣减会存在并发窗口。访问次数限制/接口防刷也可以用String实现。比如限制某个用户一分钟最多访问10次SET rate:user:1001 1 EX 60 NX INCR rate:user:1001逻辑是key不存在时先初始化成1并设置60秒过期后续每次请求都执行INCR拿到返回值如果大于10就拒绝服务。这里SET ... NX EX保证了“初始化过期时间”是原子的不会出现初始化了但没有过期时间的bug。滑动窗口限流可以配合EXPIRE实现一个粗糙版本更精确的滑动窗口要借助ZSet但很多业务场景用固定窗口也已经能解决问题不用一味追求复杂。这个场景在现在的“agent应用”里也很常见智能体应用要统计某个用户的调用次数、累计token数或者做多轮会话的频控底层很多都是String计数器。比如每个会话维护一个agent:usage:{sessionId}每次调用INCRBY累加token消耗接近限额时自动截断。String在这类轻量统计场景里真的非常顺手。3.3 分布式锁SET NX PX、Lua脚本与误删问题分布式锁是String类型最“值钱”的场景之一也是面试高频题。最朴素的分布式锁实现其实就是一条命令SET lock:order:1001 requestId-123 NX PX 30000NX保证只有key不存在时才能设置成功相当于“加锁”PX 30000设置锁的自动过期时间防止持有锁的进程宕机后死锁value用requestId这样的唯一标识用来确认“这把锁是我的”。释放锁时不能直接DEL否则可能出现误删别人锁的问题。典型场景线程A拿到锁执行时间太长锁自动过期了线程B拿到锁线程A执行完毕直接DEL把线程B的锁给删了。所以释放锁时要先判断value是否还是自己的再删除。这个过程用Lua脚本保证原子if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end把这段脚本用EVAL执行就是业界公认的“安全释放锁”方案。当然Redis分布式锁并不完美在极端场景下主节点宕机、锁数据未同步到从节点仍可能丢失所以大型系统会引入Redlock或者更强的共识方案。但对于绝大多数中小团队的日常业务SET NX PX Lua释放锁已经够用了。3.4 其他实用场景全局ID、位图签到、对象存储除了上面三个大场景String还有一些很值得知道的用法。全局ID生成。数据库自增ID在分库分表后会冲突用Redis的INCR生成全局唯一ID是常见方案INCR global:id:order (integer) 10001注意这个ID不是严格的“趋势递增”也关系不大关键是要唯一。可以配合日期作为前缀生成类似202606010000001的订单号。位图存储。用户签到、在线状态、打卡记录这类布尔型数据用位图做最省内存。一个月用31个bit每天SETBIT user:sign:1001 day 1要统计这个月签到了几天直接BITCOUNT user:sign:1001。对象序列化存储。把整个对象序列化成JSON或protobuf塞进String这种做法虽然简单但有两点要注意。一是序列化后体积会膨胀比如一个Java对象被Jackson序列化后字段名、类型信息全都会带上原本几百字节的数据可能变成几KB二是如果对象有嵌套结构且需要频繁修改其中某个字段String反序列化后修改再整体写回效率远不如直接用Hash类型操作子字段。4. String类型的内部机制SDS与编码转换4.1 SDS结构设计为什么Redis不用C字符串Redis之所以要自己实现SDS是因为C语言原生字符串有几个硬伤第一C字符串获取长度必须遍历时间复杂度O(n)SDS在结构体里直接记录len获取长度O(1)。第二C字符串拼接时如果忘记分配内存容易缓冲区溢出SDS会在追加内容前检查剩余空间不够就扩容。第三C字符串中间不能有\0SDS以len为准二进制安全。SDS的结构大致长这样以Redis 3.2之后的版本为例struct sdshdr64 { uint64_t len; // 已使用长度 uint64_t alloc; // 分配的总容量 unsigned char flags; // 头部类型标记 char buf[]; // 字节数组 };len记录已经使用的字节数alloc记录总共分配了多少空间两者之差就是可以继续追加的“预分配空间”。之所以要预留空间是因为如果每次APPEND都重新分配内存频繁的系统调用会极大拖慢性能。SDS扩容遵循一套策略如果修改后总长度小于1MB就分配和len一样多的额外空间也就是len len 1如果修改后总长度大于等于1MB则额外分配1MB。这种“空间预分配”策略保证了一个String从创建到多次追加的过程中内存重分配次数降到很低。这也是为什么你频繁APPEND一个key时Redis不至于性能骤降的原因。4.2 三种编码类型int、embstr、rawString在Redis内部会根据value的实际情况选择不同的编码方式这直接决定了内存占用和操作效率。用OBJECT ENCODING key可以查看某个key的编码。int编码。当value是可以用8字节长整型表示的数字时String直接用整数存储不做字符串解析。比如SET num 100num的编码就是int。此时INCR/DECR直接在整数上运算性能极高。embstr编码。当value是短字符串且长度不超过44字节时Redis把SDS结构体和字符串内容分配在一次连续内存里。这样内存碎片少读写效率高。通常你SET name helloname的编码就是embstr。raw编码。当字符串长度超过44字节或者经过某些修改操作导致SDS结构需要重新分配时编码会切换成raw。raw编码下SDS结构体和buf数组分两次分配性能略低于embstr但能应对更长内容。44这个阈值的来历Redis 3.2之前是39字节3.2之后把SDS头类型细分后embstr最多能容纳44字节的数据。你可以自己验证127.0.0.1:6379 SET a 12345678901234567890123456789012345678901234 OK 127.0.0.1:6379 STRLEN a (integer) 44 127.0.0.1:6379 OBJECT ENCODING a embstr 127.0.0.1:6379 SET b 123456789012345678901234567890123456789012345 OK 127.0.0.1:6379 STRLEN b (integer) 45 127.0.0.1:6379 OBJECT ENCODING b raw注意一个特例即使value是数字如果你用了APPEND、SETRANGE这类字符串操作编码可能会从int变成raw或embstr并且不再是纯数字。这会影响后续的INCR操作。下面这个序列就能复现127.0.0.1:6379 SET num 100 OK 127.0.0.1:6379 APPEND num abc (integer) 6 127.0.0.1:6379 GET num 100abc 127.0.0.1:6379 INCR num (error) ERR value is not an integer or out of range所以业务上不要把同一个key既当计数器又当字符串拼接对象两种操作混用很容易出问题。4.3 内存优化与序列化注意事项String用多了以后内存会悄悄膨胀这里面有两个常见原因。第一个是小对象太多。Redis本身的key和value都有元数据开销一个几字节的value实际占用的内存可能有好几十字节因为每个对象头、SDS头、字典节点都要占内存。如果你有几十万个细小的key内存消耗会非常可观。这种情况可以考虑用Hash把多个字段整合到一起用Hash比存几十万个String能省下一大截内存因为Hash的底层有自己的压缩策略。第二个是序列化后体积膨胀。用Jackson/Gson把Java对象序列化成JSON字段名带引号、类型信息全部保留原本内存里可能不到1KB的对象序列化后变成几KB甚至更大。要优化可以做好几步一是用更紧凑的序列化协议比如protobuf、MessagePack二是对大JSON做压缩Redis本身就支持压缩数据但前提是你能承受压缩解压的CPU开销三是考虑结构拆分不要把一个巨大的对象全塞进一个key能拆成多个Hash的就拆。这些优化在Redis数据量小的阶段感觉不到一旦内存接近上限maxmemory触发淘汰策略淘汰谁、怎么淘汰就变成线上问题了。建议在架构设计早期就给String对象的体量留个上限别等到内存爆了才去治理。5. 常见问题与排查技巧实录5.1 INCR报错“not integer or out of range”的完整排查思路这个报错我在Redis相关的问题答疑里见过太多次了尤其在使用Spring Data Redis或者各种框架封装后特别容易踩。先看最直接的原因执行INCR/DECR/INCRBY时value不是合法的64位有符号整数。可能是以下几种情况内容本身不是数字比如abc内容超过了Long.MAX_VALUE9223372036854775807内容看起来是数字但被序列化成带引号的字符串。比如Redis Desktop Manager里看到值是100注意这个值是带双引号的它其实是JSON序列化后的字符串而不是纯数字100。用INCR必然会报错。排查步骤很简单# 查看当前值长什么样 GET rate:user:1001 # 查看value的数据类型 TYPE rate:user:1001 # 查看内部编码 OBJECT ENCODING rate:user:1001如果TYPE返回stringOBJECT ENCODING返回的却既不是int也不是embstr且GET的值一眼看去有引号那基本可以确定是序列化导致的问题。解决方案也根据原因来定如果是代码里用Jackson等库对value做了序列化导致写入的是100那么要在写入端去掉序列化直接把数值作为字符串写入如果是框架自动做的序列化可以把对应字段的类型改成String或者数值类型让它在Redis里存成纯数字如果已经积累了脏数据只能重新写入或者用一个新key。这种问题最麻烦的地方在于“看起来正常、一执行就报错”所以排查时永远先GET一下看看value的真实样子别急着查代码。5.2 大Key隐患超过1MB的String就该警惕String虽然能存512MB但你实际使用中超过1MB就得仔细想想了。大Key带来的问题有三个阻塞风险Redis是单线程GET一个几百MB的key会把整条网络链路拖慢其他请求排队等着网络风暴大key在高并发下反复读写流量翻倍地消耗带宽删除阻塞删除一个大key时释放内存也可能造成阻塞尤其在DEL时。发现大Key很简单redis-cli --bigkeys这个命令会扫描整个实例输出每种类型里最大的几个key。如果是线上实例建议在低峰期执行因为扫描本身会有一定性能开销。治理大Key的思路也很清晰把大对象拆成多个小对象比如一个巨大的文本拆成多个分段key对value做压缩减少体积删除时不要直接DEL用UNLINK异步删除来避免阻塞。UNLINK是Redis 4.0引入的它会先把key从字典中摘除然后在后台线程慢慢释放内存能有效避免DEL大key造成的卡顿。日常习惯可以逐步改成删除大对象一律UNLINK。5.3 过期时间被覆盖、缓存集体失效的坑很多人写缓存时用两种方式设过期时间方式一SET cache:key value EXPIRE cache:key 600方式二SETEX cache:key 600 value方式二比方式一好因为原子。但方式二的坑在于如果你对同一个key重复SETEX过期时间会被重置成新的值。这在有些场景下是“续期”但有些场景下会让key永远不过期形成长期缓存。举个例子缓存设计成10分钟过期但热点key每5分钟就会被重新写入一次于是它的过期时间一直被重置永远不会被淘汰。如果业务逻辑依赖“10分钟不活跃就移除”的机制这种写法就完全失效了。更隐蔽的坑是用SET key newValue覆盖旧值时如果没有加KEEPTTL原来的TTL会被清掉key会变成永久的。这会导致本来应该过期的缓存变成长久缓存直到内存被塞满触发淘汰。所以覆盖已有key时一定要想清楚要不要保留TTL需要就加KEEPTTL。5.4 工具链与调试建议可视化客户端、命令监控与性能自查最后说点工具向的。日常开发时一个趁手的Redis可视化客户端能帮你快速查看String的value长什么样排查序列化问题尤其方便。Manyou用Another Redis Desktop Manager免费开源或者Redis Insight都行主要用来看key的编码、TTL、value原始内容。命令行层面有两个实用技巧一个是MONITOR它能实时打印Redis收到的所有命令。线上实例慎用因为高流量下会刷屏且影响性能但开发环境用来抓bug非常高效。另一个是REDIS BENCHMARK压测工具。如果你想验证某个String命令的QPS比如SET和INCR的极限可以跑redis-benchmark -t set,get,incr -n 100000 -q实测下来在本地环境单纯跑SET能到10万 QPSINCR也能到接近的水平。不过这只是单机理想值线上受网络、持久化、慢查询等因素影响会低不少。排查慢命令时还可以用SLOWLOG GET看看最近慢查询如果某个大key的GET出现在慢日志里那就更验证了前面说的大Key问题。写在最后的实际操作体会我自己的经验是String用得好不好往往不是知不知道命令的问题而是有没有形成一套“操作直觉”。比如看到要存Session第一反应是SET session:{id} {json} EX {time}而不是拆成两步看到要扣库存第一反应是DECR后判断返回值而不是先GET再算再写看到要加锁第一反应是SET NX PX加唯一标识、Lua脚本释放而不是自己用SETNX加EXPIRE写两行。最后再分享一个我常用的“小动作”写代码时给所有Redis key的使用处统一封装一层key的拼接、序列化、异常兜底都收口到一个工具类里。这样万一key格式要变、序列化方式要调整改动只在一处不用到处找。String类型虽然基础但它承载了大多数Redis项目中最多的读写流量值得你用最认真的态度去设计它的key规范和缓存策略。下一课开始讲Hash你会发现有了String的基础很多设计思路都是相通的。