一、序列化协议
Thrift可以让你选择客户端与服务端之间传输通信协议的类别,在传输协议上总体上划分为文本(text)和二进制(binary)传输协议, 为节约带宽,提供传输效率,一般情况下使用二进制类型的传输协议为多数,但有时会还是会使用基于文本类型的协议,这需要根据项目/产品中的实际需求(例如:调试的时候)。
序列化协议类型:
TBinaryProtocol:二进制编码格式进行数据传输。
TCompactProtocol:高效密集型的二进制序列化协议,使用Variable-Length Quantity (VLQ) 编码对数据进行压缩。
TJSONProtocol:使用JSON的数据编码协议进行数据传输。
TSimpleJSONProtocol:这种节约只提供JSON只写的协议,适用于通过脚本语言解析。
TTupleProtocol(继承自TCompactProtocol)
TDebugProtocol:在开发的过程中帮助开发人员调试用的,以文本的形式展现方便阅读。
RPC框架中一般使用 TCompactProtocol。
二、传输层
Thrift中所有的传输层协议的基类是TTransport。另外,需要说明的一点是,thrift是基于TCP协议的。
传输协议类型:
TSocket:使用堵塞式I/O进行传输,也是最常见的模式。
TFramedTransport:使用非阻塞方式,以frame为单位进行传输,类似于Java中的NIO。
TFileTransport:以文件形式进行传输,虽然这种方式不提供Java的实现,但是实现起来非常简单。
TMemoryTransport:使用内存I/O,如Java中的ByteArrayOutputStream实现。
TZlibTransport:使用执行zlib压缩,与其他传输方式联合使用,不提供Java的实现。
TNonblockingTransport:使用非阻塞方式,用于构建异步客户端。
RPC框架中一般使用 TFramedTransport。
三、Thrift的序列化和反序列化方式
步骤:
使用IDL创建thrift接口定义文件;
将thrift的定义文件转换为对应语言的源代码;
选择相应的protocol,进行序列化和反序列化;
四、TCompactProtocol与TBinaryProtocol的原理和区别
Thrift二进制序列化协议中,默认为TBinaryProtocol,关于TCompactProtocol的说明,为高效密集型的二进制序列化(varint)。
那么TCompactProtocol相对于TBinaryProtocol是怎样做到高效密集的呢?TCompactProtocol是否一定比TBinaryProtocol高效?
我们以比较常用的i32类型为例,来解释一下两种方式各自的原理:
TBinaryProtocol
处理i32整型数据类型时,定义的是4个字节的数组,32位的长度正好可以保存到这4个字节组当中。如果我们分别以n1~n32来表示第1位到第32位,那么这个数组的数据结构应该为以下结构:
i32out[0] {n1 ~ n8 }
i32out[1] {n9 ~ n16}
i32out[2] {n17 ~ n24}
i32out[3] {n25 ~ n32}
这样的实现很简单.
对于其它类型,比如i16,也是类似的原理,不过是以2个字节的数组保存,在此不再说明了。
因为我们架构中使用的是TCompactProtocol,所以我们需要重点了解一下该协议的序列化方式。
TCompactProtocol
在处理i32整型数据类型时,与TBinaryProtocol完全不同,采用的是1~5个字节组来保存。依然以n1~n32来表示第1位到第32位,数据结构应该为以下结构:
i32out[0] {1 , 0 , 0 , 0 , n1 ~ n4}
i32out[1] {1 , n5 ~ n11}
i32out[2] {1 , n12 ~ n18}
i32out[3] {1 , n19 ~ n25}
i32out[4] {0 , n26 ~ n32}
这是一种极端情况,5个字节全部占满。
很显然,这样做比TBinaryProtocol复杂得多,而且还多了1个字节,并没有达到密集的目的。那是不是说明TBinaryProtocol更好?
先不急着下结论,举个具体一点的例子来说明两种实现的区别。
假如我们需要序列化一个十进制数值'10',那么它的二进制表示方式应该为'1010',只用了4位,但i32会在前面自动补0,
则是:'00000000000000000000000000001010',那么如果使用TBinaryProtocol方式来保存,则应该为以下结构:
i32out[0] {0 , 0 , 0 , 0 , 0 , 0 , 0 , 0}
i32out[1] {0 , 0 , 0 , 0 , 0 , 0 , 0 , 0}
i32out[2] {0 , 0 , 0 , 0 , 0 , 0 , 0 , 0}
i32out[3] {0 , 0 , 0 , 0 , 1 , 0 , 1 , 0}
这样有什么问题呢?那就是大量补足的0占用了宝贵空间。
接着我们再来看看TCompactProtocol会怎样保存'10'这个数值:
i32out[0] {0 , 0 , 0 , 0 , 1 , 0 , 1 , 0}
TCompactProtocol只用了1个字节,而TBinaryProtocol依然用了4个字节。这就是为什么说TCompactProtocol高效密集型的二进制序列化的原因。
TCompactProtocol的保存规则
TCompactProtocol每个字节的第1位是状态位,第2位到第8位保存具体的数据.
这有别于TBinaryProtocol的1到8位全部保存具体数据。这也是为什么极端情况下TCompactProtocol比TBinaryProtocol多占1个字节的原因。
TCompactProtocol的字节中第1位状态位的意思是标记此字节后是否还有数据。1为有数据,0为没有数据.
为了更容易理解,我们再举一个例子,用TCompactProtocol来序列化十进制数值'300',二进制应该为'100101100',用TCompactProtocol方式来保存则为如下结构:
i32out[0] {1 , 0 , 0 , 0 , 0 , 0 , 1 , 0}
i32out[1] {0 , 0 , 1 , 0 , 1 , 1 , 0 , 0}
这里将'100101100'拆分为了2部分,'10'和'0101100',在i32out[0]中保存了'10',并在第1位记为'1'来表示后面还有数据,第7位和第8位保存'10',不足的几位(第2位到第6位)补0;
所以i32out[0]为'10000010',在i32out[1]中保存了后面的'0101100',并在第1位记为'0'来表示后面没有了,则第1位为'0',所以i32out[1]为'00101100'。
TCompactProtocol以这样的原理来达到压缩的目的。
thrift 文件:
namespace java mmxf.thrift;
struct Pair {
1: required string key
2: required string value
}
"1", "2" 这些数字标识符究竟有何含义? 它在序列化机制中究竟扮演什么样的角色?
thrift官网描述:thrift的向后兼容性(Version)借助属性标识(数字编号id + 属性类型type)来实现, 可以理解为在序列化后(属性数据存储由 field_name:field_value => id+type:field_value)。
所以,id很重要,一旦id顺序混淆或者有变化,value值与name的对应也会变换,name在其中并没有映射作用。
注意:RPC服务数据发送方(生产者)和读取方(消费者)如果同样的字段name,id不同,获取到的value是不一致的,会出现不同name的value互换的奇怪现象。
数据交换格式分类
当前的数据交换格式可以分为如下几类:
1. 自解析型
序列化的数据包含完整的结构,包含了field名称和value值. 比如xml/json/java serizable,百度的mcpack/compack, 都属于此类. 即调整不同属性的顺序对序列化/反序列化不影响。
2. 半解析型
序列化的数据,丢弃了部分信息,比如field名称,但引入了index(常常是id+type的方式)来对应具体属性和值。这方面的代表有google protobuf,thrift也属于此类。
3. 无解析型
传说中百度的infpack实现,就是借助该种方式来实现,丢弃了很多有效信息,性能/压缩比最好,不过向后兼容需要开发做一定的工作,详情不知。