目前，我們的游戲服務器組是按多進程的方式設計的。強調多進程，是想提另外一點，我們每個進程上是單線程的。所以，我們在設計中，系統的復雜點在于進程間如何交換數據；而不需要考慮線程間的數據鎖問題。
如果肆意的做進程間通訊，在進程數量不斷增加后，會使系統混亂不可控。經過分析后，我決定做如下的限制：
-
如果一個進程需要和多個服務器做雙向通訊，那么這個進程不能處理復雜的邏輯，而只是過濾和轉發數據用。即，這樣的一個進程 S
，只會把進程 A 發過來的數據轉發到 B ；或把進程 B 發過來的數據轉發到 A
。或者從一端發過來的數據，經過簡單的協議分析后，可以分發到不同的地方。例如，把客戶端發過來的數據包中的聊天信息分離處理，交到聊天進程處理。
-
有邏輯處理的進程上的數據流一定是單向的，它可以從多個數據源讀取數據，但是處理后一定反饋到另外的地方，而不需要和數據源做邏輯上的交互。
-
每個進程盡可能的保持單個輸入點，或是單個輸出點。
-
所有費時的操作均發到獨立的進程，以隊列方式處理。
-
按功能和場景劃分進程，單一服務和單一場景中不再分離出多個進程做負載均衡。
性能問題上，我是這樣考慮的：
我們應該充分利用多核的優勢，這會是日后的發展方向。讓每個進程要么處理大流量小計算量的工作；要么處理小流量大計算量的工作。這樣多個進程放在一臺物理機器上可以更加充分的利用機器的資源。
單線程多進程的設計，個人認為更能發揮多核的優勢。這是因為沒有了鎖，每個線程都可以以最大吞吐量工作。增加的負擔只是進程間的數據復制，在網游這種復雜邏輯的系統中，一般不會比邏輯計算更早成為瓶頸。如果擔心，單線程沒有利用多核計算的優勢，不妨考慮以下的例子：
計算 a/b+c/d+e/f ，如果我們在一個進程中開三條線程利用三個核同時計算 a/b c/d e/f
固然不錯，但它增加了程序設計的復雜度。而換個思路，做成三個進程，第一個只算 a/b 把結果交給第二個進程去算 c/d
于之的和，再交個第三個進程算 e/f
。對于單次運算來算，雖然成本增加了。它需要做額外的進程間通訊復制中間結果。但，如果我們有大量連續的這樣的計算要做，整體的吞吐量卻增加了。因為在算
某次的 a/b 的時候，前一次的 c/d 可能在另一個核中并行計算著。
具體的設計中，我們只需要把處理數據包的任務切細，適當增加處理流水線的長度，就可以提高整個系統的吞吐量了。由于邏輯操作是單線程的，所以另需要注意的一點是，所有費時的操作都應該轉發到獨立的進程中異步完成。比如下面會提到的數據存取服務。
對于具體的場景管理是這樣做的：
玩
家連接進來后，所有數據包會經過一個叫做位置服務的進程中。這個進程可以區分玩家所在的位置，然后把玩家數據分發到對應的場景服務進程中。這個位置服務同
時還管理玩家間消息的廣播。即，單個的場景（邏輯）服務并不關心每個數據包為哪幾個玩家所見，而由這個服務將其復制分發。
當玩家切換場景，場景服務器將玩家的數據發送給數據服務，數據服務進程 cache 玩家數據，并將數據寫入數據庫。然后把玩家的新的場景編號發回位置服務進程，這樣位置服務器可以將后續的玩家數據包正確的轉發到新的場景服務進程中。
掉落物品和資源生產同樣可以統一管理，所以的場景（邏輯）進程都將生產新物件的請求發給物品分配服務，由物品分配服務生產出新物件后通知位置服務器產生新物品。
這樣一系列的做法，最終保證了，每個場景服務器都有一個唯一的數據源——位置服務進程。它跟持久化在數據庫中的數據無關，跟時鐘也無關。由此帶來的調試便利是很顯著的。
最近，面臨諸多進程的設計時，最先面臨的一個復雜點在于啟動階段。顯然，每個進程都配有一套配置文件指出其它進程的地址并不是一個好主意。而為每個
服務都分配一個子域名在開發期也不太合適。結果我們采取了一個簡單的方案：單獨開發了一個名字服務器。它的功能類似 DNS
，但是可以讓每個進程自由的注冊自己的位置，還可以定期匯報自己的當前狀態。這樣，我們可以方便的用程序查詢到需要的服務。名字服務器的協議用的類似
POP3 的文本協議，這讓我們可以人手工 telnet 上去查閱。我相信以后我們的維護人員會喜歡這樣的設計的。:D
以上，國慶假期結束以來的工作。感謝項目組其他同事的辛勤編碼。