incr适用于简单计数、频次统计等无条件累加场景；incrby适用于指定步长的批量增减；带条件判断的增减（如库存扣减）必须用lua脚本保证原子性，否则必然出现竞态。
用 INCR 还是 INCRBY？别直接套用，先看场景
高并发下计数器最常用的是 INCR 和 INCRBY，但它们不是万能的。固定窗口限流（如“每分钟最多100次”）可以直接用 INCR + EXPIRE 组合，因为只需累加、重置，不涉及条件判断；但一旦需要“扣减前校验是否足够”，比如库存扣减或令牌桶取令牌，INCR 就会出错——它无法原子性地读+判+改。
此时必须用 Lua 脚本封装逻辑。例如扣减库存时，不能先 GET 再 DECR，否则并发下可能扣成负数。正确做法是把判断和扣减写进一个 Lua 脚本里，在 Redis 单线程中一次性执行。
-
INCR适合：简单计数、请求频次统计、无状态限流 -
INCRBY适合：批量增减（如一次扣3个令牌），但同样不带条件 - 带条件的增减（如“有足够令牌才扣”）必须走 Lua，否则必然出现竞态
HASH vs STRING：按维度隔离还是全局共享？
当限流要绑定具体参数（如用户ID、IP、设备号）时，STRING 类型的 key 是最直接的选择："rate_limit:ip:192.168.1.100" 或 "token_bucket:uid:12345"。每个维度独占一个 key，互不影响，也便于单独清理或监控。
而 HASH 更适合同一业务实体下的多子项计数，比如一个订单 ID 下记录“短信发送次数”“邮件发送次数”“回调重试次数”，都存在同一个 HASH 里，用 field 区分。但注意：HASH 的单 field 操作不能直接 INCR，得用 HINCRBY，且整个 key 的过期时间只能统一设置，没法给不同 field 设不同 TTL。
- 按维度隔离（用户/IP/接口）→ 用
STRING+ 动态 key - 同一实体多指标聚合 → 可考虑
HASH，但需接受 TTL 统一管理 - 不要为“省 key 数量”强行用
HASH，key 多不是问题，语义混乱才是
为什么滑动窗口不用 ZSET 就容易不准？
滑动窗口要求精确统计“过去60秒内所有请求时间戳”，ZSET 是唯一能天然支持范围查询+自动去重+按 score 排序的数据类型。用 STRING 或 HASH 模拟，要么得存一堆 key（如每秒一个 key），要么得在客户端维护列表再发多次命令——这既破坏原子性，又放大网络开销。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型用法：ZADD "sliding_window:uid:123" <timestamp> "req_id"</timestamp>，然后用 ZCOUNT 查 now-60 到 now 区间内数量。注意两点：
- 每次插入必须用毫秒级时间戳作 score，否则精度不够
- 得配合定时或惰性清理（
ZREMRANGEBYSCORE）删旧数据，不然内存只增不减 - 如果只是“每分钟清零”，那根本不需要
ZSET，STRING+EXPIRE更轻量
SETNX 初始化计数器时，为什么两次 GET 不可少？
初始化场景常见于“首次请求才设初值并打上过期时间”。很多人写成：先 SETNX key 1，成功就 EXPIRE。这有漏洞——SETNX 成功只说明 key 之前不存在，但不保证后续操作（如 EXPIRE）一定成功；更危险的是，如果多个请求几乎同时触发 SETNX，只有一个能成功，其余请求应直接读当前值，而不是各自再去 INCR，否则初值会被重复设。
安全写法是：用 SET key 1 EX 60 NX 一步完成设值+过期+原子性判断；如果失败，立刻 GET 当前值，再决定是否 INCR。有些 SDK（如 Jedis）不支持 SET ... NX EX 语法，就得用 Lua 封装。
- 优先用
SET key value EX seconds NX，一条命令搞定初始化 - 若 Redis 版本
- 任何“先判断再操作”的两步逻辑，在高并发下都等同于没锁
真正难的不是选哪种数据类型，而是想清楚：这个计数器是否会被多个服务实例同时读写？是否需要条件判断？时间精度要求到秒还是毫秒？这些决定了你能不能偷懒用 INCR，还是必须上 Lua 和 ZSET。漏掉任意一个前提，上线后流量一上来，就会发现限流形同虚设。
