【DDIA】编码和演进

最新推荐文章于 2026-06-07 11:33:09 发布

原创最新推荐文章于 2026-06-07 11:33:09 发布 · 609 阅读

12 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

我与DDIA的对话

Capture IV – 编码和演进

上一章聊的是存储引擎，本章继续下钻，探讨编码相关问题。

所有涉及跨进程通信的地方，都需要对数据进行编码（Encoding），或者说序列化（Serialization）。因为持久化存储和网络传输都是面向字节流的。编码本质上是一种“降维”操作，将内存中高维的数据结构降维成单维的字节流，于是底层硬件和相关协议，只需要处理一维信息即可。而解码（Decoding），或者说反序列化（Deserialization），便是反向地将字节流还原为各种数据结构。

在这里插入图片描述

在进行编码时，往往需要考虑如下两方面问题：

如何编码能够节省空间、提高性能？
如何编码以适应数据的演化和兼容？

为了避免出现歧义，我们在此规定：

向后兼容 (backward compatibility)：当前代码可以读取历史版本代码接受的数据。
向前兼容 (forward compatibility)：当前代码可以读取未来版本代码接受的数据。

数据编码的格式

编程语言内置

这一节，我们聊聊几种常见的编码工具（JSON，XML，Protocol Buffers 和 Avro），他们是如何进行编码、如何进行多版本兼容。

相信大家在日常写代码的过程中会发现，很多编程语言内置了一些缺省的编码方法：

Java 有 java.io.Serializable
Ruby 有 Marshal
Python 有 pickle

如果你确定你的数据只会被某种特定的语言所读取，那么直接用内置的编码方法即可。但这些编程语言内置的编码格式有以下缺点：

和特定语言绑定
安全问题
兼容性支持不够
效率不高

文本编码

JSON，XML 和 CSV 属于常用的文本编码格式，其好处在于肉眼可读，坏处在于不够紧凑，占空间较多。

JSON 最初由 JavaScript 引入，因此在 Web Service 中用的较多，当然随着 Web 的火热，现在成为了比较通用的编码格式，比如很多日志格式就是 JSON 的。
XML 比较古老了，比 JSON 冗余度还高，现在基本上是在配置文件用到，但总体而言用的越来越少了。
CSV（以逗号、TAB、换行符分割）还算紧凑，但是表达能力有限。数据库表导出有时会用。

除了不够紧凑外，文本编码（text encoding）还有以下缺点：

对数值类型支持不够。CSV 和 XML 直接不支持，万物皆字符串。JSON 虽区分字符串和数值，但是不进一步区分细分数值类型。可以理解，毕竟是文本编码，主要还是面向字符串。
对二进制数据支持不够。支持 Unicode，但是对二进制串支持不够，可能会显示为乱码。虽然可以通过 Base64 编码来绕过，但有点做无用功的感觉。
XML 和 JSON 支持额外的模式。模式会描述数据的类型，告诉你如何理解数据。配合这些模式语言，虽然可以让 XML 和 JSON 变得强大，但是大大增加了复杂度。
CSV 没有任何模式。

很多场景下需要数据具备一定的可读性，并且不关心编码效率，那么这几种编码格式就够用了。

二进制编码

如果数据只被单一程序读取，不需要进行交换，不需要考虑易读性等问题，则可以用二进制编码，在数据量达到一定程度后，二进制编码所带来的空间节省、效率提升都很可观。

因此，JSON 有很多二进制变种：MessagePack、BSON、BJSON、UBJSON、BISON 和 Smile 等。我们以 MessagePack 为例，他在对性能有较高要求的场景中，是 JSON 的一个热门的高效替代品。那么他是如何进行编码的呢？

对于下面例子，

{
  "userName": "Martin",
  "favoriteNumber": 1337,
  "interests": ["daydreaming", "hacking"]
}

如果用 MessagePack 来编码，则为：

83                     // 3个元素的map
a8 757365724e616d65  // "userName" (8字节)
a6 4d617274696e      // "Martin" (6字节)
ae 6661766f726974654e756d626572  // "favoriteNumber" (14字节)
cd 0539              // uint16 1337 (0x0539 = 1337)
a9 696e74657265737473 // "interests" (9字节)
92                    // 2个元素的数组
ab 646179647265616d696e67  // "daydreaming" (11字节)
a7 6861636b696e67         // "hacking" (7字节)

在这里插入图片描述

可以看出其基本编码策略为：使用类型，长度，bit 串，顺序编码，去除无用的冒号、引号、花括号。
从而将 JSON 编码的 81 字节缩小到了 66 字节，微有提高。

Thrift & Protocol Buffers

Thrift 最初由 Facebook，ProtoBuf 由 Google 在 07~08 年左右开源。他们都有对应的 RPC 框架和编解码工具。表达能力类似，语法也类似，在编码前都需要由接口定义语言（IDL）来描述模式。

什么是 IDL 呢？IDL 是编程语言无关的，这体现了微服务架构中非常重要的“契约先行”开发模式，利用相关代码生成工具，可以将上述 IDL 翻译为指定语言的代码。也就是说，集成这些生成的代码，无论什么样的语言，都可以使用同样的格式编解码。这也是使用不同编码语言的服务能够互相通信的基础。

还是这个例子，

{
  "userName": "Martin",
  "favoriteNumber": 1337,
  "interests": ["daydreaming", "hacking"]
}

Thrift IDL 结构如下：

