中文字幕免费精品_亚洲视频自拍_亚洲综合国产激情另类一区_色综合咪咪久久

之前寫過兩篇關于 Thrift 的相關文章。

Thrift源碼剖析

Thrift異步IO服務器源碼分析

也算是對Thrift比較熟悉，不過對 Thrift 里面的 Protocol 部分還是黑盒使用。 雖然大概能猜到具體實現方式，但是還是忍不住花了一點點時間把具體代碼實現翻出來看看。 主要是為了滿足一下好奇心。

簡單搞了一個Thrift的描述文件Insight.thrift作為例子。

struct Person {

1: string name,

2: i32 age,

3: optional string address,

}

service Insight {

Person Hello(1: Person person),

Person Hi(1: Person p1, 2: Person p2),

}

然后通過 畢竟Thrift其實就是干RPC的活，所以看源碼就按著RPC遠程調用的順序來看就行。

從Hello函數調用開始，InsightClient::Hello 可以看出， 在每次RPC調用的時候，會先將函數名通過writeMessageBegin("Hello", ::apache::thrift::protocol::T_CALL, cseqid) 先發送過去。 這個過程的序列化協議很簡單，直接就是傳輸的函數名字符串。 然后再發送參數。 發送參數的時候，會將所有參數作為一個 struct 發送 InsightHellopargs，

所以協議的序列化過程主要都是體現在 struct 的序列化上面。 比如像Hi函數的參數序列化過程:

uint32_t Insight_Hi_pargs::write(::apache::thrift::protocol::TProtocol* oprot) const {

uint32_t xfer = 0;

xfer += oprot->writeStructBegin("Insight_Hi_pargs");

xfer += oprot->writeFieldBegin("p1", ::apache::thrift::protocol::T_STRUCT, 1);

xfer += (*(this->p1)).write(oprot);

xfer += oprot->writeFieldEnd();

xfer += oprot->writeFieldBegin("p2", ::apache::thrift::protocol::T_STRUCT, 2);

xfer += (*(this->p2)).write(oprot);

xfer += oprot->writeFieldEnd();

xfer += oprot->writeFieldStop();

xfer += oprot->writeStructEnd();

return xfer;

}

整個對象的序列化過程主要是依賴了接口 TProtocol 的函數。

對于實現 TProtocol 接口的序列化實現主要是以下三種(在thrift-0.9.0/lib/cpp/src/thrift/protocol里)：

TBinaryProtocol

TCompactProtocol

TJSONProtocol

要了解協議序列化過程主要看一下 TBinaryProtocol 和 TCompactProtocol 就夠了。

主要是如下幾個關鍵點：

其實 writeStructStruct 和 writeStructEnd 啥屁事也不用做。

其實 writeFieldBegin 只有后兩個參數有用，第二個參數是類型，第三個參數是ID， 因為光靠這兩者就可以在反序列化（讀取解析）的時候知道是哪個成員了。

struct write 的過程其實是個遞歸的過程，也就是在write函數中， 會遞歸的調用結構體本身每個成員的write函數。

TCompactProtocol 和 TBinaryProtocol 的區別主要是， TCompactProtocol 對整數類型使用了 ZigZag 壓縮算法，比如 i32 類型的整數本來是4個字節， 可以壓縮成 1~5 字節不等。而 i64類型的整數本來是8個字節。可以壓縮成 1~10 字節不等。

更多信息請查看IT技術專欄