我在工作中遇到了IM集羣環境下消息路由問題，當集羣數小時可以用內存共享的方案，當集羣結點變多時，共享的數據同步會成爲系統的瓶頸，爲此我從網絡中TCP報文的路由原理得到靈感，想了一個不用共享內存的方案，而且理論上支持大規模的集羣。
應用場景如下，紅色與藍色是服務結點，橙色代表客戶端結點：
當一個橙色結點要給另一個橙色結點發消息時，我們應該如何設計消息的路由策略？
上圖是我們理想的消息路由路徑，這時我們可以看出，紅色結點是負責管理客戶端的連接，而藍色結點負責路由消息，因此我做了以下的區分：
這時我們可以把整個系統看成一個大的圖，A給B消息就成了A與B的通路，理想的應該是最短路徑，當然整個系統還沒有這麼簡單，還有非常的複雜的搜索算法在裏面。
這種設計對路由服務結點的性能要求較高，路由節點可能要維護自己的一張路由表，而且還要及時更新，對於每條消息也要有自己的軌跡表，記錄走過的節點，這樣可以解決內存共享與同步面臨的問題，每個接入管理服務節點（圖中的S節點）之間就可以不用相互感知，這樣增加大量的節點才能成爲可能。現在我對QQ和微信的解決方案很敬仰，不知道他們是否用內存共享，如何解決大量節點的集羣中的Session共享，還是像我猜測的與網絡中的報文路由類似的方案。
