这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天 在一些 request 和 response 数据较大的服务中，序列化和反序列化的代价较高，有两种优化思路：
- 如前文所述进行序列化和反序列化的优化
- 以无拷贝序列化的方式进行调用
通过无拷贝序列化进行 RPC 调用，最早出自 Kenton Varda 的 Cap'n Proto 项目，Cap'n Proto 提供了一套数据交换格式和对应的编解码库。
Cap'n Proto 本质上是开辟一个 bytes slice 作为 buffer ，所有对数据结构的读写操作都是直接读写 buffer，读写完成后，在头部添加一些 buffer 的信息就可以直接发送，对端收到后即可读取，因为没有 Go 语言结构体作为中间存储，所有无需序列化这个步骤，反序列化亦然。
简单总结下 Cap'n Proto 的特点：
-
所有数据的读写都是在一段连续内存中
-
将序列化操作前置，在数据 Get/Set 的同时进行编解码
-
在数据交换格式中，通过 pointer（数据存储位置的 offset）机制，使得数据可以存储在连续内存的任意位置，进而使得结构体中的数据可以以任意顺序读写
-
对于结构体的固定大小字段，通过重新排列，使得这些字段存储在一块连续内存中
-
对于结构体的不定大小字段（如 list），则通过一个固定大小的 pointer 来表示，pointer 中存储了包括数据位置在内的一些信息。
首先 Cap'n Proto 没有 Go 语言结构体作为中间载体，得以减少一次拷贝，然后 Cap'n Proto 是在一段连续内存上进行操作，编码数据的读写可以一次完成，因为这两个原因，使得 Cap' Proto 的性能表现优秀。
反序列化）+读出数据，视包大小，Cap'n Proto 性能大约是 Thrift 的 8-9 倍。写入数据+（序列化），视包大小，Cap'n Proto 性能大约是 Thrift 的 2-8 倍。整体性能 Cap' Proto 性能大约是 Thrift 的 4-8 倍。
前面说了 Cap'n Proto 的优势，下面总结一下 Cap'n Proto 存在的一些问题：
- Cap'n Proto 的连续内存存储这一特性带来的一个问题：当对不定大小数据进行 resize ，且需要的空间大于原有空间时，只能在后面重新分配一块空间，导致原来数据的空间成为了一个无法去掉的 hole 。这个问题随着调用链路的不断 resize 会越来越严重，要解决只能在整个链路上严格约束：尽量避免对不定大小字段的 resize ，当不得不 resize 的时候，重新构建一个结构体并对数据进行深拷贝。
- Cap'n Proto 因为没有 Go 语言结构体作为中间载体，使得所有的字段都只能通过接口进行读写，用户体验较差。
Thrift 协议兼容的无拷贝序列化
Cap'n Proto 为了更好更高效地支持无拷贝序列化，使用了一套自研的编解码格式，但在现在 Thrift 和 ProtoBuf 占主流的环境中难以铺开。为了能在协议兼容的同时获得无拷贝序列化的性能，我们开始了 Thrift 协议兼容的无拷贝序列化的探索。
Cap'n Proto 作为无拷贝序列化的标杆，那么我们就看看 Cap'n Proto 上的优化能否应用到 Thrift 上：
- 自然是无拷贝序列化的核心，不使用 Go 语言结构体作为中间载体，减少一次拷贝。此优化点是协议无关的，能够适用于任何已有的协议，自然也能和 Thrift 协议兼容，但是从 Cap'n Proto 的使用上来看，用户体验还需要仔细打磨一下。
- Cap'n Proto 是在一段连续内存上进行操作，编码数据的读写可以一次完成。Cap'n Proto 得以在连续内存上操作的原因：有 pointer 机制，数据可以存储在任意位置，允许字段可以以任意顺序写入而不影响解码。但是一方面，在连续内存上容易因为误操作，导致在 resize 的时候留下 hole，另一方面，Thrift 没有类似于 pointer 的机制，故而对数据布局有着更严格的要求。这里有两个思路：
- 坚持在连续内存上进行操作，并对用户使用提出严格要求：1. resize 操作必须重新构建数据结构 2. 当存在结构体嵌套时，对字段写入顺序有着严格要求（可以想象为把一个存在嵌套的结构体从外往里展开，写入时需要按展开顺序写入），且因为 Binary 等 TLV 编码的关系，在每个嵌套开始写入时，需要用户主动声明（如 StartWriteFieldX）。
- 不完全在连续内存上操作，局部内存连续，可变字段则单独分配一块内存，既然内存不是完全连续的，自然也无法做到一次写操作便完成输出。为了尽可能接近一次写完数据的性能，我们采取了一种链式 buffer 的方案，一方面当可变字段 resize 时只需替换链式 buffer 的一个节点，无需像 Cap'n Proto 一样重新构建结构体，另一方面在需要输出时无需像 Thrift 一样需要感知实际的结构，只要把整个链路上的 buffer 写入即可。
