1樓：yeqown
GOIM 是乙個即時IM應用，是乙個典型的分布式長連線應用。
im在其架構中，Comet就是處理長連線的網元，如圖:
個人以為，如何部署並不是關鍵，而是應用分布式之後如何管理應用邏輯，在GOIM中為：長連線如何管理？訊息要如何流轉？
在GOIM中，每乙個長鏈結代表乙個客戶端（Channel 含應用唯一標識key），應用中的使用者可以保持多個長連線以Mid作為使用者的標識，在Session中對應多個Key。每乙個連線都有自己的工作佇列，用於暫存要發往該客戶端的訊息。當然，Comet網元除了讓連線工作外，還提供心跳探活，連線鑑權等功能。
所有的訊息都源於Logic，由Comet傳送。GOIM中將訊息分為了，佇列訊息和協議（TCP Websocket）訊息。Job的工作就是將佇列訊息分流（如果佇列訊息指定了Comet ServerID），處理成協議訊息，並推送給所有或單個Comet。
Comet亦提供了三種介面處理三種緯度的訊息，個人訊息，房間廣播，全域性廣播。其中個人，房間都是先定位再傳送，至於如何傳送訊息取決於使用的應用層協議。
從Job到Comet, 可以採用廣播的方式。也就是個人訊息和廣播訊息都發給所有的Comet，這樣雖然會導致個人訊息的傳送會浪費部分Comet資源，但是要簡單點。。。慎用！
那麼同樣的，在分布式的長連線應用中，也需要考慮這兩個問題。如何標示乙個長連線並管理Session（如何儲存業務使用者和連線的對映關係）？如何定位乙個長連線（或者房間單元）並向其傳送訊息？
yeqown：訊息推送架構-Based-GOIM
2樓：階級敵人
我也曾經考慮過有沒有什麼很完美的方式實現長連線服務端分布式部署，說一些自己的想法看能不能幫到你。
我感覺分布式服務很看重水平擴充套件的能力，如果水平擴充套件能力差，會導致很多問題。
個人認為最大的問題之一就是，客戶端長連線因為部署的機器重啟導致TCP連線被斷掉後，客戶端再重連可能會導致不同伺服器間的鏈結數不均衡，導致負載不均。
緩解這個問題還要結合你的應用場景來看，就是你的長連線場景的目的是什麼。
假設你是乙個MMO網遊，或者射擊類遊戲那樣的強互動長連線場景，想做分布式部署，我個人感覺完全做不到（鏈結一斷，部分玩家集體掉線，要砸鍵盤啦）
如果互動場景並不像即時遊戲那樣強的話，TCP的維持只是為了達到能接受較低頻率的伺服器主動推送，也許乙個TCP gateway一樣的中間層（我知道做架構調整很複雜）可以幫你讓業務層面的服務做到分布式。大概想到了這麼多
關於C 分布式服務端框架問題，哪位大牛來回答？
Irons Du 不是大牛，強答一下。1 如果登陸 集群 和遊戲邏輯集群不是同乙個，那麼登陸成功之後就把遊戲集群位址告訴玩家。當然整個集群也可以只有乙個，玩家不發生鏈結切換 玩家鏈結的只有閘道器 或許最終的遊戲邏輯伺服器則可以讓玩家直連，為了減少一些內網延遲 這也會導致客戶端同時存在 1 個網路鏈結...
如何成為linux服務端C 開發專家
我們愛珂學 我的意見是，別去找那種很明顯搬磚的活。比如像我現在呆的這種遊戲公司，用的C 98，平時做的都是各種各樣的業務邏輯，就完全就是搬磚，最多成為乙個稍微好一點的搬磚工 比了比自己 就算是主程，通常都是來解決各種下面的人解決不了的陳年老bug。真正的技術積累還是得靠工作的，選乙個方向，然後找那個...
Django可以用來做C S架構的服務端嗎？
如果純粹做服務端，我更推薦 django rest framework 基於django 這是官網，供參考 Home Django REST framework也可以簡單點，看中文 詳解Django REST framework框架Django REST Framework教程 快速入門 這個問題我...