关于buffer:深入浅出FlatBuffers原理

简介：FlatBuffers 是一个开源的、跨平台的、高效的、提供了多种语言接口的序列化工具库。实现了与 Protocal Buffers 相似的序列化格局。次要由 Wouter van Oortmerssen 编写，并由 Google 开源。本文将基于高德地图数据编译增量公布应用了 FlatBuffers 序列化工具，为大家分享 FlatBuffers 的原理。

作者 | 大向
起源 | 阿里技术公众号

FlatBuffers 是一个开源的、跨平台的、高效的、提供了多种语言接口的序列化工具库。实现了与 Protocal Buffers 相似的序列化格局。次要由 Wouter van Oortmerssen 编写，并由 Google 开源。Oortmerssen 最后为 Android 游戏和重视性能的利用而开发了 FlatBuffers，当初它具备 C ++、C#、C、Go、Java、PHP、Python 和 JavaScript 的接口。

高德地图数据编译增量公布应用了 FlatBuffers 序列化工具，借此契机对 FlatBuffers 原理进行钻研并分享于此。本文简略介绍 FlatBuffers Scheme，通过分析 FlatBuffers 序列化与反序列化原理，重点答复以下问题：

问题 1：FlatBuffers 如何做到反序列化速度极快的（或者说无需解码）。
问题 2：FlatBuffers 如何做到默认值不占存储空间的（Table 构造内的变量）。
问题 3：FlatBuffers 如何做到字节对齐的。
问题 4：FlatBuffers 如何做到向前向后兼容的（Struct 构造除外）。
问题 5：FlatBuffers 在 add 字段时有没有程序要求（Table 构造）。
问题 6：FlatBuffers 如何依据 Scheme 主动生成编解码器。
问题 7：FlatBuffers 如何依据 Scheme 主动生成 Json。

FlatBuffers 通过 Scheme 文件定义数据结构，Schema 定义与其余框架应用的 IDL(Interface description language)语言相似简略易懂，FlatBuffers 的 Scheme 是一品种 C 的语言（只管 FlatBuffers 有本人的接口定义语言 Scheme 来定义要与之序列化的数据，但它也反对 Protocol Buffers 中的 .proto 格局）。上面以官网 Tutorial 中的 monster.fbs 为例进行阐明：

// Example IDL file for our monster's schema.
namespace MyGame.Sample;
enum Color:byte {Red = 0, Green, Blue = 2}
union Equipment {Weapon} // Optionally add more tables.
struct Vec3 {
  x:float;
  y:float;
  z:float;
}
table Monster {
  pos:Vec3;
  mana:short = 150;
  hp:short = 100;
  name:string;
  friendly:bool = false (deprecated);
  inventory:[ubyte];
  color:Color = Blue;
  weapons:[Weapon];
  equipped:Equipment;
  path:[Vec3];
}
table Weapon {
  name:string;
  damage:short;
}
root_type Monster;

namespace MyGame.Sample;

namespace 定义命名空间，能够定义嵌套的命名空间，用 . 宰割。

enum Color:byte {Red = 0, Green, Blue = 2};

enum 定义枚举类型。和惯例的枚举类稍有不同的中央是能够定义类型。比方这里的 Color 是 byte 类型。enum 字段只能新增，不能废除。

union Equipment {Weapon} // Optionally add more tables

union 相似 C/C++ 中的概念，一个 union 中能够搁置多种类型，独特应用一个内存区域。这里的应用是互斥的，即这块内存区域只能由其中一种类型应用。绝对 struct 来说比拟节俭内存。union 跟 enum 比拟相似，然而 union 蕴含的是 table，enum 蕴含的是 scalar 或者 struct。union 也只能作为 table 的一部分，不能作 root type。

struct Vect3{x : float; y : float; z : float;};

struct 所有字段都是必填的，因而没有默认值。字段也不能增加或者废除，且只能蕴含标量或者其余 struct。struct 次要用于数据结构不会产生扭转的场景，绝对 table 应用更少的内存，lookup 的时候速度更快（struct 保留在父 table 中，不须要应用 vtable）。