struct Person {
    1: required string userName,
    2: optional i64 favoriteNumber,
    3: optional list<string> interests
}

有了上面的 IDL 后，Thrift 就可以直接对数据内容进行编码，其支持多种不同的编码格式，常用的有：Binary、Compact、JSON。可以让用户自行在：编码速度、占用空间、可读性方便进行取舍。

Binary 编码结果如下：

0B        // 字段1的类型：STRING (11)
00 01     // 字段1的ID：1

00 00 00 06 // 字符串长度：6 (Martin 占6个字节)
4D 61 72 74 69 6E // "Martin" 的 ASCII 码 (M a r t i n)

// --- 字段2 ---
0A        // 字段2的类型：I64 (10)
00 02     // 字段2的ID：2

00 00 00 00 00 00 05 39 // 数字 1337 的大端字节序（Big-Endian）表示 (0x539)

// --- 字段3 ---
0F        // 字段3的类型：LIST (15)
00 03     // 字段3的ID：3

0B        // 列表中元素的类型：STRING (11)
00 00 00 02 // 列表长度：2 (有两个字符串)

// 第一个字符串 "daydreaming"
00 00 00 0B // 长度：11
64 61 79 64 72 65 61 6D 69 6E 67 // "daydreaming"

// 第二个字符串 "hacking"
00 00 00 07 // 长度：7
68 61 63 6B 69 6E 67 // "hacking"

00        // 停止标记：STOP (0)

在这里插入图片描述

可以看出其特点：

使用 field tag 编码。field tag 其实蕴含了协议中的字段类型和名字。
使用类型、tag、长度、bit 数组的顺序编码。

再看看 Compact 编码：
在这里插入图片描述

相比 Binary Protocol，Compact Protocol 由以下优化：

filed tag 只记录增量 delta。如果字段ID是1,2,3，只需要存 1,1,1 而不是 1,2,3，以便节省空间，从而将 field tag 和 type 压缩到一个字节中。
对数字使用变长编码和 Zigzag 编码。

ProtoBuf 与 Thrift Compact Protocol 编码方式很类似，也用了变长编码和 Zigzag 编码。但 ProtoBuf 对于数组的处理与 Thrift 显著不同，使用了 repeated 前缀而非真数组，其好处在于兼容数组类型的同时，支持将可选（optional）单值字段，修改为多值字段。修改后，旧代码在看到新的多值字段时，只会使用最后一个元素。

ProtoBuf IDL 结构如下：

message Person {
    required string user_name       = 1;
    optional int64  favorite_number = 2;
    repeated string interests       = 3;
}

在这里插入图片描述

在聊完了编码方式后，我们回到全文一开始提出的第二个问题：这些编码如何适应数据的演化和兼容？

随着时间的推移，业务总会发生变化，我们也不可避免的增删字段，修改字段类型，即模式演变。在模式发生改变后，需要：

向后兼容：新的代码，在处理新的增量数据格式的同时，也得处理旧的存量数据。
向前兼容：当前代码，需要以后可拓展。

Thrift 和 ProtoBuf 是怎么解决这两个问题的呢？

字段标号 + 限定符（optional、required）保证向后兼容：新加的字段需为 optional。这样在解析旧数据时，由于新字段是可选的，就不会出现字段缺失的情况。
向前兼容：字段标号不能修改，只能追加。这样旧代码在看到不认识的标号时，省略即可。

数据流模型

数据可以以很多种形式从一个系统流向另一个系统，但不变的是，流动时都需要编码与解码。在数据流动时，会涉及编解码双方模式匹配问题，上一节已经讨论。本小节主要探讨几种进程间典型的数据流方式：

通过数据库
通过服务调用
通过异步消息传递

经由数据库的数据流

访问数据库的程序，可能：

只由同一个进程访问。
由多个进程访问。则多个进程可能有的是旧版本，有的是新版本，此时数据库需要考虑向前和向后兼容的问题。

对于应用程序，可能很短时间就可以由旧版本替换为新版本。但是对于数据，旧版本的代码写入的数据量，经年累月可能很多。在变更了模式之后，由于这些旧模式的数据量很大，全部更新对齐到新版本的代价很高。这种情况我们称之为：数据的生命周期超过了其对应代码的生命周期。

在读取时，数据库一般会对缺少对应列的旧数据

填充新版本字段的默认值（default value）
如果没有默认值则填充空值（nullable）

后返回给用户。一般来说，在更改模式时（比如 alter table），数据库不允许增加既没有默认值、也不允许为空的列。

经由服务的数据流

通过网络通信时，通常涉及两种角色：服务端（server）和客户端（client）。通常来说，暴露于公网的多为 HTTP 服务，而 RPC 服务常在内部使用。

服务端和客户端只是一个相对的概念。服务端也可以同时是客户端：

作为客户端访问数据库。
作为客户端访问其他服务。我们常把一个大的服务拆成一组功能独立、相对解耦的服务，这就是面向服务的架构（service-oriented architecture，SOA），或者微服务架构（micro-services architecture）。

基于二进制编码的 RPC 通常比基于 HTTP 服务效率更高。但 HTTP 服务，或者更具体一点，Restful API 的好处在于，生态好、有大量的工具支持。而 RPC 的 API 通常和 RPC 框架生成的代码高度相关，因此很难在不同组织中无痛交换和升级。因此，这也是为什么“暴露于公网的多为 HTTP 服务，而 RPC 服务常在内部使用”。