跨語言RPC框架Thrift詳解

Thrift的傳輸格式（協議層）

Thrift之因此被稱爲一種高效的RPC框架，其中一個重要的緣由就是它提供了高效的數據傳輸。
如下是Thrift的傳輸格式種類：

    TBinaryProtocol: 二進制格式。效率顯然高於文本格式。
    TCompactProtocol：壓縮格式。在二進制基礎上進一步壓縮。
    TJSONProtocol：JSON格式。
    TSimpleJSONProtocol：提供JSON只寫協議（缺乏元數據信息），生成的文件很容易用過腳本語言解析。
    TDebugProtocol：使用易懂的刻度文本格式，以便於調試。

以上能夠看到，在線上環境，使用TCompactProtocol格式效率是最高的，同等數據傳輸佔用網絡帶寬是最少的。
7、Thrift的數據傳輸方式（傳輸層）

    TSocket：阻塞式socket。
    TFramedTransport：以frame爲單位進行傳輸，非阻塞式服務中使用。
    TFileTransport：以文件形式進行傳輸。
    TMemoryTransport：將內存用於I/O，Java是現實內部實際使用了簡單的ByteArrayOutputStream。
    TZlibTransport：使用zlib進行壓縮，與其餘傳輸方式聯合使用。當前無java實現。

8、Thrift的服務模型

    TSimpleServer
    簡單的單線程服務模型，經常使用於測試。只在一個單獨的線程中以阻塞I/O的方式來提供服務。因此它只能服務一個客戶端鏈接，其餘全部客戶端在被服務器端接受以前都只能等待。
    TNonblockingServer
    它使用了非阻塞式I/O，使用了java.nio.channels.Selector，經過調用select()，它使得程序阻塞在多個鏈接上，而不是單一的一個鏈接上。TNonblockingServer處理這些鏈接的時候，要麼接受它，要麼從它那讀數據，要麼把數據寫到它那裏，而後再次調用select()來等待下一個準備好的可用的鏈接。通用這種方式，server可同時服務多個客戶端，而不會出現一個客戶端把其餘客戶端所有「餓死」的狀況。缺點是全部消息是被調用select()方法的同一個線程處理的，服務端同一時間只會處理一個消息，並無實現並行處理。
    THsHaServer（半同步半異步server）
    針對TNonblockingServer存在的問題，THsHaServer應運而生。它使用一個單獨的線程專門負責I/O，一樣使用java.nio.channels.Selector，經過調用select()。而後再利用一個獨立的worker線程池來處理消息。只要有空閒的worker線程，消息就會被當即處理，所以多條消息能被並行處理。效率進一步獲得了提升。
    TThreadedSelectorServer
    它與THsHaServer的主要區別在於，TThreadedSelectorServer容許你用多個線程來處理網絡I/O。它維護了兩個線程池，一個用來處理網絡I/O，另外一個用來進行請求的處理。
    TThreadPoolServer
    它使用的是一種多線程服務模型，使用標準的阻塞式I/O。它會使用一個單獨的線程來接收鏈接。一旦接受了一個鏈接，它就會被放入ThreadPoolExecutor中的一個worker線程裏處理。worker線程被綁定到特定的客戶端鏈接上，直到它關閉。一旦鏈接關閉，該worker線程就又回到了線程池中。
    這意味着，若是有1萬個併發的客戶端鏈接，你就須要運行1萬個線程。因此它對系統資源的消耗不像其餘類型的server同樣那麼「友好」。此外，若是客戶端數量超過了線程池中的最大線程數，在有一個worker線程可用以前，請求將被一直阻塞在那裏。
    若是提早知道了將要鏈接到服務器上的客戶端數量，而且不介意運行大量線程的話，TThreadPoolServer多是個很好的選擇。
---------------------
做者：aronykl
來源：CSDN
原文：https://blog.csdn.net/zw19910924/article/details/78178539
版權聲明：本文爲博主原創文章，轉載請附上博文連接！