table Monster{};

table 是在 FlatBuffers 中定义对象的次要形式，由一个名称（这里是 Monster）和一个字段列表组成。能够蕴含下面定义的所有类型。每个字段（Field）包含名称、类型和默认值三局部；每个字段都有默认值，如果没有明确写出则默认为 0 或者 null。每个字段都不是必须的，能够为每个对象抉择要省略的字段，这是 FlatBuffers 向前和向后兼容的机制。

root_type Monster;

用于指定序列化后的数据的 root table。

Scheme 设计须要特地留神的：

新字段只能加在 table 的前面。旧代码会疏忽这个字段，依然能够失常执行。新代码读取旧的数据，会取到新增字段的默认值。
即便字段不再应用了也不能从 Scheme 中删除。能够标记为 deprecated，在生成代码的时候不会生成该字段的拜访器。
如果须要嵌套的 vector，能够将 vector 包装在 table 中。string 对于其余编码能够应用 [byte] 或者 [ubyte] 反对。

简略来说 FlatBuffers 就是把对象数据，保留在一个一维的数组中，将数据都缓存在一个 ByteBuffer 中，每个对象在数组中被分为两局部。元数据局部：负责寄存索引。实在数据局部：寄存理论的值。然而 FlatBuffers 与大多数内存中的数据结构不同，它应用严格的对齐规定和字节程序来确保 buffer 是跨平台的。此外，对于 table 对象，FlatBuffers 提供前向 / 后向兼容性和 optional 字段，以反对大多数格局的演变。除了解析效率以外，二进制格局还带来了另一个劣势，数据的二进制示意通常更具备效率。咱们能够应用 4 字节的 UInt 而不是 10 个字符来存储 10 位数字的整数。

FlatBuffers 对序列化根本应用准则：

小端模式。FlatBuffers 对各种根本数据的存储都是依照小端模式来进行的，因为这种模式目前和大部分处理器的存储模式是统一的，能够放慢数据读写的数据。
写入数据方向和读取数据方向不同。

FlatBuffers 向 ByteBuffer 中写入数据的程序是从 ByteBuffer 的尾部向头部填充，因为这种增长方向和 ByteBuffer 默认的增长方向不同，因而 FlatBuffers 在向 ByteBuffer 中写入数据的时候就不能依赖 ByteBuffer 的 position 来标记无效数据地位，而是本人保护了一个 space 变量来指明无效数据的地位，在剖析 FlatBuffersBuilder 的时候要特地留神这个变量的增长特点。然而，和数据的写入方向不同的是，FlatBuffers 从 ByteBuffer 中解析数据的时候又是依照 ByteBuffer 失常的程序来进行的。FlatBuffers 这样组织数据存储的益处是，在从左到右解析数据的时候，可能保障最先读取到的就是整个 ByteBuffer 的概要信息（例如 Table 类型的 vtable 字段），不便解析。

对于每种数据类型的序列化：

标量类型即根本类型，如：int，double，bool 等，标量类型应用间接寻址进行数据拜访。

示例：short mana = 150; 12 个字节，存储构造如下：

schema 中定义标量能够设置默认值。文章最后提到 FlatBuffers 的默认值不占存储空间的，对于 table 外部的标量，是能够做到默认值不存储的，如果变量的值不须要扭转，该字段在 vtable 中对应的 offset 的值设置为 0 即可，默认值被记录在解码接口内，解码时获取该字段的 offset 为 0 时，解码接口则返回默认值。对于 struct 构造因为没有应用 vtable 构造，因而外部的标量没有默认值，必须存储（struct 类型和 table 类型的序列化原理在下文会具体阐明）。

// Computes how many bytes you'd have to pad to be able to write an
// "scalar_size" scalar if the buffer had grown to "buf_size" (downwards in
// memory).
inline size_t PaddingBytes(size_t buf_size, size_t scalar_size) {return ((~buf_size) + 1) & (scalar_size - 1);
}

