用途：为在 Redis 中建模数据提供基础指导，重点覆盖数据类型选择与键名约定，这两项决策直接影响内存占用、性能和可维护性。适用时机包括：缓存对象、会话或按用户状态；计数器、排行榜、最近条目列表、唯一成员集合；审查或重构 Redis 键名；以及决定某个实体该用 Redis Hash 还是 JSON 文档。
主要能力：提供按访问模式（而非仅数据形状）选型的对照建议。简单值与计数器用 String，支持原子 INCR/DECR 与 SET/GET；字段可独立更新的对象用 Hash，可做字段级读写、避免整对象重写；队列与最近 N 条用 List，两端推入弹出为 O(1)；唯一项与成员判断用 Set，SADD/SISMEMBER/SCARD 为 O(1)；排行榜与按分数范围用 Sorted Set，支持 ZADD/ZRANGE/ZRANK；嵌套或层级数据用 JSON，支持路径级更新、嵌套数组与 RQE 索引；事件日志与扇出消息用 Stream，持久化并支持消费者组；向量相似度用 Vector Set，提供带 HNSW 的原生向量存储。文档还指出了一个常见反模式：把扁平对象塞进序列化字符串，更新一个字段就要取回、解析、修改、重写，应改用 Hash。
用法：键名采用冒号分隔的稳定层级，形如 {entity}:{id}:{attribute}，例如 user:1001:profile、order:2024:items、session:abc123、article:987:likes。建议全小写、冒号分隔，不使用空格或混合大小写；键名尽量短但可读；不要用完整 URL 或长字符串作键，可提取短标识符或使用 URL 的哈希摘要；多租户场景加前缀（如 tenant:42:user:7:cart）便于扫描与 ACL 按租户定位；每个服务选定一套约定并保持全局一致。
限制：资料未提供具体收费、价格、平台或性能数据；上述建议为通用建模指导，实际选型仍需结合具体访问模式与数据规模评估。