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來劃分）到這個用戶所在的歸屬位置寄存器，並從該寄存器取得用戶信息，而後保存在與這個服務器相關聯的拜訪位置寄存器中。

我以爲應當包含如下幾部分:
一、好友列表、狀態維護服務器，用記好友列表的讀取以及狀態更新等，這一塊的實現應當比較複雜，發佈式實現也較爲麻煩。
二、登陸及會話分發服務器，用於用戶登陸系統，會話實現以及分配聊天服務器。
三、聊天服務器，用戶與該服務器直接鏈接進行，包括離線消息隊列等都存儲在該機器上。
四、聊天消息中轉服務器，對於不一樣的聊天服務器間消息的分發，牽涉到好友分組。

大概的流程：
一、用戶登陸，登陸及會話服務器驗證登陸並生成會話，同時分配聊天服務器給窗戶端，同時更新好友列表與狀態相關信息，和客戶端相關信息。
二、客戶端拿到會話令牌和分配獲得的聊天服務器的信息，鏈接聊天服務器，聊天服務器到會話服務器進行驗證，驗證經過後與客戶端創建會話，開始聊天。
三、若是對聊天消息不作檢查的話，直接走P2P的流程進行聊天，固然若是須要對聊天消息作處理的話就須要走消息中轉服務器，若是同服務器的不須要走，不一樣服務器的走中轉服務器進行中轉。
四、對於離線消息直接存儲到內存隊列或者文本DB中，不一樣服務器間走中轉服務器進行中轉。
五、對聊天服務器作分配，作負載均衡時須要考慮結點的添加與刪除相關發佈式實現的常見問題。

我的以爲若是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 架構的考慮，是總體性的考慮，關鍵問題是你想支持多大的用戶併發，多大的用戶存儲空間，想給用戶提供什麼樣的服務。
是什麼規模的集羣，樓主能夠先考慮一下。
由於大規模和小規模差異太大了。