标量数据类型是按其自身字节数大小进行对齐。通过 PaddingBytes 函数计算，所有标量都会调用这个函数，进行字节对齐。

除了根本类型之外，FlatBuffers 中只有 Struct 类型应用间接寻址进行数据拜访。FlatBuffers 规定 Struct 类型用于存储那些约定成俗、永不扭转的数据，这种类型的数据结构一旦确定便永远不会扭转，没有任何字段是可选的（也没有默认值），字段可能不会被增加或被弃用，所以 structs 不提供前向 / 后向兼容性。在这个规定之下，为了进步数据访问速度，FlatBuffers 独自对 Struct 应用了间接寻址的形式。字段的程序即为存储的程序。struct 有的个性个别不作为 schema 文件的根。

示例：struct Vec3(16, 17, 18); 12 个字节

struct 定义了一个固定的内存布局，其中所有字段都与其大小对齐，并且 struct 与其最大标量成员对齐。

vector 类型实际上就是 schema 中申明的数组类型，FlatBuffers 中也没有独自的类型和它对应，然而它却有本人独立的一套存储构造，在序列化数据时先会从高位到低位顺次存储 vector 外部的数据，而后再在数据序列化结束后写入 Vector 的成员个数。数据存储构造如下：

示例：byte[] treasure = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};

vector size 的类型为 int，因而在初始化申请内存时 vector 进行四字节字节对齐。

FlatBuffers 字符串依照 utf-8 的形式进行了编码，在实现字符串写入的时候将字符串的编码数组当做了一维的 vector 来实现。string 实质上也能够看做是 byte 的 vector，因而创立过程和 vector 基本一致，惟一的区别就是字符串是以 null 结尾，即最初一位是 0。string 写入数据的构造如下：

示例：string name =“Sword”;

vector size 的类型为 int，因而在初始化申请内存时字符串进行四字节字节对齐。

Union 类型比拟非凡，FlatBuffers 规定这个类型在应用上具备如下两个限度：

Union 类型的成员只能是 Table 类型。
Union 类型不能是一个 schema 文件的根。

FlatBuffers 中没有特定类型示意 union，而是会生成一个独自的类对应 union 的成员类型。与其余类型的次要区别是须要先指定类型，在序列化 Union 的时候个别先写入 Union 的 type，而后再写入 Union 的数据偏移；在反序列化 Union 的时候个别先
析出 Union 的 type，而后再依照 type 对应的 Table 类型来解析 Union 对应的数据。

FlatBuffers 中的 enum 类型在数据存储的时候是和 byte 类型存储的形式一样的。因为和 Union 类型类似，enum 类型在 FlatBuffers 中也没有独自的类与它对应，在 schema 中申明为 enum 的类会被编译生成独自的类。

enum 类型不能是一个 schema 文件的根。

table 是 FlatBuffers 的基石，为了解决数据结构变更的问题，table 通过 vtable 间接拜访字段。每个 table 都带有一个 vtable（能够在具备雷同布局的多个 table 之间共享），并且蕴含存储此特定类型 vtable 实例的字段的信息。vtable 还可能表明该字段不存在（因为此 FlatBuffers 是应用旧版本的代码编写的，仅仅因为信息对于此实例不是必须的，或者被视为已弃用），在这种状况下会返回默认值。

table 的内存开销很小（因为 vtables 很小并且共享）拜访老本也很小（间接拜访），然而提供了很大的灵活性。table 在非凡状况下可能比等价的 struct 破费更少的内存，因为字段在等于默认值时不须要存储在 buffer 中。这样的构造决定了一些简单类型的成员都是应用绝对寻址进行数据拜访的，即先从 Table 中取到成员常量的偏移，而后依据这个偏移再去常量真正存储的地址去取实在数据。

