現在假設有如下構建的游戲伺服器，游戲伺服器有一組gate伺服器，用來驗證客戶端，並且通過gate伺服器來與一組主伺服器，然後主伺服器與關係伺服器進行通信。 其中relation伺服器用來處理各種關係，例如好友關係，師徒關係等。現在有一個玩家A添加玩家B為好友，那麼客戶端發送給服務端的消息流程如上所示 ...
現在假設有如下構建的游戲伺服器，游戲伺服器有一組gate伺服器，用來驗證客戶端，並且通過gate伺服器來與一組主伺服器，然後主伺服器與關係伺服器進行通信。
其中relation伺服器用來處理各種關係，例如好友關係，師徒關係等。現在有一個玩家A添加玩家B為好友，那麼客戶端發送給服務端的消息流程如上所示。首先gate收到客戶端消息，進行驗證等，然後轉發給Main1伺服器， 這裡假設玩家A的信息存儲在Main1伺服器上，然後Main1伺服器檢測玩家A的各種要求，如果滿足要求，則將消息轉發給Main2伺服器，這裡假設玩家B在Main2伺服器，然後Main2伺服器進行各種檢測，如果滿足條件，則將消息轉發給Relation伺服器，Relation伺服器再進行各種檢測，然後回覆消息給客戶端。假設Main1的伺服器檢測和Main2的伺服器檢測都可以獨立完成，那麼消息邏輯可以改為：
上面的設計方案，假設玩家A和玩家B都在Gate1上。我們查看上面的兩幅圖，可以看出後面這幅圖比第一幅圖多出了一條消息，但是，響應客戶端的消息，下麵這幅圖平均來說卻只需要經過三條網路通信，上面的那種需要4條網路消息。也就是說，正常情況下，下麵的方案響應客戶端的速度更快。對客戶端來說，這無疑是一個好的消息。
那麼我們先考慮一下，採用下麵這種方式需要解決的問題，首先Relation伺服器需要同時等待Main1和Main2的消息，然後才可以處理，這個需要添加一定的緩存，還需要一定的區分同一條消息的機制，這個在有些情況下，可以通過協議ID來區分，另外，也可以通過一個例如64位ID來區分，如果Relation伺服器對接收到的超過20s甚至更長時間的消息都不再處理，那麼64位ID可以保證在這段時間內不會重覆。這種機制不需要重覆，只需要在relation伺服器中接收到消息時，設置當前時間，然後每隔一段時間，例如1s中清理一下就可以了。這種問題的處理，也可以參考hadoop的reduce函數的處理，當然可以參考的資料很多。然後，這種方案需要玩家在同一個Gate上，對於很多游戲來說，一組伺服器，一個Gate足以，那麼這個問題，自然不用處理。對於有多個Gate的情況，也可以如果在同一個Gate上，就採用上述做法，如果不在同一個Gate上，就採用原來的做法，只需要在協議中進行區分就可以了。至於為此添加的協議中的額外欄位，不會很長，對網路的增加的壓力應該不大。從上來看，這種方式是一種可行的方案。
我們考慮一下這種方案存在的不利之處。首先網路中增加了一條協議，增加了一條Gate到Main的消息，增加了一條Main到Relation的消息，減少了一條Main到Main的消息。這個建議測試一下，查看一下這種通信協議的增加，會不會成為游戲伺服器的瓶頸。如果Main伺服器之間的通信原本比較多的話，那麼這種改變，可以減少Main之間的通信量。然後，增加了設計的複雜度，尤其是Relation的複雜度，同時增加了Relation的記憶體占用。對於很多游戲來說，Main伺服器的處理邏輯是瓶頸，這種設計方式，可以將部分需要Main伺服器處理的邏輯，轉交給Relation伺服器進行處理。如果存在很多別的伺服器，使用類似的處理的話，可能會減少Main伺服器的壓力，從而增加一組伺服器的承載能力。所以說這種設計方式，在有些情況下，不僅可以增加服務端對客戶端的響應速度，而且可以增加一組伺服器的承載量。
上面只是提供了一種簡單的設想，可以供設計游戲伺服器的程式員予以參考，如果有什麼好的建議或者意見，也歡迎反饋。
