Redis能不能直接存对象啊，还是得先转成别的格式？

Redis能不能直接存对象啊，还是得先转成别的格式？”这个问题，答案是：Redis本身并不能直接存储我们在编程语言中使用的复杂对象（比如一个用户对象，里面包含姓名、年龄、地址等信息），它需要我们先把这个对象转换（或者叫序列化）成一种Redis能够理解和存储的特定格式，这就像你和一位只说英语的朋友交流，你不能直接把中文句子丢给他，需要先翻译成英文他才能懂，Redis就是一个这样“只说特定语言”的数据库。

为什么不能直接存？

这得从Redis的数据类型说起，Redis是一个非常快速的内存键值数据库,它支持几种简单的数据结构，

• String（字符串）：这是最简单的一种，就是一个键对应一个值，这个值可以是文本,也可以是二进制数据。
• Hash（哈希）：类似于一个小的字典，一个键下面可以存放多个字段（field）和值（value）,适合表示一个具有属性的对象。
• List（列表）：一个有序的字符串列表,可以从两头添加或弹出元素。
• Set（集合）：一个无序的、不重复的字符串集合。
• Sorted Set（有序集合）：类似于集合，但每个元素都关联一个分数,可以根据分数排序。

你可以看到，这些类型的“值”基本上都是字符串或者数字，而我们程序中的对象，比如Java里的User对象、Python里的dict或自定义类实例，在内存中是一块结构复杂的、包含各种数据类型和关系的数据，Redis的“小脑瓜”无法直接理解这种复杂结构，所以我们需要把对象“拍扁”，变成一个连续的、线性的字节序列，这个过程就是序列化。

那需要转成什么格式呢？

常见的转换格式有以下几种,各有优劣：

序列化成JSON字符串（最常用、最直观） 这是目前最流行、最容易被人类理解和跨语言使用的方法，JSON格式本身就是一种轻量级的数据交换格式,它用文本的方式清晰地表示了对象的属性和值。

• 怎么存：把你的对象（比如{name: "张三", age: 30}）通过编程语言自带的库（如Python的json.dumps()，Java的Jackson库）转换成一个JSON字符串（'{"name":"张三","age":30}'），然后把它作为String类型存入Redis。
• 优点：
  • 可读性强：你直接用Redis的命令行工具也能看清楚存的是什么。
  • 跨语言：几乎所有编程语言都支持JSON的解析,方便不同系统之间交换数据。
  • 结构清晰：能很好地表示嵌套的对象结构。
• 缺点：
  • 有额外开销：JSON是文本格式，相比一些二进制格式,它会占用更多的存储空间。
  • 性能损耗：序列化和反序列化（从字符串变回对象）的过程需要解析文本,对CPU有一定消耗。
  • 类型信息丢失：JSON只有少数几种基本类型（字符串、数字、布尔等），你对象里原本的特定类型（如日期）可能会被转换成字符串,取回来时需要自己再转换。

使用二进制序列化格式（更高效、更专业） 如果你追求极致的性能和更小的空间占用，可以考虑二进制格式，常见的有Protocol Buffers（Protobuf）、MessagePack、Apache Avro等，或者直接用编程语言自带的序列化机制（如Java的Serializable接口、Python的pickle模块）。

• 怎么存：使用相应的库将对象序列化成二进制字节流，然后将这个字节流作为Redis的String类型（因为Redis的String可以存二进制安全的数据）存入。
• 优点：
  • 空间小：二进制格式非常紧凑,节省内存。
  • 速度快：序列化和反序列化的速度通常比处理JSON文本快得多。
• 缺点：
  • 不可读：你看到的是一堆乱码,无法直接查看内容。
  • 跨语言兼容性可能受限：比如Python的pickle序列化的数据，基本上只能用Python读回来，而像Protobuf虽然支持多语言，但需要预先定义好数据格式（.proto文件）,不够灵活。

使用Redis的Hash结构（适合简单、扁平的对象） 如果你的对象属性不多，且结构比较扁平（没有复杂的嵌套对象），还有一种非常Redis风格的做法：不进行序列化，而是把对象的每个字段和值直接存成Redis Hash 结构的field-value对。

• 怎么存：比如一个用户对象，你可以用一个键user:123表示，它的类型是Hash，然后在这个Hash里设置name字段为“张三”，age字段为30。
• 优点：
  • 高效：你可以单独读取或修改对象的某一个字段，而不需要操作整个对象,非常节省网络带宽和CPU。
  • 原生支持：直接利用Redis的数据结构,操作起来很自然。
• 缺点：
  • 不适合复杂对象：如果对象有嵌套（比如地址信息本身又是一个包含省、市、街道的对象），用Hash表示起来会很麻烦，可能需要拆分成多个Hash,或者放弃这种结构。
  • 类型限制：Hash的field和value都只能是字符串，数字会被存储为字符串,取回时需要自己转换类型。

总结一下该怎么选：

• 绝大多数情况，首选JSON：因为它简单、通用、可读性好，在性能和空间不是极端敏感的场景下,它是平衡性最好的选择。
• 当你需要频繁修改对象的部分字段时，考虑使用Hash：比如只更新用户的最后登录时间，用Hash可以直接修改last_login字段，而用JSON则需要读出整个字符串、解析成对象、修改属性、再序列化、最后写回,效率低很多。
• 在性能压榨到极致的系统内部，考虑二进制序列化：比如高频交易、实时推荐等场景,每一毫秒和每一KB内存都很重要。

回到最初的问题，Redis不能直接存对象，必须转成格式，至于转成哪种格式，就像出门选衣服，要看具体的“天气”和“场合”，没有绝对的好坏,只有最适合你当前需求的选择。