thrift rpc 使用常見問題集和經驗

原文：http://blog.rushcj.com/2010/08/21/try-thrift/

Thrift是一個非常棒的工具，是Facebook的開源項目，目前的開發非常的活躍，由Apache管理，所以用的是Apache
Software License，這非常重要，因為可以放心的對其修改並用到自己的項目中。

談到修改Thrift,這非常重要。因為我覺得如果要嚴肅的使用Thrift，不可避免的要深入瞭解它，並幾乎都要修改Thrift的代碼。一個通訊架構，它不可能幫你做到所有的事情，也不可能在不瞭解的情況下就貿然的使用。

1.Thrift 的Java Server/Client有個較為嚴重的bug(https://issues.apache.org/jira/browse/THRIFT-601 )，隨機向thrift  sever的監聽連接埠發些資料，可能會導致Server OutOfMemory，細細看看代碼，這個bug有點土。

2.Thrift Client線程不安全，多線程下使用可能導致Server和用戶端程式崩潰。Client的每次調用遠程方法其實是有多次Socket寫操作，因此每個線程中使用的Client要保證獨立，如果多個線程混用同一個Client(其實是用同一個Socket)，可能會導致傳輸的位元組順序混亂，使得Server OutOfMemory(參考1）

3.Thrift定義資料結構時，盡量避免用map, 或者set。在cpp下, map被對應為std::map(rb tree)和std::set，thrift產生的類不會重載”<”，因此需要手動修改產生類，否則link沒法通過。較為麻煩。

4.如果Client端基於效率考慮，要緩衝Socket，需要重新實現其TTransport類，以支援 Socket緩衝池。當然，這個實現其實跟thrift沒多大關係，算是2次開發。但一般都要這麼做的吧？

5.如果Client基於效率考慮，緩衝了Socket，那麼thrift Server端的模式選擇就較為重要了。如果使用同步的TThreadPoolServer，那麼無可避免的，用戶端緩衝1個Socket，Server端就會有一個線程一直處於Server狀態，等待peek這個Socket上的資料。這個線程就不能用於其它請求了。所以，及時清理Client端的Socket及控制Socket池的大小是非常必要的。

6.聽同事說CPP Thrift Server的Epoll NonBlocking模式有效率問題。其實，並發要求不高的Server用LT模式的EPoll其實很方便的，當然，這個要自己給Thrfit Server做patch了，不過也不麻煩。開發起來也是很方便的。我想給我們的Server加個EPOLLONESHOT的同步EPoll實現。

7.CPP下的 TThreadPoolServer和TThreadServer由一個有趣的問題，如果有用戶端維護長串連，那麼對這個Server執行個體做析構的時候會堵塞（前面說過了，在peek中…）。

8.用valgrind看，thrift cpp似乎有一些記憶體問題。沒細看。

9.無論是Java，還是CPP，Server端都無法通過合法的方式擷取Client的ip, port。可以通過編寫ThriftServerEventHandler可以處理這件事情。如果想要擷取Client ip, port的話，可以看看這個東西。