1. 先把Strings的命令全景焊进脑子里Redis里最常见的类型就是Strings但很多教程只讲到SET和GET就停了后面那些“难得不好记”的命令靠临时翻文档。我比较推荐换一个思路不需要死记命令表而是按业务诉求把命令归成几个组。Strings的命令看着多其实分组之后逻辑非常完整跟业务场景一一对应用的时候自然就想起来了。我平时习惯分成下面这五组分组核心命令典型场景基础读写SET、GET、MSET、MGET缓存读写、取值、批量查询条件写与过期控制SETNX、SETEX、PSETEX、SET NX/XX/EX/PX/KEEPTTL、GETDEL、GETEX分布式锁、带过期时间的缓存、一次性令牌数值原子操作INCR、DECR、INCRBY、DECRBY、INCRBYFLOAT计数器、限流、库存扣减字符串操作APPEND、STRLEN、SETRANGE、GETRANGE局部修改、拼接、截取位运算SETBIT、GETBIT、BITCOUNT、BITPOS、BITOP签到、在线状态、活跃统计这也是我这篇内容的组织方式。先会命令再看底层存储结构最后回到真实业务里去想“这条命令到底带来了什么”。1.1 基础读写SET、GET、MSET、MGET不止表面那么简单先说最基础的SET。很多人用SET就是SET key value其实它的完整语法是这样的SET key value [NX | XX] [GET] [EX seconds | PX milliseconds | EXAT unix-time-seconds | PXAT unix-time-milliseconds | KEEPTTL]NX只在key不存在时写入XX只在key已存在时写入EX/PX设置过期时间分别以秒和毫秒为单位EXAT/PXAT指定某个时间戳过期KEEPTTL写入时保留原有过期时间GET返回旧值如果key不存在返回空为什么这个语法重要因为很多旧教程让你分两步走先SET再EXPIRE。这样有两个问题。第一是多余的一次网络往返第二个更致命——如果两条命令之间进程崩了key就成了永久key你原本想要的“自动过期”直接失效。所以写新代码的时候尽量把过期时间一起塞进SET能原子地办完就原子地办完。GET本身没什么好说的但它有个隐藏细节同一个key如果存储的是二进制安全数据照样可以用GET原样取回。Redis的字符串不关心你存的是普通文本、JSON序列化结果、图片的二进制还是压缩后的对象只要能塞进字节数组它一视同仁。MSET和MGET适合一次操作多个key。比如页面要同时展示用户名、头像地址、用户等级三个字段分别存了三个key用MGET一次拿回来比循环GET省太多网络开销。需要注意两点MSET是原子的要么全部写入要么全部不写适合需要同时保证多个key状态的场景。MGET不是原子的它只是一个批量读取工具如果业务要求这多个key必须处于同一个逻辑时刻那MGET是保证不了的只能靠版本号或者Lua自行判断。我自己的习惯是凡是批量读优先MGET凡是批量写优先MSET再用pipeline补充那种“不同命令交错执行”的批次操作。1.2 条件写与过期控制SETNX、SETEX和SET的扩展选项先说SETNX它的语义是“SET if Not exist”只在key不存在时赋值。老版本里SETNX是单独的指令很多人在锁场景里直接SETNX lock 1然后忘了设过期时间holder进程一挂锁就永远解不开了。这也是为什么后来官方推荐直接用SET key value NX PX 30000这种组合一条命令完成“不存在才写”和“带上过期时间”。SETEX和PSETEX是“设置值过期时间”的专用指令区别只在时间单位一个是秒一个是毫秒。它们内部其实就是SET的EX/PX语义单独存在的意义主要是兼容老代码和让意图更直白。GETDEL是在Redis 6.2之后加入的命令取走值的同时直接删除key适合一次性消费的令牌、验证码、券码。用过之后如果还想留着就用GETEX取出值同时可以顺带修改key的过期时间甚至用PERSIST选项去掉过期时间让它变成永久key。有些场景里我们需要拿到旧值再写入新值老派的做法是WATCHMULTI或者直接Lua。其实Redis还有个GETSET命令它获取旧值然后无条件写入新值。注意GETSET本身不是原子的CAS它只是个“读旧写新”指令。想要“只有值没变才更新”还是得配合Lua或WATCH机制来做。1.3 数值原子操作INCR家族撑起高并发计数一个常见的误解是Redis做计数器不就是GET出来在应用层加1再SET回去吗这么做在低并发下没问题但一旦流量上来两个线程同时读到一个值先后写回就丢了一次更新。Strings里的INCR、DECR、INCRBY、DECRBY就是为了解决这个问题的。它们的核心逻辑是原子的。因为Redis核心处理模型是单线程事件循环一条命令在执行期间不会被其它命令插入所以INCR key从“读旧值、加1、写回”整个过程可以看成不可分割的。在应用层你不需要加锁也不需要CAS循环直接一条INCR就完事。我在实际项目里常用它做这几件事未读数、点赞数、评论数这类只增不减的指标限流场景的窗口计数比如每分钟最多1000次请求每次进来INCR超过阈值就拒绝库存扣减配合DECRBY判断返回值是否小于0来确认是否超卖有一个边界必须提一下INCR只支持64位有符号整数。如果当前值已经是9223372036854775807再INCR就会报错“increment or decrement would overflow”。如果key里存的值本身不是整数表示比如SET n 1.5INCR也会直接报错。此时你得用INCRBYFLOAT但要注意浮点数累计会有精度漂移对精度敏感的数据我建议别在Redis里算浮点要么放大成整数要么在应用层用高精度库算。还有一层和存储结构有关当一个key被INCR之后它的底层编码通常是int。int编码不仅占用内存极小而且运算效率高。如果你把一个数字存成了字符串001那INCR会直接报错这类“看起来像数字但不是规范整数”的写法在业务里很容易埋雷我后面会再展开。1.4 字符串拼接与裁剪APPEND、STRLEN、SETRANGE、GETRANGEAPPEND是在原字符串后面追加如果key不存在就等价于SET。STRLEN返回字符串的字节长度注意不是字符长度。比如一个中文汉字UTF-8编码占3个字节用STRLEN数出来就是3倍于汉字个数。如果业务需要按字符数处理就得在应用层解码。GETRANGE可以用来截取字符串区间end传-1表示取到末尾。SETRANGE则是从指定偏移量覆盖内容。SETRANGE有个比较特别的点如果偏移量超过了当前字符串长度中间的空档会用\x00填充等于强制把字符串拉长。如果你不小心设置了一个很大的offset那内存会瞬间上升还可能构造出大key。这里有个场景很有意思以前做业务日志或者长文本存储时有的人喜欢不停APPEND。但我要提醒一句Strings每次APPEND都要走SDS的增长逻辑如果追加次数非常多、字符串非常大扩容时的内存拷贝成本不可忽视。频繁的尾部追加如果量很大我更倾向于换成List的RPUSH或者独立设计日志结构让每个条目成为独立的元素而不是在同一个字符串上反复增长。1.5 位操作用最少的内存做海量状态Strings在底层就是字节数组所以天然可以当位图用。你不需要额外的数据结构直接SETBIT、GETBIT、BITCOUNT就能做大量布尔状态统计。典型的例子是用户签到。给每个用户分配一个key把每一天映射到位偏移一年用365个bit约46字节。一亿个用户一年的签到数据换算下来大概4.6GB这是相当可观的空间节省。而传统关系型数据库存一亿行签到记录光主键和索引就够喝一壶。再比如在线状态统计。把用户ID映射到bit位登录置1离线置0然后用BITCOUNT统计在线人数要统计两个业务线之间的共同活跃用户直接BITOP AND两个位图结果位图里为1的就是交集用户。BITOP支持AND、OR、XOR、NOT四种操作可以当成“内存里的位级集合运算”。位图的底层还是字符串所以同样受512MB大小限制。需要注意的隐患是不要对着一个特别大的偏移位直接写。比如SETBIT user:online 4294967295 1虽然命令合法但会把字符串一下撑到512MB立刻成为一个大key。出现这种操作基本都是用户ID映射逻辑出了问题排查时要格外小心。2. 存储结构SDS与三种编码方式理解了命令就该看命令背后的数据结构了。Strings值在Redis内部不是直接用C语言原生的char[]而是用了一种叫SDSSimple Dynamic String的结构。搞清楚SDS你对“为什么Strings能存二进制”“为什么有些key占内存特别小”“为什么某些操作突然变慢”都会有一个底层解释。2.1 为什么Redis要自己实现字符串结构C语言的字符串用char[]表示以\0结尾。这个设计有两个硬伤。第一个是取长度必须遍历整个数组复杂度是O(n)如果字符串是几MB大小每次STRLEN都要扫一遍完全不可接受。第二个是不二进制安全因为\0被当成终止符一旦字符串内部包含\0后面内容就全丢了。Redis作为一个通用存储既要存普通文本也要存序列化对象、图片、压缩数据这些二进制内容里出现\0太正常了。所以它必须用一种“长度记录在头部、内部不做截断”的结构。于是就有了SDS头部保存长度的信息内容区可以包含任意字节。除此之外SDS还解决了一个常见问题缓冲区溢出。C语言对字符串拼接时如果目标空间不够就会直接覆盖后面的内存区域可能出现很难查的脏数据。SDS在修改前会检查剩余空间不够就扩容保证操作安全。2.2 SDS分级头设计到底省了什么老版本的SDS结构非常简单就三个字段struct sdshdr { unsigned int len; // 已使用长度 unsigned int free; // 未使用长度 char buf[]; // 字节数组 };问题在哪儿呢就算你存的字符串是alen和free这两个字段也各占4字节加上buf结束符额外的头开销至少有8字节。现实中一个Redis实例里短字符串key非常多这个头开销放大到千万级后就是很大的内存浪费。所以Redis 3.2之后引入了分级SDS头根据字符串长度选择不同的头类型类型len字段alloc字段支持最大长度头部大小sdshdr5无独立字段无31字节1字节sdshdr8uint8_tuint8_t255字节3字节sdshdr16uint16_tuint16_t65535字节5字节sdshdr32uint32_tuint32_t4GB9字节sdshdr64uint64_tuint64_t2^6417字节其中sdshdr5比较特殊它本身没有单独的len和alloc字段而是在flags字节的高5位里存长度所以它只适合长度小于32的短字符串。一旦你要对sdshdr5做追加或者扩容它就得升级成sdshdr8。这个分级的收益很大大量的短key不再需要固定的8字节头而是一个3字节甚至1字节的头就够了。整个实例内存的紧凑度会上一个台阶。2.3 int、embstr、raw三种编码方式SDS是字符串的存储结构但Redis在字符串对象之上还做了一层编码优化编码方式有三种通过OBJECT ENCODING key可以看到。第一种是int编码。当value可以被解析成64位有符号整数时Redis不会创建SDS而是直接把整数值塞进对象指针字段里。这意味着连一次内存分配都不用做一个字符串类型的key可能只占很干净的一个对象头内存省到极致。我们平时INCR出来的计数器绝大多数就是int编码。第二种是embstr编码。embstr的意思是embedded string它把redisObject和SDS结构体一次性分配在一块连续内存里创建和释放各只需要一次内存操作碎片也更少。这个连续分配的目标是尽量让整个对象塞进一个缓存行里。在Redis 3.2之后不超过44字节的短字符串会走embstr。为什么是44这个数因为redisObject固定16字节sdshdr8头是3字节再加上字符串结尾的\0占1字节441631正好等于64也就是一个缓存行的大小。老教程里如果写的是39你要知道那是3.2时代之前的事了当时旧的sds头有8字节168391同样等于64。embstr有个特点它是只读的类似不可变对象。一旦你尝试修改它比如APPEND或者SETRANGE它就会被转成raw编码。因为连续内存没法安全地动态扩容修改变量需要重新分配一大块空间干脆直接转成更灵活的raw。第三种是raw编码。当字符串长度超过44字节Redis会把redisObject和SDS分开分配SDS的头部按长度选择sdshdr8/16/32/64内容区也随时可以扩容。raw编码牺牲了一些小对象上的内存紧凑性换来了大对象的灵活性。2.4 编码切换与扩容机制int、embstr、raw之间的关系不是固定不变的Redis会在写入或修改时自动调整编码但要注意一点编码切换一般是单向劣化不容易反向恢复。举例来说127.0.0.1:6379 SET counter 1 OK 127.0.0.1:6379 OBJECT ENCODING counter int 127.0.0.1:6379 SET name tom OK 127.0.0.1:6379 OBJECT ENCODING name embstr继续在name后面追加字符把字符串长度推到45以上它会转成raw。raw编码之后就算你把这个值删掉重新写成短的Redis会重新创建一个新的短字符串对象可能又变回embstr但如果你只是在原key上收缩内容编码是不会自己降回来的。再看SDS的扩容机制。sdsMakeRoomFor在需要追加内容时如果当前剩余空间不够会预留一部分额外空间当新长度小于1MB时分配双倍容量当新长度大于等于1MB时每次只额外增加1MB。这样做的目的很直接——减少频繁重分配的次数。假如你要往字符串里追加100次数据如果每次都不预留空间那就要做100次realloc每次realloc还要拷贝旧数据时间开销非常难看。预留之后很多次追加可以直接落在尾部空闲空间里。还有一个反直觉的行为是“惰性空间释放”。SDS缩短时并不会立刻把多余的内存还给操作系统而是把长度改小、空间留着备用。所以如果你盯着MEMORY USAGE看可能会发现一个key删掉一部分内容之后内存并没有明显下降这不是Redis不怀好意而是它在等下一次追加。如果这段内存长期等不到重用那就只能算“有效浪费”。在批量写入大量短字符串、然后缩减的场景里内存暂高的现象并不少见。3. 业务场景里的命令组合打法命令拆完、底层也看完了现在回到业务里。Strings能承载非常多场景但每个场景选对命令组合才是关键填错一个选项就可能有坑。3.1 缓存读写与缓存击穿最常见的缓存逻辑就是读多写少的热点数据。简单做法就是GET先查查不到再读数据库回填SET。但如果某个热点key刚好过期大量请求同时发现缓存为空就会一起打到数据库上这就是缓存击穿。可以这么处理加一个互斥的写法只有第一个请求能拿到写缓存的权利。常见做法是SET cache_key 1 NX EX 10谁在key过期后第一个设置成功谁就去查数据库其它请求可以短暂等待或者直接返回旧缓存。这里要注意这个锁key和缓存key要分开设计别混用否则很容易出现“锁没释放导致缓存回填失败”的连锁问题。另一个细节是缓存写入最好统一带过期时间并且加入随机抖动。比如基础过期时间300秒再随机加0到30秒避免一批同时间创建的key同时过期让后端压力出现毛刺。3.2 计数器、限流与库存扣减计数器的玩法前面已经提到过但库存扣减值得单独拿出来说因为它不光拼原子性还拼“怎么判断扣多了”。简单做法是用DECRBY扣减库存返回值就是扣减之后剩的数量如果返回负数说明库存不够了。这时你有两种选择一种是允许库存变成负值后续再补偿另一种是事先用Lua判断够不够再扣保证任何时刻库存都不会被扣穿。我在库存场景更推荐Lua脚本因为DECRBY返回负数虽然能发现超卖但已经晚了用户那边看到“扣款成功结果库存负了”就很尴尬。Lua脚本是在服务端原子执行的两条命令之间不会插入其它命令所以可以这样写local stock tonumber(redis.call(GET, KEYS[1])) if stock and stock tonumber(ARGV[1]) then return redis.call(DECRBY, KEYS[1], ARGV[1]) else return -1 end需要注意Lua脚本里拿到的是一个字符串值必须用tonumber转成数字再比大小。这种脚本执行完返回给客户端的可能是扣减后的剩余库存业务侧要用返回值判断是否成功。限流也可以用Strings的INCR EXPIRE组合。比如单位时间窗口60秒限制100个请求每个请求进来先INCR如果是第一次就同时EXPIRE 60再看当前计数是否超过100超过则拒绝。这里有个边界第一次INCR和EXPIRE之间并不是原子的所以窗口的第一秒可能出现极端情况下过期时间没设上去导致计数器永久累积。严谨的做法是用Lua把INCR和EXPIRE包起来或者使用专门为限流设计的滑动窗口方案。3.3 分布式锁的获取与释放分布式锁的正确“获取”我前面提过就是一条SETSET lock:order:10086 random_value NX PX 30000random_value建议用UUID或者业务请求ID不能直接写死一个固定值因为释放锁的时候要靠它判断“这把锁是不是我的”。很多人栽在释放锁上。如果直接DEL key极端情况会出现线程A持有锁因为处理时间过长锁已经到期自动释放了线程B拿到锁此时线程A才处理完执行DEL把B的锁误删了。所以释放锁之前必须先判断value是不是自己存进去的那个再删除。这个“读取判断删除”两步不是原子的如果先GET再DEL中间也可能出岔子所以要用Luaif redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end用这个脚本当前线程就只能删除自己持有的锁别人拿到的锁不受影响。3.4 用位图实现用户签到和在线状态位图业务的写法和前面命令部分呼应。每个用户分配一个独立位图通常以天为粒度key命名类似sign:2025:user:001偏移量就是当天的序号。写签到用SETBIT查某天是否签到用GETBIT统计一个月的签到次数就用BITCOUNT。如果要做“连续签到N天”的查询需要把一段时间的位取出来逐个判断可以用GETRANGE把区间bit拉回应用层再循环判断。不过当数据规模很大的时候把大段位图拉到应用层会产生网络开销更合适的做法是在Redis里用BITCOUNT或者BITPOS先算出粗略结果再配合小范围拉取。在线状态更典型的是“全部用户一个位图用用户ID当偏移”。比如一个平台的日活统计每个用户ID对应一个bit登录就SETBIT online:20250101 user_id 1。要统计一天的DAU直接BITCOUNT。要算连续两天都在线的用户就用BITOP AND把两天的位图做交集再用BITCOUNT看结果。这个方案的常量是每天只需要1.25MB内存来容纳一千万用户对比存一千万条用户关系记录存储成本完全不在一个量级。4. Strings高频问题排查与经验沉淀到这一节我打算把平时排查Redis问题时最常碰到的几个Strings相关的坑聊透。这些经验比命令列表更难从官方文档里学到基本都是踩过之后记下来的。4.1 大Key的小心思慢查询、内存暴涨和阻塞Strings理论上能存512MB但“能存”和“该存”是两回事。大Value会带来三个连锁问题一是网络传输耗时暴增二是序列化和内存分配时阻塞事件循环三是容易造成集群环境下节点数据倾斜。排查大Key最直接的方式是Scan扫描redis-cli --bigkeys它会遍历所有key按类型给出最大key信息。如果只想精细看某一个key的占用可以用127.0.0.1:6379 MEMORY USAGE somekey (integer) 1048577这里返回的是Redis视角里这个key实际占用的字节数包括对象头、SDS头和数据区比通过STRLEN估算更准确。定位到大Key之后处理方案其实不复杂。如果是大字符串可以看业务能否拆成多个key比如用Hash的field存分片或者把大对象改成按业务维度拆分成多个小key再用MGET聚合。还要特别注意绝对不要在位图上随便写超大偏移否则一行周报都可能把一个key变成500MB洪水。4.2 编码转换不可逆带来的内存浪费很多人不理解为什么同一个key在变成大数据后再缩回去内存仍然很高。原因就在编码升级和SDS扩容之后内存不会立刻缩回来。举个例子某个key原本存了100MB的大字符串后来业务改成存100字节的小字符串。raw和原SDS的空间在删除重写之前并不会自动回收。如果你是原地修改比如SETRANGE覆盖后又截断那内存更是只涨不跌。所以这种场景下应该直接删掉key重建新值让Redis重新选择合适的编码。同理如果一个业务写入大量的小字符串Redis会自动选择embstr编码但一旦用过APPEND、SETRANGE等修改操作编码就会转成raw头开销变大。想要验证也不难反复执行OBJECT ENCODING和MEMORY USAGE对比修改前后的内存占用。日常开发里能在写入时就确定好的字段尽量一次性SET进去避免后续原地修改。4.3 过期与内存淘汰策略如何影响StringsStrings带过期时间的写法前面讲了很多但过期后key不会立刻从内存消失。Redis的过期删除是惰性删除周期删除双管齐下访问时发现过期就删后台也会周期扫描清理。所以如果你用INFO查看内存刚过期的key可能还占着地方。这个“短暂残留”本身是正常的设计问题在于如果业务上对“过期即释放”有强烈依赖那就得注意监测内存变化。还有一个相关点是淘汰策略。当内存达到maxmemory时如果配置的是allkeys-lru或allkeys-random之类策略Strings类型的大量短生命周期key可能是最早被淘汰的对象。设计缓存层时要对“缓存被逐出”有兜底逻辑不能假设只要设置了过期时间缓存就一定在。4.4 一个典型的并发扣减排查实录有一次我在某商品秒杀模块排查超卖问题当时的逻辑是先GET库存再在应用层判断是否大于0最后DECR。单机测试怎么跑都没问题一上线上就被流量打穿库存出现负数。定位过程其实很快两个请求同时GET到库存为1两个都在应用层判断通过然后先后DECR结果库存变成-1。这就是典型的“读-改-写”竞态。换成Lua脚本后判断和扣减放在Redis服务端原子执行负库存再也没出现过。那次的教训让我养成了一个习惯任何涉及“先判断再修改”的Strings操作要么用Lua要么拆成Redis原生的原子指令绝不在应用层拼两步。4.5 命令与参数的小抄笔记最后补一个零碎但实用的点。现在不少开发框架封装了Redis操作比如Spring Data Redis的ValueOperations很多人觉得直接调API就行不用记命令。但你迟早会遇到框架没封装的高级参数比如SET的NX/XX/GET组合、GETEX、BITFIELD。真到线上排查时你会花更多时间去想“框架这个API到底发了什么命令出去”。所以我建议每个用Redis的人在自己的笔记里留一份“Strings命令速查”记录命令名、关键参数、返回值和常见报错。不用太长重点是能让自己在新版本特性出现时快速对标。比如Redis 7.0给SET加上了GET选项以前要做“取旧值并写新值”还要用Lua现在一条SET就能拿回旧值这类新特性就是提升效率的点。5. 我给新手的几个实操建议讲到这里Strings的核心内容其实已经过完了。最后我再说几个从大量实践中沉淀出来的小建议算不上系统总结却是我认为最值得带走的经验。第一能用一条命令完成的绝不用两条。无论是SET带过期时间还是INCR/DECR做计数Redis的单线程模型让很多原子操作成为天然的正确解法。你少用一条命令不仅是省网络开销更是减少一个出错的中间态。第二遇到内存问题先看编码再看key大小。OBJECT ENCODING、MEMORY USAGE、DEBUG OBJECT这三个命令在高频问题的排查里价值极高。很多时候你以为“这个key很小”实际上是编码已经劣化成raw或者是SDS的惰性空间在作祟。第三不要把大数据量的JSON整个塞进一个String。虽然技术上没问题但更新一个字段就得全量读写性能很快会成为瓶颈。这种情况用Hash按字段拆才是更合理的数据建模。第四位图很有用但一定要在代码里写清楚offset的映射规则。我见过位图偏移计算错误造成用户数据错乱的事故这类问题在排查时几乎看不到直接报错只能靠对比逻辑推导非常痛苦。Strings这个类型上手容易精通难难就难在“底层结构”和“命令边界”需要同时理解。当你把SDS的分级头、int/embstr/raw编码切换、以及原子命令的语义都串起来以后很多表面上晦涩的线上问题会变得非常清晰。这也是我写Redis数据类型系列最想传递的东西不要只背命令要顺着“为什么”去理解它。