单就构造来讲：首先能够将 Table 分为两个局部，第一局部是存储 Table 中各个成员变量的概要，这里命名为 vtable，第二局部是 Table 的数据局部，存储 Table 中各个成员的值，这里命名为 table_data。留神 Table 中的成员如果是简略类型或者 Struct 类型，那么这个成员的具体数值就间接存储在 table_data 中；如果成员是简单类型，那么 table_data 中存储的只是这个成员数据绝对于写入地址的偏移，也就是说要取得这个成员的真正数据还要取出 table_data 中的数据进行一次绝对寻址。

vtable 是一个 short 类型的数组，其长度为（字段个数 +2）* 2 字节，第一个字段是 vtable 的大小，包含这个大小自身；第二个字段是 vtable 对应的对象的大小，包含到 vtable 的 offset；接下来是每个字段绝对于对象开始地位的 offset。
table_data 的结尾是 vtable 开始地位减去以后 table 对象开始地位的 INT 型 offset，因为 vtable 可能在任意的中央，这个值有可能是负值。table_data 开始用 int 存储了 vtable 的 offset，因而进行了四字节对齐的。

add 的操作是增加 table_data，因为 Table 数据结构的是通过 vtable – table_data 机制存储的，这个操作没有强制要求字段的先后顺序，对程序没有要求，因为 vtable 在记录每个字段绝对于对象开始地位的 offset 时是依照 schema 中定义的程序进行存储的，所以在 add 字段的时候即便没有程序也能够依据 offset 获取正确的值。须要留神的是，每次 add 字段时 FlatBuffers 都会做字节对齐解决。

std::string e_poiId = "1234567890";
double e_coord_x = 0.1; 
double e_coord_y = 0.2;
int e_minZoom = 10;
int e_maxZoom = 200;

//add
featureBuilder.add_poiId(nameData);
featureBuilder.add_x(e_coord_x);
featureBuilder.add_y(e_coord_y);
featureBuilder.add_maxZoom(e_maxZoom);
featureBuilder.add_minZoom(e_minZoom);
auto rootData = featurePoiBuilder.Finish();
flatBufferBuilder.Finish(rootData);
blob = flatBufferBuilder.GetBufferPointer();
blobSize = flatBufferBuilder.GetSize();

add 程序 1：最终二进制的大小为 72 字节。

std::string e_poiId = "1234567890";
double e_coord_x = 0.1; 
double e_coord_y = 0.2;
int e_minZoom = 10;
int e_maxZoom = 200;

//add
featureBuilder.add_poiId(nameData);
featureBuilder.add_x(e_coord_x);
featureBuilder.add_minZoom(e_minZoom);
featureBuilder.add_y(e_coord_y);
featureBuilder.add_maxZoom(e_maxZoom);
auto rootData = featurePoiBuilder.Finish();
flatBufferBuilder.Finish(rootData);
blob = flatBufferBuilder.GetBufferPointer();
blobSize = flatBufferBuilder.GetSize();

add 程序 2：最终二进制的大小为 80 字节。

add 程序 1 和 add 程序 2 对应的 schema 文件一样，表白的数据也一样，Table 构造在 add 字段时有没有程序要求。序列化后的数据大小差 8 个字节，起因就是字节对齐导致的。因而 add 字段的时候，尽量把雷同类型的字段放在一起进行 add，这样会防止不必要的字节对齐，获取更小的序列化后果。

FlatBuffers 的向前向后兼容指的是 table 构造。table 构造每个字段都有默认值，如果没有明确写出则默认为 0 或者 null。每个字段都不是必须的，能够为每个对象抉择要省略的字段，这是 FlatBuffers 向前和向后兼容的机制。须要留神的是：

新的字段只能加在 table 的前面。旧的代码会疏忽这个字段，依然能够失常执行。新的代码读取旧的数据，新增的字段会返回默认值。
即便字段不再应用了也不能从 schema 中删除。能够标记为 deprecated，在生成代码的时候该字段不会生成该字段的接口。

