集群模式下消息转发的方案如何选择？

[defineYIDA]

发送消息：Client1-->Client2 ，集群模式下Server如何拿到Client2的Channel？

1. RPC（或者HTTP）

项目最开始时考虑的方式，在Client1的接入服务器上，通过redis上的注册信息，获得Client2接入的Server的地址，进而通过RPC或者HTTP接口的方式拿到Channel。
问题：
但是在配置的时候感觉很奇怪，拿dubbo来说，Server既是consumer又是provider，在调用的时候还得指定一个特定provider（Client2接入的Server）的服务。
这里使用HTTP可能还更方便，通过拼接URL来访问接口，获得Channel
所以就暂时放了放寻找其他的方式。

2. Proxy将消息广播给所有Server

因为存在一个Proxy层（接入层），就考虑到在发送消息的时候将消息广播到与Proxy连接的所以后端服务器，后端Netty如果不能拿到对应的Channel就丢弃，能拿到就转发。
问题：
这样做网络中肯定会多出许多广播消息影响服务的性能。而且并不好做类似用户不在线的提示。

3. Proxy做消息分发

在Proxy拿到Client1的消息时，根据redis中的注册信息，拿到Client2的后端服务器的信息，将消息转发到对应的后端服务器上。
问题：
Proxy的功能就不纯了，出现了业务逻辑，其实起初是想将Proxy做成无状态的。