在使用 Redis 的 String 和 Hash 数据结构时，需要注意不同的特性和使用场景，以下是详细说明：
一、使用 Redis String 数据结构的注意事项及原因
String 是 Redis 最基础的数据结构，可存储字符串、数字、二进制数据（如图片），最大容量为 512MB。
1. 避免存储过大的值
注意：单个 String 值不宜超过 100KB（推荐），避免接近 512MB 上限。
原因：
Redis 是单线程处理命令，过大的 String 会导致读写操作阻塞，影响其他请求响应速度。
内存分配效率低，过大的 String 可能触发 Redis 的内存重分配，产生性能开销。
网络传输成本高，大值会增加带宽消耗和延迟。
2. 谨慎使用SET覆盖操作
注意：
SET key value会直接覆盖已有值，需确认是否需要先判断键是否存在（如用SETNX或GET+SET组合）。原因：
误操作可能导致重要数据丢失，尤其在分布式系统中，并发写入时容易覆盖预期外的值。
若需实现 “仅当键不存在时设置” 或 “仅当键存在时更新”，应使用
SETNX（SET if Not Exists）或SET ... XX参数。
3. 合理设置过期时间
注意：通过
EXPIRE或SET key value EX seconds为临时数据设置过期时间，避免内存泄漏。原因：
String 本身不会自动过期，若长期存储无效数据，会占用内存，降低 Redis 效率。
过期时间是 Redis 内存淘汰的重要依据，合理设置可减少手动清理的维护成本。
4. 数字操作的原子性与范围
注意：
INCR/DECR等命令仅支持 64 位有符号整数，超出范围会报错；高并发下依赖其原子性。原因：
Redis 的数字操作是单线程原子执行的，可安全用于计数器、限流等场景，无需额外加锁。
若存储非整数类型（如字符串），调用
INCR会返回错误，需提前确保值的类型正确。
5. 二进制安全的使用
注意：String 支持二进制数据（如序列化对象），但需注意序列化格式的兼容性。
原因：
Redis 对 String 的存储是二进制安全的（不解析内容），但反序列化时若格式错误（如版本不兼容），可能导致数据无法读取。
二、使用 Redis Hash 数据结构的注意事项及原因
Hash 适用于存储对象（如用户信息、商品属性），由键值对（field-value）组成，类似字典。
1. 避免 Hash 表过大
注意：单个 Hash 的 field 数量不宜过多（推荐不超过 1000 个），避免成为 “大 Key”。
原因：
Redis 的 Hash 底层使用压缩列表（ziplist）和哈希表（hashtable）两种编码：
当 field 少且 value 小时用 ziplist，节省内存但操作效率低（O (n)）。
当 field 增多或 value 变大时，会转为 hashtable（O (1)），但内存占用增加。
过大的 Hash 会导致
HGETALL等命令返回大量数据，阻塞线程并占用带宽。
2. 谨慎使用HGETALL
注意：避免对大 Hash 使用
HGETALL，改用HSCAN分批获取。原因：
HGETALL会一次性返回所有 field-value，若 Hash 包含 10 万个 field，会导致 Redis 处理时间过长，阻塞其他请求。HSCAN通过游标分批迭代，每次返回部分数据，降低对 Redis 性能的影响。
3. field 命名的简洁性
注意：field 名称尽量简短（如用 “n” 代替 “name”），减少内存占用。
原因：
Hash 的 field 会重复存储在内存中，过长的 field 名称会显著增加内存消耗（尤其当 field 数量多时）。
例如，10 万个 field 若每个名称节省 10 字节，可减少约 1MB 内存。
4. 避免滥用 Hash 存储非对象数据
注意：Hash 适合存储 “对象的多个属性”，不适合存储无关的键值对。
原因：
若将不相关的键值对塞进同一个 Hash，会导致逻辑混乱，且无法针对单个 field 设置过期时间（Hash 的过期时间是针对整个键的）。
例如，存储 “用户 1 的信息” 和 “用户 2 的信息” 应使用两个 Hash，而非一个 Hash 中的不同 field。
5. 警惕 Hash 的内存编码转换
注意：监控 Hash 的编码类型（通过
OBJECT ENCODING key查看），避免频繁转换。原因：
ziplist 转 hashtable 是单向的（无法转回），转换过程会消耗 CPU 资源。
若业务中 Hash 的 field 会动态增加，应提前规划阈值（通过
hash-max-ziplist-entries和hash-max-ziplist-value配置），避免频繁触发转换。