Redis 的键名要起得清楚
Redis 键是平面键空间中的二进制安全名称，不是文件路径，也不是数据库表结构声明。冒号可以按约定分隔业务归属、环境、实体和标识，例如 cart:prod:string:42 能表达意图。但 Redis 不会把这些字段解释成类型检查或访问限制，不能仅凭名字就推断服务端已经替应用建立了约束。 让约定没有歧义 写入方、读取方、维护任务和迁移逻辑，应采用相同字段顺序与标识编码。不同前缀可以让两个服务分别存储同一个业务编号；若最后编码出来的完整名字相同，仍然会碰撞。命名规范帮助人和代码协作，并没有创建由 Redis 独立管理的命名空间。 类型标签也只是说明。SET 可以在名字带 hash 的键下写入字符串，之后 HSET 就会报 WRONGTYPE。排查时应用 TYPE 查看真实数据类型，序列化格式与类型要求则属于应用契约。不能把名字中的“列表”“哈希”当作当前数据已经符合预期的证据。 名字宜简短清晰，不必压缩成难懂缩写，也不要把整段文档塞进去。键名占内存并随命令传输，但对象开销和负载本身同样重要；没有测量就不能宣称一次改名显著加快查询。标识编码还应避免分隔符、通配符和集群花括号取得本来不希望赋予的含义。 模式匹配不等于模式删除 SCAN MATCH 接受 glob 模式。从游标零开始，把每次返回的新游标用于下一次调用，直到再次返回零。COUNT 是工作量提示，不保证精确返回多少条，也不是严格内存上限。某一页可能没有匹配项，但游标还不为零，不能据此提前结束。每次调用仍需要服务端工作，增量扫描不等于完全没有阻塞成本。 完整迭代保证能看到在迭代全过程始终存在、且符合模式的键，但可能重复返回；迭代中新增或删除的键没有同样保证。应用应按需要去重，或让处理逻辑可以安全重复。扫描不是快照，更不能把一个空页面当作集合已经遍历完毕。 DEL 的语义不同：它接收精确键名，不接收模式。参数末尾带星号，不会删除所有同前缀兄弟键；只有真的存在名字包含这个星号的键，才会删除那一个。命令行工具之外还有 shell 展开这一层，应正确引用参数，不要把终端的展开行为误认为 Redis 自己支持通配删除。 坏掉的样子 维护脚本若假定 DEL 会展开前缀，可能实际什么也没删，却报告清理完成。相反，先用宽泛模式收集 SCAN 结果，再无条件删除每个匹配，也可能误伤不属于自己的数据。必须核对精确目标与修改策略；而且发现与删除之间，同名键可能已经被重建，之前审阅过的名字不一定还指向同一个逻辑对象。 前缀也不是安全边界。访问限制应通过合适的 ACL 键模式和命令权限落实，必要时使用独立部署边界。键模式权限无法约束不携带键参数、直接作用于整个数据库的命令，所以给账户一个前缀模式不等于万事安全。服务名前缀也不会自动预留内存，更不构成淘汰策略隔离。 ...
