Redis是否支持整数作为键存储？架构与性能原因探究

先直接给你明确答案：Redis不支持将整数（或任何非字符串类型）直接作为键存储——所有传入的键都会被强制转换为字符串类型，就像你在示例里看到的那样，34和34.0最终被存成了"34"和"34.0"两个完全不同的键，这是Redis核心架构决定的。

接下来聊聊为什么Redis会做这样的限制，从架构和性能两个层面来拆解：

架构层面的核心原因 #

• 简化核心实现：Redis的键空间本质是一个哈希表，统一用字符串作为键可以极大简化代码逻辑——不需要为不同类型的键处理不同的哈希计算、比较规则，也不用额外维护键的类型元数据。如果支持多种键类型，整个核心数据结构的复杂度会飙升，后续的维护和扩展成本也会大幅增加。
• 简化持久化逻辑：Redis的RDB和AOF持久化机制都是围绕字符串来设计的。统一字符串键意味着持久化时不需要记录键的类型信息，直接存储字符串字节即可，减少了持久化的开销，也避免了不同类型键带来的兼容性问题。

性能层面的考量 #

• 统一高效的查找逻辑：字符串类型的键在哈希计算、查找时的逻辑是统一且极致高效的。如果支持多种键类型，Redis需要为每种类型实现专属的哈希函数和比较逻辑，这会增加查找操作的额外开销，拖慢整体性能。
• 通用性带来的间接性能提升：字符串是通用类型，能兼容所有业务场景的键需求（不管是数字、业务ID、UUID还是其他标识）。应用层不需要在数值和其他类型之间反复做转换，反而能减少不必要的序列化/反序列化开销，提升实际开发和运行效率。

再结合你的示例补充一句：你看到34和34.0被判定为不同的成员，就是因为Redis只认字符串的字节序列是否一致，不会做语义上的数值相等判断——它把每个键都当作纯字符串处理。

如果你的业务需要用数值作为键并做数值层面的判断，建议在应用层先统一数值的格式（比如统一存整数的字符串形式，或者把浮点数标准化成固定格式），避免出现示例里的这种不一致问题。

内容的提问来源于stack exchange，提问作者Mangu Singh Rajpurohit