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