我在工作中遇到了IM集群环境下消息路由问题，当集群数小时可以用内存共享的方案，当集群结点变多时，共享的数据同步会成为系统的瓶颈，为此我从网络中TCP报文的路由原理得到灵感，想了一个不用共享内存的方案，而且理论上支持大规模的集群。
应用场景如下，红色与蓝色是服务结点，橙色代表客户端结点：
当一个橙色结点要给另一个橙色结点发消息时，我们应该如何设计消息的路由策略？
上图是我们理想的消息路由路径，这时我们可以看出，红色结点是负责管理客户端的连接，而蓝色结点负责路由消息，因此我做了以下的区分：
这时我们可以把整个系统看成一个大的图，A给B消息就成了A与B的通路，理想的应该是最短路径，当然整个系统还没有这么简单，还有非常的复杂的搜索算法在里面。
这种设计对路由服务结点的性能要求较高，路由节点可能要维护自己的一张路由表，而且还要及时更新，对于每条消息也要有自己的轨迹表，记录走过的节点，这样可以解决内存共享与同步面临的问题，每个接入管理服务节点（图中的S节点）之间就可以不用相互感知，这样增加大量的节点才能成为可能。现在我对QQ和微信的解决方案很敬仰，不知道他们是否用内存共享，如何解决大量节点的集群中的Session共享，还是像我猜测的与网络中的报文路由类似的方案。
