【問題】

Thrift采用了C/S模型，不支持雙向通信：client只能遠程調(diào)用server端的RPC接口，但client端則沒有RPC供server端調(diào)用，這意味著，client端能夠主動與server端通信，但server端不能主動與client端通信而只能被動地對client端的請求作出應(yīng)答。這種RPC模式在某些應(yīng)用中存在缺陷，比如：有些應(yīng)用，在大部分情況下，client端會主動向server端發(fā)請求或者向server端發(fā)送數(shù)據(jù)，而在少部分情況下，server端也需要主動向client發(fā)送一些命令，告知進行某些操作。

為了解決該問題，通常有三種方案可供選：

方案一：輪詢

該方案很容易想到：client端周期性地向server端詢問是否需要進行某些操作，如果需要，則什么也不做，如果需要，則按照server的應(yīng)答（response）要求進行操作。該方案的不足是延遲較大、且會浪費大量資源，造成不必要的訪問開銷。

方案二：雙client/server

通信雙方都既是client，也是server。該方案需要在通信雙方之間建立兩個通信通道，開啟兩個端口，這比較繁瑣，且很不優(yōu)雅。但仍是目前普遍采用的一套方案。

client/server <————————-> client/server

方案三：異步共享通道

Thrit底層實際上是socket，而socket是支持雙向傳輸?shù)?，因此，我們完全可以通過修改thrift本身實現(xiàn)雙向傳輸。有興趣的讀者可參考：

http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html