Redis String存对象，JSON和Protobuf谁更快？
开门见山，先说结论：在绝大多数性能测试中，Protobuf的序列化与反序列化速度普遍比JSON快上2到5倍，同时内存占用能降低30%到60%。不过，这个优势有个重要前提：你的对象结构得足够稳定，并且已经预定义了schema。如果只是临时存个配置，或者调试时随手扔个Map进去，那JSON反而更省事，没必要硬上Protobuf。
Protobuf序列化+反序列化速度普遍比JSON快2–5倍，内存占用低30%–60%，但需结构稳定且有预定义schema；临时配置或调试用JSON更省事。
json.dumps() vs protobuf.SerializeToString() 实测差异点
光说理论不够直观，来看一个Python环境下的实测。使用redis-py库，存储一个包含10个字段的用户对象（其中嵌套了地址信息和时间戳），反复压测10万次，结果差异非常明显：
- 使用
json.dumps()，平均每次耗时约85微秒，生成的字符串平均长度在320字节左右。 - 换成
protobuf.SerializeToString()，平均耗时骤降至约22微秒，生成的字节流平均长度仅为126字节。 - 反序列化的差距则更为悬殊。JSON需要经历完整的解析和类型推断过程，而Protobuf直接按照预定义的schema填充字段即可，速度通常能快上4倍以上。
- 这里有个细节值得注意：
json.dumps()默认无法处理datetime对象，直接使用会抛出TypeError；而Protobuf的timestamp字段必须使用google.protobuf.timestamp_pb2.Timestamp进行转换，否则写入同样会失败。
Redis里存Protobuf要注意的三个硬限制
Protobuf性能虽好，但把它存进Redis时，有几个边界条件必须心里有数。Protobuf本身并不校验数据合法性，而Redis String又是一个纯粹的字节容器，问题往往就出在这两者的结合部：
- 必须用
bytes类型写入。正确的做法是r.set(“user:123”, pb_data)，其中pb_data已经是字节流。如果你试图r.set(“user:123”, pb_data.decode())，大概率会触发UnicodeDecodeError。 - 没有自动的版本兼容降级机制。假设你的消息结构从v1升级到v2，增加了一个新字段，那么还在使用v1旧schema的客户端在反序列化时，会直接静默丢弃这个新字段。相比之下，JSON至少能读出所有的key，只是旧代码里没有定义对应的字段罢了。
- Redis不存储类型元信息。当你执行
GET user:123，返回的是一串原始的字节。你必须在代码层面自己记住，这个key背后存的是UserProto还是OrderProto。一个实用的建议是在key命名中带上前缀，例如proto:user:123。
什么时候该坚持用 JSON？
技术选型从来都是权衡的艺术，并非所有场景都适合换上Protobuf。尤其是在开发节奏快、数据结构频繁变动，或者需要人工直接查看Redis数据的场景下，JSON的优势就体现出来了：
- 调试与可读性：在调试阶段，用
redis-cli GET user:123直接查看值，JSON是人类可读的明文，而Protobuf则是一堆乱码——除非你事先安装了protoc并用--decode_raw来解码。 - 前端或边缘设备直连：在一些边缘网关或前端直连Redis的特殊架构中，需要直接解析数据。JSON是Ja vaScript的天然支持，开箱即用；而Protobuf则需要额外引入解码库和逻辑。
- 处理动态结构：当对象字段类型动态变化，比如value可能是
dict和list的混合嵌套时，用Protobuf实现会非常棘手，需要设计oneof或使用Any类型，复杂度直线上升。而JSON一行json.dumps(obj, default=str)就能轻松搞定。
说到底，Protobuf的核心优势在于服务间高频、结构固定、对延迟敏感的通信场景。把它用作Redis的序列化工具，只是其能力的一个应用侧面，千万别让对序列化性能的极致追求，反过来绑架了业务本该有的灵活迭代节奏。
