编码与演化

一句话

第 2、3 章讲数据怎么建模、怎么落盘；第 4 章问一个更贴近工程日常的问题：数据要在内存表示（对象、结构体、列表）和字节序列（存文件、走网络）之间来回翻译，这层翻译（编码 / 序列化）怎么做，才能让代码和数据各自独立地演化？全章的灵魂是两个词——向后兼容（backward compatibility）：新代码能读老数据；向前兼容（forward compatibility）：老代码能读新代码写的数据。做到这两条，你才敢对一个跑着的大系统做滚动升级，而不必让所有节点同时停机换代码。

Glossary · 术语表

坐标

本章是 Part I「数据系统的基石」的收官。它上承第 2 章（数据模型）、第 3 章（存储引擎），把「数据长什么样、怎么存」的话题收到一个绕不开的落点——数据一旦要跨越进程、跨越时间，就必须编码成字节；同时它又是通往 Part II「分布式数据」的桥：复制、分区、多节点通信，本质都是数据在网络上流动，而流动就得先编码。落到现实，这一章对应的是你每天都在碰的决策：接口用 JSON 还是 Protobuf？给消息队列里的事件加个字段会不会搞挂下游？数据库某张表的结构能不能安全地改？

这章要解决什么

应用总在变——需求变了，数据的形态也跟着变：加个字段、拆个字段、改个类型。DDIA 把「数据形态可变」称为 schema 演化（evolution）。问题是，改动不会瞬间同步到系统的每一处：

• 服务端通常滚动升级——一批批换，任一时刻新旧版本共存；
• 客户端（手机 App、别人写的第三方程序）更是你根本没法逼着升级，老版本可能赖着跑好几年。

于是「新旧代码、新旧数据四种组合同时存在」成了常态。要让系统在这种混乱里照常运转，就得让所有数据的编码格式同时满足向后和向前兼容。DDIA 有句点题的话：「数据的生命周期常常比写它的代码更长」——一条五年前写入的记录还静静躺在库里，读它的代码早已改过无数遍。不把兼容当第一公民，每次升级都是在给未来埋雷。

核心内容，讲透

① 编码是什么，以及为什么别用语言内置的序列化

内存里的数据充满指针 / 引用——对象里套着对另一个对象的地址，这些地址一出本进程就毫无意义。所以要存盘、要上网，必须把它翻译成一段自包含的字节序列，这一步就是编码（encoding），也叫序列化。几乎每种语言都自带一套（Java 的 Serializable、Python 的 pickle、Ruby 的 Marshal），一行就能用——但 DDIA 劝你别拿它做长久存储或跨系统通信：① 绑死语言，Java 序列化的东西别的语言基本读不了；② 安全隐患，反序列化时能被诱导实例化任意类，是经典的远程执行漏洞；③ 版本兼容做得差，本章最看重的向前 / 向后兼容它恰恰照顾不好；④ 性能与体积也常不理想。结论：内置序列化图一时省事，长期是坑。

② 文本格式：JSON / XML / CSV 的甜与坑

跨语言就转向标准格式。JSON、XML、CSV 胜在人能读、生态无处不在，是 Web 与配置的事实标准。但坑也实在：数字含糊——JSON 分不清整数和浮点、更没精度概念，超过 2^53 的大整数（如推特的雪花 ID）在按 IEEE 双精度浮点解析的语言里会悄悄丢精度（Twitter 的 API 为此对同一个 ID 既返回数字 id、又返回字符串 id_str）；不支持二进制串，塞二进制得先 Base64、白胖 33%；schema 可选，字段类型全靠双方口头约定，容易对不上。它们够用、够通用，但当你在乎体积、类型精确、和强制的兼容规则时，就该看二进制 + schema 的格式了。

③ 二进制 + schema：Thrift 与 Protocol Buffers（认号不认名）

Thrift（Facebook）和 Protocol Buffers（Google）是同一路思想：先用 IDL 写死 schema（每个字段配一个数字标签 field tag），再由工具生成各语言的读写代码。关键在于——编码后的字节里只存「字段号 + 类型 + 值」，完全不存字段名。一个 userName="Martin" 不再拖着 8 个字符的键名，只留一个字节的标签号。所以它们比 JSON 小得多：DDIA 那条示例记录，JSON 约 81 字节，Thrift 紧凑协议约 34 字节、Protobuf 约 33 字节，小了一半还多。

省空间只是副产品，真正的价值是 schema 演化：字段靠号不靠名，于是——加字段只要给个新的、没用过的标签号：老代码读到不认识的号，按类型信息跳过即可（向前兼容）；新代码读老数据时，缺的新字段给个默认值即可（向后兼容）。铁律有二：新加的字段不能设成必填（required），否则老数据一律读不过；标签号一旦用出去，永不修改、永不复用——改名字随便（名字不入编码），改号就等于换了个字段。删字段只能删可选字段，且那个号从此作废、不许再分给别人。

