第1部分?messagepack說明

1.1messagepack的消息編碼說明

為什么messagepack比json序列化使用的字節流更少，?可通過圖1-1、圖1-2有個直觀的感覺。

?

?

圖1-?1?messagepack與json的格式對比1

?

圖1-?2?messagepack與json的格式對比2

messagepack的具體的消息格式如圖1-3所示，messagepack的數據類型主要分類兩類：固定長度類型和可變長度類型。

?

圖1-?3?messagepack的消息格式

messagepack的具體類型信息表示如圖1-4所示。

?

?

圖1-?4?messagepack的類型信息

1.2?messagepack的序列化和反序列化方式

現在msgpack能支持基本的數據類型，支持list和map，?還支持自定義的數據類型。例子1，?序列化和反序列化一個javabean，?只要加上@MessagePackMessage的注解。

?

Java代碼??

/**?

?*?一個用于messagepack測試序列化和反序列的javabean?

?*??

?*?@author?jimmee?

?*/??

@MessagePackMessage???

public?class?Person?{??

/**?編號?*/??

public?int?id;??

/**?名字?*/??

public?String?name;??

/**身高*/??

public?double?height;??

/**?

?*?默認構造函數?

?*/??

public?Person()?{??

}??

?

?

?

序列化直接調用MessagePack的pack方法；反序列化則調用對應的unpack方法。這兩個方法，都支持傳遞序列化和反序列化的數據類型。

1.3?與json的序列化性能對比

如下所示，通過100條數據的序列化和反序列化進行對比。

?

Java代碼??

List<Map>?msgs?=?new?ArrayList<Map>();??

for?(int?i?=?0;?i?<?100;?i++)?{??

Map?msg?=?new?HashMap();??

msg.put(Const.FID,?i);??

msg.put(Const.SUBJECT,?"subject"?+?i);??

msg.put(Const.LABEL0,?1);??

msg.put(Const.FROM,?"test@163.com");??

msg.put(Const.TO,?"test@126.com");??

msg.put(Const.MODIFIED_DATE,?new?Date().getTime());??

msg.put(Const.RECEIVED_DATE,?new?Date().getTime());??

msg.put(Const.SENT_DATE,?new?Date().getTime());??

msgs.add(msg);??

????}??

?

?

比較結果如表1-1所示。

表1-?1?messagepack與json的性能對比

框架	字節大小（byte）	序列化時間（ns）	反序列化時間（ns）
messagepack	12793	2313335	529458
json	17181	?1338371	1776519

?

可以看出，messagepack的序列化字節數比json小將近30%；序列化時間messagepack差不多是json的兩倍；反序列化時間，messagepack只需要json的30%的時間。

但是，值得注意的是，雖然messagepack的反序列化時間比較少，但是要真正轉換為前端需要的類型參數格式，還需要額外的一些時間。

第2部分?protocol?buffers

2.1?protocol?buffers的消息編碼說明

Protocol?Buffers支持的數據類型如下圖所示：

??

圖2-?1?protocol?buffers支持的數據類型。

首先對Varint進行說明。Varint?是一種緊湊的表示數字的方法。它用一個或多個字節來示一個數字，值越小的數字使用越少的字節數。這能減少用來表示數字的字節數。

比如對于?int32?類型的數字，一般需要?4?個?byte?來表示。但是采用?Varint，對于很小的?int32?類型的數字，則可以用?1?個?byte?來表示。當然，采用?Varint?表示法，大的數字則需要?5?個?byte?來表示。從統計的角度來說，一般不會所有的消息中的數字都是大數，因此大多數情況下，采用?Varint?后，可以用更少的字節數來表示數字信息。

Varint?中的每個?byte?的最高位?bit?有特殊的含義，如果該位為?1，表示后續的?byte?也是該數字的一部分，如果該位為?0，則結束。其他的?7?個?bit?都用來表示數字。因此小于?128?的數字都可以用一個?byte?表示。大于?128?的數字，比如?300，會用兩個字節來表示：1010?1100?0000?0010。

圖2-2說明了?Google?Protocol?Buffer?如何解析兩個?bytes。注意到最終計算前將兩個?byte?的位置相互交換過一次，這是因為?Google?Protocol?Buffer?字節序采用?little-endian?的方式。

??

圖2-?2?protocol?buffers解析兩個字節

消息經過序列化后會成為一個二進制數據流，該流中的數據為一系列的?Key-Value?對，如圖2-3所示。

??

圖2-?3?protocol?buffers的消息流

采用這種?Key-Pair?結構無需使用分隔符來分割不同的?Field。對于可選的?Field，如果消息中不存在該?field，那么在最終的?Message?Buffer?中就沒有該?field，這些特性都有助于節約消息本身的大小。

假設我們生成如下的一個消息Message：

?Message.id?=?5;? ?Message.info?=?“hello”；

則最終的?Message?Buffer?中有兩個?Key-Value?對，一個對應消息中的?id；另一個對應?info。

Key?用來標識具體的?field，在解包的時候，Protocol?Buffer?根據?Key?就可以知道相應的?Value?應該對應于消息中的哪一個?field。

Key?的定義如下：

?(field_number?<<?3)?|?wire_type?

可以看到?Key?由兩部分組成。第一部分是?field_number。第二部分為?wire_type。表示?Value?的傳輸類型。

wire?type如表2-1所示。

表2-?1?wire?type說明

Type?	Meaning?	Used?For?
0?	Varint?	int32,?int64,?uint32,?uint64,?sint32,?sint64,?bool,?enum?
1?	64-bit?	fixed64,?sfixed64,?double?
2?	Length-delimited?	string,?bytes,?embedded?messages,?packed?repeated?fields?
3?	Start?group?	Groups?(deprecated)?
4?	End?group?	Groups?(deprecated)?
5?	32-bit?	fixed32,?sfixed32,?float?

?

在計算機內，一個負數一般會被表示為一個很大的整數，因為計算機定義負數的符號位為數字的最高位。如果采用?Varint?表示一個負數，那么一定需要?5?個?byte。為此?Google?Protocol?Buffer?定義了?sint32，sint64?類型，采用?zigzag?編碼。

Zigzag?編碼用無符號數來表示有符號數字，正數和負數交錯，如圖2-3所示。使用?zigzag?編碼，絕對值小的數字，無論正負都可以采用較少的?byte?來表示，充分利用了?Varint?這種技術。

??

圖2-?4?ZigZag編碼

2.2?protocol?buffers的序列化和反序列化

步驟：

創建消息的定義文件.proto；

使用protoc工具將proto文件轉換為相應語言的源碼；

使用類庫支持的序列化和反序列化方法進行操作。

?

以同樣的數據的操作為例：

1.?定義proto文件messages.ptoto

?

Java代碼??

message?MessageMeta?{??

??required?int32?id?=?1;??

??required?string?subject?=?2;????

optional?int32?lablel0?=?3;??

required?string?from?=?4;??

required?string?to?=?5;??

optional?int64?modifiedDate?=?6;??

optional?int64?receivedDate?=?7;??

optional?int64?sentDate?=?8;??

}??

?

?

?

?

Java代碼??

message?MessageMetas?{??

repeated?MessageMeta?msg?=?1;??

}??

?

?

2.?將message.proto文件轉換為java語言的源碼

例如，?執行命令：protoc?-I=src?--java_out=out?src/messages.proto產生Messages的java文件。

3.?執行序列化和反序列化

?

Java代碼??

MessageMetas.Builder?msgsBuilder?=?MessageMetas.newBuilder();??

for?(int?i?=?0;?i?<?100;?i++)?{??

MessageMeta.Builder?msgBuilder?=?MessageMeta.newBuilder();??

msgBuilder.setId(i);??

msgBuilder.setSubject("subject"?+?i);??

msgBuilder.setLablel0(1);??

msgBuilder.setFrom("test@163.com");??

msgBuilder.setTo("test@126.com");??

msgBuilder.setModifiedDate(new?Date().getTime());??

msgBuilder.setReceivedDate(new?Date().getTime());??

msgBuilder.setSentDate(new?Date().getTime());??

msgsBuilder.addMsg(msgBuilder.build());??

}??

MessageMetas?msgs?=?msgsBuilder.build();??

?

?

之后調用相應的writeTo方法進行序列化，?調用parseFrom進行反序列化。

2.3?與json等的性能對比

表2-?2?性能對比表格

框架	字節大小（byte）	序列化時間（ns）	反序列化時間（ns）
messagepack	12793	2313335	529458
protocol?buffers	6590	941790	408571
json	17181	?1338371	1776519

?

可以看出，protocol?buffers在字節流，序列化時間和反序列化時間方面都明顯較優（即空間和時間上都比較好）。

第3部分?thrift

thrift的架構如圖3-1所示。圖3-1顯示了創建server和client的stack。最上面的是IDL，然后生成Client和Processor。紅色的是發送的數據。protocol和transport?是Thrift運行庫的一部分。通過Thrift?你只需要關心服務的定義，而不需要關心protocol和transport。

Thrift支持?text?和?binary?protocols，binary?protocols要比text?protocols，但是有時候?text?protocols比較有用（例如：調試的時候）。支持的協議有：

TBinaryProtocol?：直接的二進制格式

TCompactProtocol?：效率和高壓縮編碼數據

TDenseProtocoal?：?和TCompactProtocol相似，但是省略了meta信息，從哪里發送的，增加了receiver。還在實驗中，java實現還不可用。

TJSONProtocoal：使用JSON

TSImpleJSONProtocoal?：只寫的protocol使用JSON。適合被腳本語言轉化

TDebugProtocoal：使用人類可讀的text?格式?幫助調試

??

圖3-?1?thrift架構圖

上面的protocol?說明了傳送的是什么樣的數據，Thrift?的transports?則說明了怎樣傳送這些數據。支持的transport：

TSocket?：使用?blocking?socket?I/O；

TFramedTransport?：以幀的形式發送，每幀前面是一個長度。要求服務器來non-blocking?server；

TFileTransport?：寫到文件；

TMemoryTransport?：使用內存?I/O?，java實現中在內部使用了ByteArrayOutputStream；

TZlibTransport?壓縮?使用zlib，在java實現中還不可用。

最后，thrift?提供了servers：

TSimpleServer?：單線程server，使用標準的blocking?IO，用于測試；

TThreadPoolServer：多線程server?，使用標準的blocking?IO；

TNonblockingServer??多線程?server，使用?non-blocking?IO?（java實現中使用了NIO?channels），TFramedTransport必須使用在這個服務器。

一個server只允許定義一個接口服務。這樣的話多個接口需要多個server。這樣會帶來資源的浪費。通常可以通過定義一個組合服務來解決。

3.1?thrift的消息編碼說明

1.?支持的數據類型

所有編程語言中都可用的關鍵類型。

bool?布爾值，真或假

byte?有符號字節

i16??16位有符號整數

i32??32位有符號整數

i64??64位有符號整數

double?64位浮點數

string?與編碼無關的文本或二進制字符串

可基于基本類型定義結構體，例如：

?

Java代碼??

struct?Example?{??

1:i32?number=10,??

2:i64?bigNumber,??

3:double?decimals,??

4:string?name="thrifty"??

}??

?

?

支持的容器有list<type>，set<type>和Map<type1,type2>。

若使用TCompactProtocol，傳遞的消息形式如圖3-2所示：

?

?

圖3-?2?thrift的compact方式的消息流

在這種方式下，對整數而言，也是采用可變長度的方式進行實現。一個字節，最高位表示是否還有數據，低7位是實際的數據，如圖3-3所示，?整數106903的編碼，?相比普通的int類型，節省一個字節。

??

圖3-?3?compact方式對一個整數106903進行編碼

3.2thrift的序列化和反序列化方式

步驟：

創建thrift接口定義文件；

將thrift的定義文件轉換為對應語言的源代碼；

選擇相應的protocol，進行序列化和反序列化。

仍以同樣的數據對象為例子：

定義thrift文件messages.thrift

?

Java代碼??

struct?MessageMeta?{??

??1:i32?id;??

??2:string?subject;????

3:i32?lablel0;??

4:string?from;??

5:string?to;??

6:i64?modifiedDate;??

7:i64?receivedDate;??

8:i64?sentDate;??

}??

???

struct?MessageMetas?{??

1:list<MessageMeta>?msgs;??

}??

?

?

?

2.?將定義的文件轉換成相應的java源碼

執行命令：thrift?-gen?java?messages.thrift

3.?執行序列化和反序列化

?

Java代碼??

MessageMetas?msgs?=?new?MessageMetas();??

List<MessageMeta>?msgList?=?new?ArrayList<MessageMeta>();??

for?(int?i?=?0;?i?<?100;?i++)?{??

MessageMeta?msg?=?new?MessageMeta();??

msg.setId(i);??

msg.setSubject("subject"?+?i);??

msg.setLablel0(1);??

msg.setFrom("test@163.com");??

msg.setTo("test@126.com");??

msg.setModifiedDate(new?Date().getTime());??

msg.setReceivedDate(new?Date().getTime());??

msg.setSentDate(new?Date().getTime());??

msgList.add(msg);??

}??

msgs.setMsgs(msgList);??

//?序列化??

ByteArrayOutputStream?out?=?new?ByteArrayOutputStream();??

TTransport?trans?=?new?TIOStreamTransport(out);??

TBinaryProtocol?tp?=?new?TBinaryProtocol(trans);??

msgs.write(tp);??

???

byte?[]?buf?=?out.toByteArray();??

//?反序列化??

ByteArrayInputStream?in?=?new?ByteArrayInputStream(buf);??

trans?=?new?TIOStreamTransport(in);??

tp?=?new?TBinaryProtocol(trans);??

MessageMetas?msgs2?=?new?MessageMetas();??

msgs2.read(tp);??

?

?

3.3與json等的性能對比

表3-?1?性能對比

框架	字節大小（byte）	序列化時間（ns）	反序列化時間（ns）
messagepack	12793	2313335	529458
protocol?buffers	6590	941790	408571
thrift	6530	798696	754458
json	17181	?1338371	1776519

?

通過對比，可以發現thrift總的來說，都比較不錯。

第4部分?小結

通過對messagepack，protocol?buffers以及thrift的分析，主要分析了這些框架的序列化和反序列化部分的內容。實際上messagepack和thrift都還有自己的rpc調用框架。

所有的測試都是在本機上進行，基于100條元數據進行測試。可能不同數據，以及不同的規模，測試結果應該會存在差別，https://github.com/eishay/jvm-serializers/wiki/的有比較好的測試結果說明。根據自己的測試，從性能上說，messagepack，protocol?buffers以及thrift都比json好（在測試時，發現messagepack序列化的時間稍微多一些）。

從編程語言上來說，messagepack，protocol?buffers以及thrift，當然還包括json，都是支持跨語言的通訊的。

從接口定義的靈活性來（或者是否支持動態類型），messagepack較protocol?buffers以及thrift較好，后兩者都要預先定義schema并相對固定。

?

?實際工作中, 一般都采用protocol buffers或者thrift.

?

第5部分?參考資料

1.?http://msgpack.org/

2.?http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/overview.html

3.?http://jnb.ociweb.com/jnb/jnbJun2009.html

4.?http://code.google.com/p/thrift-protobuf-compare/

5.?http://www.tbdata.org/archives/1307

6.?https://github.com/eishay/jvm-serializers/wiki/

7.?http://wiki.apache.org/thrift/

8.?http://pypi.python.org/pypi/msgpack-python/

from:http://jimmee.iteye.com/blog/2042420

總結

以上是生活随笔為你收集整理的MessagePack, Protocol Buffers和Thrift序列化框架原理和比较说明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。