【问题】
Thrift采用了C/S模型，不支持双向通信：client只能远程调用server端的RPC接口，但client端则没有RPC供server端调用，这意味着，client端能够主动与server端通信，但server端不能主动与client端通信而只能被动地对client端的请求作出应答。这种RPC模式在某些应用中存在缺陷，比如：有些应用，在大部分情况下，client端会主动向server端发请求或者向server端发送数据，而在少部分情况下，server端也需要主动向client发送一些命令，告知进行某些操作。
（什么是Thrift，可参考：Thrift架构介绍）
为了解决该问题，通常有三种方案可供选：
方案一：轮询(可选)
该方案很容易想到：client端周期性地向server端询问是否需要进行某些操作，如果需要，则什么也不做，如果需要，则按照server的应答（response）要求进行操作。该方案的不足是延迟较大、且会浪费大量资源，造成不必要的访问开销。
方案二：双client/server(推荐)
通信双方都既是client，也是server。该方案需要在通信双方之间建立两个通信通道，开启两个端口，这比较繁琐，且很不优雅。但仍是目前普遍采用的一套方案。
client/server <————————-> client/server
方案三：异步共享通道(不推荐)
Thrit底层实际上是socket，而socket是支持双向传输的，因此，我们完全可以通过修改thrift本身实现双向传输。有兴趣的读者可参考：