Redis存储只读对象列表：使用SET类型还是STRING类型更合适？

一、不使用SET专属命令时，SET类型相比STRING类型的优势 #

• 单元素操作效率更高：如果需要判断某个条目是否存在于列表中，直接调用SISMEMBER命令即可完成O(1)复杂度的查询，无需把整个列表的序列化内容全部拉取到本地反序列化后再遍历判断，节省网络带宽和本地计算资源。
• 内存开销更低：Redis对小容量SET有专门的优化编码（intset/ziplist，取决于元素类型和长度），如果你的列表元素是数值、短字符串等简单类型，SET存储的内存占用会比带引号、逗号、括号的JSON字符串低30%以上。
• 后续扩展兼容性更强：即使当前是只读场景，如果后续需要新增增量增删元素、自动去重、随机拉取条目等需求，SET可以直接适配，不需要修改原有存储结构，也不会出现STRING类型全量读写的原子性问题。

二、直接序列化为JSON存STRING是否是更合适的实践 #

结合你当前的场景（只读缓存、每次访问都是拉取完整列表、无单元素操作需求），直接存JSON字符串是更合适的选择，原因如下：

• 开发适配成本极低：你从本地MemoryCache迁移到Redis的过程中，只需要在缓存读写层增加通用的JSON序列化/反序列化逻辑即可，业务层代码不需要做任何修改，也不需要单独适配Redis SET类型的读写逻辑。
• 全量读取效率更高：你每次需要用到完整的对象列表时，只需要调用一次GET命令拉取完整字符串，一次反序列化就能得到目标对象，比调用SMEMBERS拉取所有SET元素后逐个反序列化拼接列表的速度更快，Redis服务器的处理压力也更低。
• 复杂结构适配性好：如果你的列表元素是包含多个字段的自定义对象，存STRING的JSON序列化逻辑可以通用适配所有类型，不需要额外处理SET单元素的序列化规则。

如果后续业务新增了单元素查询、去重、增量修改等需求，再切换为SET类型即可，两种方案的迁移成本并不高。

内容的提问来源于stack exchange，提问作者Nick Mezvrishvili