集群式遊戲伺服器架構方案設計開發
自從2023年開發voip radius server以及修改gnugk依賴，從事伺服器開發已經近五年了，對伺服器開發也有一些自己獨到的看法以及見解。當擺脫了技術本身的束縛之後，才理解重要的並不是某種技術的運用，而是整體設計的考慮，也慢慢明白了設計是開發的靈魂的道理。
從技術層面來看，各個平台都有一些自己特有的東西，比如windows 平台下面的iocp技術，可以說為了支援大的併發，iocp是乙個windows平台的必選方案。而在linux下面epoll又是所有開發人員需要掌握的技術。當然還有freebsd下面kqueue的應用了。一些其他平台也有自己獨有的aio庫。
隨著網路開發的進一步理念加深，跨平台庫也吸引了越來越多的使用者的眼光。比如行業裡面最出名的莫過於ace、asio(boost公司)兩大支援庫。新的版本中都對iocp支援，使用的是proactor設計模式實現的。
當我們擁有了以上的知識背景後，我們就可以開始著手設計了。而這僅僅是乙個必要條件，而不是重複條件。為什麼呢？
我們先來提一下集群式伺服器開發的常用幾個技術知識。
1：執行緒
2：執行緒池
3：記憶體池
4：資料庫連線池
5：為了達到1:10000的連線，可以採用server-client的連線方式，而為了達到1:10000*100的連線，我們怎麼辦呢？一般會採用client-> connserver -> logicserver。這是技術背景。connserver在接受完client 的連線後，將logic server 暴露給client,並立刻斷開連線。以後的資料互動就和conn server沒有關係了，這種架構有很多的優勢。
[圖一：標準集群gameserver架構方案]
首先要說的是執行緒，在伺服器開發中，執行緒是乙個非常重要的概念，尤其是現在多核伺服器的發展。當然，提到了執行緒自然應該說到執行緒之間的互斥。這也是伺服器開發者們在開發最初最容易出現的問題。體現在乙個資源或者多個資源在多個執行緒中共享使用如何避免出現髒資料的問題。
執行緒池，池，顧名思義，是乙個儲存容器，乙個淺顯的比方，我們把水事先存放在水池裡面，當我們需要的時候，就去裡面取，用完了就還給池（其實這裡並不是非常合適的例子，畢竟我們用完了水是丟掉）。這是乙個由多個執行緒組成的乙個佇列，當有事情發生時候，我們把當前的空閒的執行緒丟給他，為他服務。當下乙個事件發生的時候，我們又從池裡面取乙個空閒的執行緒丟給他，為他服務。當服務完畢，把執行緒丟回池中。起到反覆利用的目的。
記憶體池，同樣也是乙個池。這個概念的產生是為了避免伺服器頻繁的分配記憶體，而採取預先分配一定數目的物件，並將物件們放到佇列中，當需要的時候，從該佇列中取出，當用完，就返回池中。比如我們的server可能會存在10000個連線，我們預先開闢10000個client物件，儲存在listpfreeclientslist中，當需要的時候，從佇列中pop乙個出來，當使用完畢就丟回pfreeclientslist。這種機制很好的起到了避免頻繁開闢記憶體物件的目的，可以很好的提高系統的效能。
資料庫連線池，同上面一致的道理，在伺服器中，資料庫訪問也是乙個很大的瓶頸，所以同樣採取上面的道理，使用連線池的概念。當然在資料庫連線方面也有乙個特殊的問題存在。就是資料庫的連線不宜過多，所以傳統的來乙個處理，就開乙個連線是不合理的，必須採用控制適當的連線次數。
當然另外一些需要提到的是記憶體資料庫。硬碟的訪問速度和記憶體的訪問速度不是乙個數量級的，而且隨著記憶體的硬體**越來越低，記憶體資料庫的可行性也越來越高，尤其是實時性要求高的系統，完全可以採用記憶體資料庫和物理資料庫想結合的方法來處理。
當系統的連線數量從萬上百萬級別的時候，伺服器程式就超越了伺服器本身，我們需要考慮的問題將從一下幾個方面開展：
1：如何劃分系統中功能？
2：如何保證整個系統的效能可控，直觀的說就是系統每一步時候瓶頸在**？
3：如何保證當系統的瓶頸凸顯時候，簡單的新增一組伺服器，就可以達到分壓目的？
4：系統的災難部分出現的時候，如何保證系統依然可以完整執行？
第乙個問題是如何劃分系統中的功能。在軟體開發中，我們追求的是每個函式功能盡量簡單，易學裡面的道理叫做大道至簡。軟體開發中同樣適用，在伺服器開發中，同樣適用。如何將整個系統中的需求抽象為功能，並如何更好的劃分功能，將極大減少系統開發的難度，並能夠使得系統的可擴充套件性非常強。
第二個問題是瓶頸問題。從物理上面來分析，效能在硬碟，記憶體，cpu是三個決定因素的地方。而從軟體的角度就包含了資料庫系統，作業系統，伺服器軟體系統三個方面，更細節方面拿遊戲伺服器來說，conn server 的壓力，logic server的壓力，還是db server的壓力了。
第三個問題還體現在分組方面。比如當conn server出現壓力的時候，如何簡單的新增乙個conn server就達到分壓目的。當logic server出現壓力，或者db server出現壓力。另外就是如果伺服器設計以組的方式出現，應該如何管理組以達到分壓目的。
第四個問題是災難恢復。在重要的系統中，由於涉及到的系統、硬體、軟體非常多，很容易某個系統出現故障，這個時候，系統應該具有很好的伸縮性，故障出現後，系統必須依然執行順利。
所以在設計伺服器時候，應該考慮上面的因素。下面我提出在集群伺服器開發中的兩種可行的方案。
[圖二：基於功能劃分的集群gameserver架構]
[圖三：組劃分的集群伺服器架構]
在圖二中，系統按照功能方式劃分系統，當壓力增加的時候，按照功能方式新增某伺服器，可以簡單的達到分壓的目的。在conn server中儲存所有有效hall server的連線，以及當前該hall server的當前連線數。**示意如下：
集群式遊戲伺服器架構方案設計開發
自從2003年開發voip radius server以及修改gnugk以來，從事伺服器開發已經近五年了，對伺服器開發也有一些自己獨到的看法以及見解。當擺脫了技術本身的束縛之後，才理解重要的並不是某種技術的運用，而是整體設計的考慮，也慢慢明白了設計是開發的靈魂的道理。從技術層面來看，各個平台都有一些...
集群式遊戲伺服器架構方案設計開發
自從2003年開發voip radius server以及修改gnugk以來，從事伺服器開發已經近五年了，對伺服器開發也有一些自己獨到的看法以及見解。當擺脫了技術本身的束縛之後，才理解重要的並不是某種技術的運用，而是整體設計的考慮，也慢慢明白了設計是開發的靈魂的道理。從技術層面來看，各個平台都有一些...
遊戲伺服器架構設計
一 棋牌類伺服器的特點 1，棋牌類不分割槽不分服 一般來說，棋牌遊戲都是不分割槽不分服的。所以棋牌類伺服器要滿足隨著使用者量的增加而擴充套件的需要。2，房間模式 即在同一局遊戲中就是在同乙個房間中，同乙個房間中的人可以接收到其他人的訊息。3，每個房間的操作必須是順 序性 這個特性類似與一般遊戲的回合...