I M的業務場景中消息是最核心且最頻繁使用到的，很容易影響客戶端的體驗，也是通信處理的瓶頸和系統性能瓶頸之處，因此設計好消息的處理方案對IM系統至關重要。在此根據自身的經驗和遇到的問題，總結下IM消息的處理思路，希望對讀者有所啓發。
服務端IM消息功能
單聊消息轉發；
羣組消息轉發；
多終端消息同步；
單聊消息入庫存檔；
羣組消息入庫存檔；
消息檢索；
離線消息；
消息回執；
消息撤回；
消息的擴展及業務類型（羣組管理消息、文件消息、公告消息、投票消息等更多的業務類型消息）；
移動終端的消息推送等等
關鍵性問題
消息轉發
消息轉發延遲問題。消息轉發要在耗時的業務邏輯操作之前處理掉，否則得等耗時操作處理完會造成時延。同時，業務處理中耗時的操作會佔用業務線程，導致在併發負載高的時候，獲取不到空閒的業務線程，消息得不到及時轉發。尤其消息入庫存檔操作，如果消息存檔規模達到百萬千萬級，要進行異步方式進行存檔。
如果其它業務（非消息業務）的處理也有比較耗時的操作，不能和消息使用同一個線程池進行處理，因爲也會造成獲取不到空閒的業務線程來轉發消息。這就是及時業務（消息轉發）要有線程隔離的機制。
客戶端的時鐘是不能保證正確的，也是不統一的，所以轉發消息要處理消息時間的同步問題，在消息到達服務端時要給消息打上時間戳，這樣所有客戶端的上展示的消息的時間才能同步。
相同賬號登錄的多個終端，不管是消息的發送方還是接收方要轉發消息。
消息存檔
消息的存檔記錄數和佔用的磁盤空間都是很大的，如何在不影響查詢性能的前提下儘量節約空間是消息存檔面臨最大的挑戰。查詢消息很常見都是按用戶來，所以按用戶來分表是很常見的方案，來降低查詢的規模，提高性能。羣組消息是一對多的映射，一些協議中（比如xmpp）消息體數據量比較多，如果直接冗餘，會給存儲空間帶來比較大的負擔，這並非一定不可行，要根據實際的業務進行評估。另一種方案可以將消息主體和消息的接收者（可帶冗餘字段）拆開存儲，接收者記錄做用戶映射的分表，主體表可以按其他方式進行分表（比如時間段分表）。
消息檢索
消息檢索肯定要建索引，但要避免or索引（在實際項目中最早採用or索引造成很大的查詢性能問題）。消息查詢和離線消息的實現方案有關係，用戶登錄後，可以由服務端推送離線消息也可以由客戶端主動來檢索離線消息，這種業務場景下，客戶端主動來檢索離線消息，如果併發太高，即使在分表和索引優化之後，檢索歷史消息也可能是非常耗時的操作，有可能會阻塞業務線程池，造成其它業務不能處理，所以這時候檢索歷史消息也應該要採用異步方式來響應。