④ Avro：连字段号都不要，靠「两份 schema 对齐」

Avro（2009 年为 Hadoop 而生）走了另一条路：编码后的字节里既没字段名、也没字段号、连类型标记都没有——纯粹是一串值挨着排。这么极致的紧凑靠什么解码？靠两份 schema：写入时用的 writer's schema 和读取时用的 reader's schema。二者不必相同，只需兼容；Avro 按字段名把两份 schema 对齐（schema resolution）——writer 有、reader 没有的字段被忽略（向前兼容），reader 有、writer 没有的字段用 reader 里写好的默认值填（向后兼容）。

代价是：解码时必须拿得到 writer's schema。实践中，大文件在开头存一份 writer schema（Hadoop 里一存百万条记录，摊薄到几乎没成本）；数据库 / 消息流则给每条记录带一个小小的版本号，去一个 schema 注册表（registry）查对应 schema。Avro 最大的甜头是对「动态生成的 schema」友好：数据库表加一列，直接照新表结构生成一份新 Avro schema 即可，不必像 Protobuf 那样手工给每列维护一个不重复的标签号——这正是它在数据仓库 / 大数据管道里受宠的原因。

⑤ 数据在哪流动：数据库、服务、异步消息

格式讲完，DDIA 追问：数据究竟怎么从一段代码流到另一段？归成三种数据流（dataflow）模式，每一种都得过兼容关。经数据库：写它的进程和读它的进程可能是不同版本，甚至「给未来的自己写」；一个坑是——旧代码读了一条含新字段的记录、改了别的字段又写回去，若解析时把不认识的新字段丢了，就会悄悄抹掉数据，格式和代码都要保住未知字段。经服务（REST / RPC）：客户端与服务端各自升级，通常服务端先升，所以要请求向后兼容、响应向前兼容；RPC 想把网络调用伪装成本地调用，但网络会延迟、丢包、超时，得靠幂等与重试兜。经异步消息（消息队列 / actor）：发送方把消息投进 broker、接收方将来某刻再取，两头彻底解耦、时序错开，兼容要求最直接。

关键权衡与选型

本章的选型有两层。第一层是选编码格式——从「一行就能用」的语言内置，到人可读的文本，再到紧凑且强制兼容规则的二进制 schema，代价与收益逐级不同：

表 1 · 五类编码格式对比

第二层是选数据流方式——同一份数据，走数据库、走服务、还是走消息，兼容的方向和难点各不同：

表 2 · 三种数据流模式的兼容重点

一条实用心法：对外、要人读、变动少的接口，JSON 足矣；对内、高频、在乎体积和强制兼容的服务间通信，上 Protobuf / gRPC；大数据管道、schema 随库结构自动变的场景，Avro 最省心。

为什么重要 / 落到真实系统

这一章是微服务和大数据时代的地基。凡是拆成多服务、要独立部署的系统，团队 A 升级自己的服务时不能等团队 B 一起改——能做到这点，全靠接口的编码格式向前 / 向后兼容。gRPC 用 Protobuf、Kafka + Avro + Schema Registry 管事件流、REST + JSON 撑开放 API——你每天用的基础设施，正是本章思想的直接产物。这些主张也有公开可查的工程实践替它们背书：

易错点与争议

• 把字段号改了 / 复用了。这是最致命的错：号一变，老数据里的旧号会被新代码错认成别的字段，数据静默错乱。号只增不改、废号永不复用。
• 给新字段设成必填（required）。老数据里没有它，一读就报错，向后兼容当场破功。新字段一律给可选 + 默认值。
• 「向前兼容」被忽略。大家都记得让新代码读老数据（向后），却常忘了老代码要能读新数据——滚动升级期老节点还在跑，它遇到新字段必须能安然跳过。
• 读-改-写丢字段。旧代码读一条记录、只改一个字段又写回，若序列化库把它没解析的新字段丢掉，就悄悄抹掉了别人的数据。要么保留未知字段，要么别做整条覆盖。
• 把 RPC 当本地函数调用。网络会延迟、丢包、超时，同一个请求可能被重试；不设计幂等，重试就会重复扣款、重复下单。
• 时代局限（2017）。此后 gRPC 已成微服务事实标准、GraphQL 兴起改变了 API 演化方式、Protobuf 也补齐了更多特性；但「编码 + 向前 / 向后兼容」这套心智框架至今是所有跨版本数据交换的底层逻辑，纹丝未动。

要点