linux下IM server搭建

一步一步開始做。

附錄：

一套開源協議：http://www.igniterealtime.org/index.jsp

Proso：http://prosody.im/

那誰網友的筆記http://www.cppblog.com/converse/archive/2009/01/13/71902.html

網友的一些觀點：

msn是用幾個不同的服務器分別運行的不同的服務。比如最前端專門做單點登錄。一台做用戶列表的管理。再一台專門負責通信。類似如此。
還有是服務器群集的技術，我也不是很了解。高手補充下。

定時發送其實很簡單，將待發送數據排程即可。比如，用戶希望“一個月后”發送該消息，那么就將該消息和“請求時間+一個月”的時間存放入數據庫。——這是進入隊列過程。

出隊過程就是，將消息按發送時間先后排序，將所有“時間到”的消息發送出去，並根據“最近一條消息時間”安排下次發送即可。

具體架構偶也不是很清晰，不過建議使用RPC中間件。Ice有個Strome就是用於 發布/訂閱 模型的，一個人訂閱的就是“與他有關”的所有消息，而每個用戶可以“發布”消息到好友 或者 聊天室(群)里面，這樣就完成了一個基礎的IM架構了。分布式的話，設計服務器間同步的接口，然后將用戶像撒豆子一樣交給各個服務器(通過HASH算法和登入服務器接口)，每個用戶的消息必定是需要交給一個或多個其它用戶的，那么消息就有了“目的地”，根據“豆子們”所在的服務器作為“跳躍門”將消息丟過去，該服務器再根據客戶狀態要么暫存要么交給客戶就好了。

難點有下面兩點：

1.用戶上下線消息的處理。
  不同的用戶分布式策略決定了用戶上下線消息的處理。

2.DB的分布式策略
  在同時在線 10萬用戶的系統里面單數據庫顯然無法滿足需求，
  分布式的數據庫策略或者大量的memory cache是個解決方案。

我以前做過一段時間電信，我覺得IM和移動的原理差不多，可以考慮用移動網的架構。

關於DB分布，可以考慮引入兩個概念，一個叫歸屬位置寄存器，另外一個叫拜訪位置寄存器。

歸屬位置寄存器存放用戶的原始資料信息，包括用戶名和密碼。當一個用戶在某個服務器上登陸時，服務器根據特定的規則定位（比如依據ID來划分）到這個用戶所在的歸屬位置寄存器，並從該寄存器取得用戶信息，然后保存在與這個服務器相關聯的拜訪位置寄存器中。

我覺得應當包含以下幾部分:
1、好友列表、狀態維護服務器，用記好友列表的讀取以及狀態更新等，這一塊的實現應當比較復雜，發布式實現也較為麻煩。
2、登錄及會話分發服務器，用於用戶登錄系統，會話實現以及分配聊天服務器。
3、聊天服務器，用戶與該服務器直接連接進行，包括離線消息隊列等都存儲在該機器上。
4、聊天消息中轉服務器，對於不同的聊天服務器間消息的分發，牽涉到好友分組。

大概的流程：
1、用戶登錄，登錄及會話服務器驗證登錄並生成會話，同時分配聊天服務器給窗戶端，同時更新好友列表與狀態相關信息，和客戶端相關信息。
2、客戶端拿到會話令牌和分配得到的聊天服務器的信息，連接聊天服務器，聊天服務器到會話服務器進行驗證，驗證通過后與客戶端建立會話，開始聊天。
3、如果對聊天消息不做檢查的話，直接走P2P的流程進行聊天，當然如果需要對聊天消息做處理的話就需要走消息中轉服務器，如果同服務器的不需要走，不同服務器的走中轉服務器進行中轉。
4、對於離線消息直接存儲到內存隊列或者文本DB中，不同服務器間走中轉服務器進行中轉。
5、對聊天服務器做分配，做負載均衡時需要考慮結點的添加與刪除相關發布式實現的常見問題。

個人覺得如果P2P應用得好和好友列表及狀態維護上也實現得好，那么IM的架構應當是比較不錯了的。

以上純屬個人猜想。大家繼續！

好友狀態可以用簡單的Ping Pong機制來確定，另外，我有想將服務器的所謂“中轉網絡”擴大到客戶端的做法。這樣，消息中轉不一定需要走服務器，直接與客戶端連接也可以。涉及到一個不復雜的節點算法流程，與KAD類似。

我覺得不一定像移動網那么復雜，也不一定完全照搬。 
粗略划分了一下： 
對於HLR（歸屬寄存器），保存帳號的基本信息；基本上是靜態數據，也應該包括用戶 
最后一次登陸時的服務器等少量的動態信息。 
對於VLR（拜訪寄存器），可以用來保存離線消息這類的既時信息（其它用戶給當前 
（不在線）用戶發的消息）

呃……對了……有大量的基於Jabber的開源服務器可以參考。那些服務器大部分都實現了服務器間通信，以及消息緩存等機制。

如果要現成的，
也許可以看看 ejabberd - Distributed, fault-tolerant Jabber/XMPP server
written in Erlang
http://www.process-one.net/en/projects/ejabberd/

ICE提供的功能也足夠實現分布式IM了

im 最大的難點，就是一個定位 和查找的問題。

而最致命的問題，是很多帳戶可能不用
歸屬位置寄存器存放用戶的原始資料信息，包括用戶名和密碼。

這種做法可能會有非常大的浪費。 但是設計合理還是可以用的。

定位和查找，偶們經常使用的樹形結構就很有用。比如你打長途電話，如果跨市，就要撥打區號，如果跨國，就要撥打國際長途號碼一樣——用這種結構，我們用一個目錄，就能裝下地球上所有人了。什么？你不在里面？抱歉，還米開通火星長途，請等待添加火星服務器……(后面只是玩笑~)

對於游戲im來說還要考慮一賬戶多腳色多點同登問題。最好是兩層登錄

IM 架構的考慮，是整體性的考慮，關鍵問題是你想支持多大的用戶並發，多大的用戶存儲空間，想給用戶提供什么樣的服務。
是什么規模的集群，樓主可以先考慮一下。
因為大規模和小規模差別太大了。