用戶信息用user1@ip1, user2@ip2表示。?? 后面的消息存儲db是公共的。

1）用戶登錄時主動拉取信息， server將該用戶的離線信息發(fā)給用戶

2）同server中， 不同用戶傳遞消息時， server將收到的其他用戶發(fā)來的消息直接存儲并發(fā)給該目標(biāo)用戶、無需判斷發(fā)送是否成功。 不成功則表示用戶連接異常了， 下次再連上時，目標(biāo)用戶能主動拉取到。【保證了任何情況下不會丟掉消息】

3）user1通過server1轉(zhuǎn)發(fā)給server2的user2時，server1收到時即存儲， 然后server1轉(zhuǎn)發(fā)給server2； 如果轉(zhuǎn)發(fā)成功，則由server2執(zhí)行步驟2負責(zé)最終的投遞；server2投遞成功，user2就能看到最新；否則user2離線、下次再登陸依然能看到。【也保證了任何情況下不會丟掉消息】

這種要求server之間能全互通、且全互連接了。 不支持server之間的多次relay、不支持第三方server。

可能問題：

1） 寫可能成為瓶頸。在db前端加cache、數(shù)據(jù)慢慢由cache寫到db中； 查詢時合并db結(jié)果和cache結(jié)果。

2）群聊、群通知（幾十、幾百的規(guī)模）。server逐個給群中每個人發(fā)、或者發(fā)給其他server轉(zhuǎn)發(fā)。【信息的存儲是以群為單位】

3）全服系統(tǒng)通知（幾萬、幾十萬規(guī)模、或者騰訊幾億規(guī)模？ 幾億也是分解到了一個服務(wù)器能支撐的量， 約幾w或者幾千！！）：可以短時間內(nèi)全部逐個發(fā)、或者分時發(fā)減慢影響。 全服系統(tǒng)通知可以使用內(nèi)存存放，整個就沒多少數(shù)據(jù)。避免后端db的查詢。【信息的存儲以全服為單位、獨此一份】

4）有時序問題？ server2收到消息msg1，查詢知user2未上線，準(zhǔn)備寫db/cache； 寫之前user2上線了并主動獲取離線消息、但得到的是不包含msg1的離線消息。 msg1在這次登陸中被漏掉了。？? server先寫cache/db， 再判斷是否用戶在線而發(fā)送；這樣OK。

5）有可能有多次relay的需求？?? 或者relay之后的server也有存儲的需求？? cache只是減少寫壓力； 讀依賴于mysql本身的緩存機制。

每個模塊負責(zé)自己的事情、把自己的事情做好， 能夠向外承諾模塊自己的責(zé)任； 模塊也能信任其他模塊聲稱的職能。

模塊間的功能和職責(zé)劃分明確， 否則模塊之間互相不能信任，考慮的東西太多太復(fù)雜， 無法達成簡潔、清晰的設(shè)計。

略 仿xmpp

http://wiki.jabbercn.org/Jabberd2:%E5%AE%89%E8%A3%85%E5%92%8C%E7%AE%A1%E7%90%86%E6%8C%87%E5%8D%97

https://github.com/jabberd2/jabberd2

http://zh.wikipedia.org/wiki/XMPP%E5%8D%94%E8%AD%B0%E4%BC%BA%E6%9C%8D%E5%99%A8%E8%BB%9F%E9%AB%94%E5%88%97%E8%A1%A8

總結(jié)

以上是生活随笔為你收集整理的系统通知、 聊天服务的实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。