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。
有些场景里，我们需要拿到旧值再写入新值，老派的做法是WATCH+MULTI，或者直接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.5，INCR也会直接报错。此时你得用INCRBYFLOAT，但要注意浮点数累计会有精度漂移，对精度敏感的数据，我建议别在Redis里算浮点，要么放大成整数，要么在应用层用高精度库算。
还有一层和存储结构有关：当一个key被INCR之后，它的底层编码通常是int。int编码不仅占用内存极小，而且运算效率高。如果你把一个数字存成了字符串"001"，那INCR会直接报错，这类“看起来像数字但不是规范整数”的写法，在业务里很容易埋雷，我后面会再展开。
1.4 字符串拼接与裁剪：APPEND、STRLEN、SETRANGE、GETRANGE
APPEND是在原字符串后面追加，如果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[]，而是用了一种叫SDS（Simple 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[]; // 字节数组 };问题在哪儿呢？就算你存的字符串是"a"，len和free这两个字段也各占4字节，加上buf结束符，额外的头开销至少有8字节。现实中一个Redis实例里短字符串key非常多，这个头开销放大到千万级后就是很大的内存浪费。
所以Redis 3.2之后引入了分级SDS头，根据字符串长度选择不同的头类型：
| 类型 | len字段 | alloc字段 | 支持最大长度 | 头部大小 |
|---|---|---|---|---|
| sdshdr5 | 无独立字段 | 无 | 31字节 | 1字节 |
| sdshdr8 | uint8_t | uint8_t | 255字节 | 3字节 |
| sdshdr16 | uint16_t | uint16_t | 65535字节 | 5字节 |
| sdshdr32 | uint32_t | uint32_t | 4GB | 9字节 |
| sdshdr64 | uint64_t | uint64_t | 2^64 | 17字节 |
其中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字节，44+16+3+1正好等于64，也就是一个缓存行的大小。老教程里如果写的是39，你要知道那是3.2时代之前的事了，当时旧的sds头有8字节，16+8+39+1同样等于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 分布式锁的获取与释放
分布式锁的正确“获取”我前面提过，就是一条SET：
SET lock:order:10086 random_value NX PX 30000random_value建议用UUID或者业务请求ID，不能直接写死一个固定值，因为释放锁的时候要靠它判断“这把锁是不是我的”。
很多人栽在释放锁上。如果直接DEL key，极端情况会出现：线程A持有锁，因为处理时间过长，锁已经到期自动释放了，线程B拿到锁，此时线程A才处理完，执行DEL，把B的锁误删了。所以释放锁之前必须先判断value是不是自己存进去的那个，再删除。
这个“读取判断+删除”两步不是原子的，如果先GET再DEL，中间也可能出岔子，所以要用Lua：
if 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 过期与内存淘汰策略如何影响Strings
Strings带过期时间的写法前面讲了很多，但过期后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数据类型系列最想传递的东西：不要只背命令，要顺着“为什么”去理解它。