FlatBuffers 反序列化的过程就很简略了。因为序列化的时候保留好了各个字段的 offset，反序列化的过程其实就是把数据从指定的 offset 中读取进去。反序列化的过程是把二进制流从 root table 往后读。从 vtable 中读取对应的 offset，而后在对应的 object 中找到对应的字段，如果是援用类型，string / vector / table，读取出 offset，再次寻找 offset 对应的值，读取进去。如果是非援用类型，依据 vtable 中的 offset，找到对应的地位间接读取即可。对于标量，分 2 种状况，默认值和非默认值。默认值的字段，在读取的时候，会间接从 flatc 编译后的文件中记录的默认值中读取进去。非默认值字段，二进制流中就会记录该字段的 offset，值也会存储在二进制流中，反序列化时间接依据 offset 读取字段值即可。

整个反序列化的过程零拷贝，不耗费占用任何内存资源。并且 FlatBuffers 能够读取任意字段，而不是像 Json 和 protocol buffer 须要读取整个对象当前能力获取某个字段。FlatBuffers 的次要劣势就在反序列化这里了。所以 FlatBuffers 能够做到解码速度极快，或者说无需解码间接读取。

FlatBuffers 的自动化包含主动生成编码解码接口和主动生成 Json，自动化生成编解码接口和主动生成 Json，都依赖 schem 的解析。

FlatBuffers 形容文件解析器按游标的形式程序进行辨认 FlatBuffers 反对的数据结构。获取字段名称、字段类型、字段默认值、是否弃用等属性。反对关键字：标量类型、非标量类型、include、namespace、root_type。

如果须要嵌套的 vector，能够将 vector 包装在 table 中。

FlatBuffers 应用模板编程，编码解码接口仅生成 h 文件。实现数据结构的定义，并特化出变量的 Add 函数、Get 函数，校验函数接口。对应的文件名为 filename_generated.h。

FlatBuffers 的次要指标是防止反序列化。通过定义二进制数据协定来实现的，一种将定义好的将数据转换为二进制数据的办法。由该协定创立的二进制构造无需进一步解码即可读取。因而在主动生成 json 时，只须要提供二进制数据流和二进制定义构造就能够读物数据，转换成 json。

Json 构造与 FlatBuffers 构造保持一致。
默认值不输入 Json。

解码速度极快，将序列化数据存储在缓存中，这些数据既能够写出至文件中，又能够通过网络原样传输，也可间接读取而没有任何解析开销，拜访数据时的惟一内存需要就是缓冲区，不须要额定的内存调配。
扩展性、灵活性：它反对的可选字段意味着具备很好的前向 / 后向兼容。FlatBuffers 反对选择性地写入数据成员，这不仅为某一个数据结构在利用的不同版本之间提供了兼容性，同时还能使程序员灵便地抉择是否写入某些字段及灵便地设计传输的数据结构。
跨平台：反对 C++11、Java，而不须要任何依赖库，在最新的 gcc、clang、vs2010 等编辑器上也工作良好。应用简略不便，仅仅须要主动生成的大量代码和一个繁多的头文件依赖，很容易集成到现有零碎中，生成的 C++ 代码提供了简略的拜访和结构接口，能够兼容 Json 等其余格局的解析。

数据无可读性，必须进行数据可视化能力了解数据。
向后兼容性局限，在 schema 中增加或删除字段必须小心。

相比其它的序列化工具，FlatBuffers 最大的劣势是反序列化速度极快，或者说无需解码。如果应用场景是须要常常解码序列化的数据，则有可能从 FlatBuffers 的个性取得肯定的益处。

原文链接
本文为阿里云原创内容，未经容许不得转载。

关于buffer:深入浅出FlatBuffers原理

一前言

二 FlatBuffers Scheme

三 FlatBuffers 的序列化

1 标量类型

2 Struct 类型

3 vector 类型

4 String 类型

5 Union 类型

6 Enum 类型

7 Table 类型

四 FlatBuffers 的反序列化

五 FlatBuffers 的自动化

1 schema 形容文件解析

2 主动生成编码解码接口

3 主动生成 Json

六 FlatBuffers 的优缺点

1 长处

2 毛病

七总结

一 前言