【问题】
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本身实现双向传输。有兴趣的读者可参考: