Posted on 2011-01-19 14:51
點點滴滴 閱讀(1248)
評論(0) 編輯 收藏 引用 所屬分類:
10 服務器
當閱讀一項工程的源碼時，我們大概會選擇從main函數開始，而當開始一項新的工程時，第一個寫下的函數大多也是main。那我們就先來看看，游戲服務器代碼實現中，main函數都做了些什么。
由于我在讀技術文章時最不喜看到的就是大段大段的代碼，特別是那些直接Ctrl+C再Ctrl+V后未做任何修改的代碼，用句時髦的話說，一點技術含量都沒有！所以在我們今后所要討論的內容中，盡量會避免出現直接的代碼，在有些地方確實需要代碼來表述時，也將會選擇使用偽碼。
先從mangos的登錄服代碼開始。mangos的登錄服是一個單線程的結構，雖然在數據庫連接中可以開啟一個獨立的線程，但這個線程也只是對無返回結果的執行類SQL做緩沖，而對需要有返回結果的查詢類SQL還是在主邏輯線程中阻塞調用的。
登錄服中唯一的這一個線程，也就是主循環線程對監聽的socket做select操作，為每個連接進來的客戶端讀取其上的數據并立即進行處理，直到服務器收到SIGABRT或SIGBREAK信號時結束。
所以，mangos登錄服主循環的邏輯，也包括后面游戲服的邏輯，主循環的關鍵代碼其實是在SocketHandler中，也就是那個Select函數中。檢查所有的連接，對新到來的連接調用OnAccept方法，有數據到來的連接則調用OnRead方法，然后socket處理器自己定義對接收到的數據如何處理。
很簡單的結構，也比較容易理解。
只是，在對性能要求比較高的服務器上，select一般不會是最好的選擇。如果我們使用windows平臺，那IOCP將是首選；如果是linux，epool將是不二選擇。我們也不打算討論基于IOCP或是基于epool的服務器實現，如果僅僅只是要實現服務器功能，很簡單的幾個API調用即可，而且網上已有很多好的教程；如果是要做一個成熟的網絡服務器產品，不是我幾篇簡單的技術介紹文章所能達到。
另外，在服務器實現上，網絡IO與邏輯處理一般會放在不同的線程中，以免耗時較長的IO過程阻塞住了需要立即反應的游戲邏輯。
數據庫的處理也類似，會使用異步的方式，也是避免耗時的查詢過程將游戲服務器主循環阻塞住。想象一下，因某個玩家上線而發起的一次數據庫查詢操作導致服務器內所有在線玩家都卡住不動將是多么恐怖的一件事！
另外還有一些如事件、腳本、消息隊列、狀態機、日志和異常處理等公共組件，我們也會在接下來的時間里進行探討。
前面我們只簡單了解了下mangos登錄服的程序結構，也發現了一些不足之處，現在我們就來看看如何提供一個更好的方案。
正如我們曾討論過的，為了游戲主邏輯循環的流暢運行，所有比較耗時的IO操作都會分享到單獨的線程中去做，如網絡IO，數據庫IO和日志IO等。當然，也有把這些分享到單獨的進程中去做的。
另外對于大多數服務器程序來說，在運行時都是作為精靈進程或服務進程的，所以我們并不需要服務器能夠處理控制臺用戶輸入，我們所要處理的數據來源都來自網絡。
這樣，主邏輯循環所要做的就是不停要取消息包來處理，當然這些消息包不僅有來自客戶端的玩家操作數據包，也有來自GM服務器的管理命令，還包括來自數據庫查詢線程的返回結果消息包。這個循環將一直持續，直到收到一個通知服務器關閉的消息包。
主邏輯循環的結構還是很簡單的，復雜的部分都在如何處理這些消息包的邏輯上。我們可以用一段簡單的偽碼來描述這個循環過程：
while (Message* msg = getMessage())
{
if (msg為服務器關閉消息)
break;
處理msg消息;
}
這里就有一個問題需要探討了，在getMessage()的時候，我們應該去哪里取消息？前面我們考慮過，至少會有三個消息來源，而我們還討論過，這些消息源的IO操作都是在獨立的線程中進行的，我們這里的主線程不應該直接去那幾處消息源進行阻塞式的IO操作。
很簡單，讓那些獨立的IO線程在接收完數據后自己送過來就是了。好比是，我這里提供了一個倉庫，有很多的供貨商，他們有貨要給我的時候只需要交到倉庫，然后我再到倉庫去取就是了，這個倉庫也就是消息隊列。消息隊列是一個普通的隊列實現，當然必須要提供多線程互斥訪問的安全性支持，其基本的接口定義大概類似這樣：
IMessageQueue
{
void putMessage(Message*);
Message* getMessage();
}
網絡IO，數據庫IO線程把整理好的消息包都加入到主邏輯循環線程的這個消息隊列中便返回。有關消息隊列的實現和線程間消息的傳遞在ACE中有比較完全的代碼實現及描述，還有一些使用示例，是個很好的參考。
這樣的話，我們的主循環就很清晰了，從主線程的消息隊列中取消息，處理消息，再取下一條消息......