圖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的注解。

 

/**
 * 一個用于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條數據的序列化和反序列化進行對比。

 

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

 

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;
}

 

 

 

 

message MessageMetas {
repeated MessageMeta msg = 1;
}

 

 

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

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

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

 

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 與編碼無關的文本或二進制字符串

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

 

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

 

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. 執行序列化和反序列化

 

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/