原文：
多進程的遊戲服務器設計
目前，我們的遊戲服務器組是按多進程的方式設計的。強調多進程，是想提另外一點，我們每個進程上是單線程的。所以，我們在設計中，系統的複雜點在於進程間如何交換數據；而不需要考慮線程間的數據鎖問題。
如果肆意的做進程間通訊，在進程數量不斷增加後，會使系統混亂不可控。經過分析後，我決定做如下的限制：
-
如果一個進程需要和多個服務器做雙向通訊，那麼這個進程不能處理複雜的邏輯，而只是過濾和轉發數據用。即，這樣的一個進程 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
原帖：http://www.dearbook.com.cn/Book/AuthorBlog.aspx?id=25&url=http%3a%2f%2fblog.codingnow.com%2f2006%2f10%2fmulti_process_design.html&t=%b6%e0%bd%f8%b3%cc%b5%c4%d3%ce%cf%b7%b7%fe%ce%f1%c6%f7%c9%e8%bc%c6
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
隨着多核越來越被人們重視，單線程多進程的服務器解決方案，將成爲將來一段時間甚至是很長一段時間內，服務器解決方案。補充一小點：在相同的物理服務器上，進程之間的通訊有：信號，共享內存，管道，套接字之外，還有一種不常用的方法，就是用進程拋出異常的方法來進行通信。
