最近看了一些關於，darkstar遊戲框架的文章，在此進行一下總結吧，也算是對學習成果的展示。相信人們平時一般都會玩遊戲，尤其是對於一些大型的mmo遊戲有些人更是情有獨鍾。那麼在設計這些遊戲的過程中都要考慮那些問題，這些問題又是如何解決的呢？
1.遊戲設計面臨問題：
在大型遊戲設計過程中出了要考慮到遊戲劇情機器相關的內容外，在技術層面上，伸縮性問題成為了在設計階段重點考慮的問題之一。沒有人能夠準確估計將來遊戲可能達到的規模，也沒有人能準確**未來該遊戲的走勢。有可能在很長一段時間內該遊戲都無人問津，使用者量極少，那麼預先購置大量昂貴的裝置顯然是對資源的浪費，然而，也有可能突然有一天該遊戲被大多數人所認識，人們開始蜂擁的加入遊戲的行列，遊戲的使用者量激增，也許當初的預期跟實際情況相差甚遠，當前的裝置根本無法滿足使用者的需求，即使當初預料到了準確的使用者量，那麼誰又能保證使用者永遠對你的遊戲感興趣呢？很有可能有一天人們都放棄了該遊戲，轉而投向其他的遊戲，那麼使用者量又會極具下降，又會有很多多餘的資源閒置。那麼這種狀況體現了遊戲對於框架的哪種需求呢？伸縮性，伸縮性能夠使遊戲隨著當前情況不斷調整策略。
另外一點涉及到遊戲不同於一般web應用的伸縮性的問題體現在，遊戲角色與虛擬遊戲互動的問題上，在一般的mmo遊戲中使用者智慧型與周圍的虛擬環境如：npc，或者其他的玩家進行互動，但是這之發生在小範圍內，在同乙個虛擬世界中兩個玩家互動的可能性是極小的。對於這種情況的伸縮性考慮也是非常重要的，直接影響到系統的效能。
還有一點便是可擴充套件性的問題，當然這裡所說的可擴充套件性並不是指**的可擴充套件，那只涉及到後期的維護和開發，這裡所說的可擴充套件所指的範圍更大，粒度更大，一款mmo遊戲肯定要有一定的劇情支撐，如果長期不對劇情進行更新，放入新的副本，那麼很快玩家便會失去對遊戲的興趣，那麼很自然的對遊戲的擴充套件便成為了遊戲是否成功的重要方面。
延時問題也是乙個重要的方面，因為很多玩家對於mmo遊戲就是為了追求一種即時的刺激感與互動的快感，然而延時卻嚴重影響了使用者的體驗，降低延時也成為了遊戲的乙個重要考慮方面。
2.如何解決上述問題：
為了解決上述問題，人們首先應當想到的解決方式也許就是分布式的方案，我想這也應該是最好的解決方案之一。當使用者量激增時我們可以採用增加主機的方式來增加系統的處理能力，當使用者減少的時候我們可以適當的關停部分主機。這種橫向擴充套件的策略比縱向擴充套件的方式對於系統的提高更大，成本更低，當然我們也很容易想到，即使採用縱向擴充套件的方式很快的便會出現效能的瓶頸難以繼續實現擴充套件。在加上現在的主機處理器大部分採用多核技術，這種增加核心數更加適應我們所需要的並行的多工處理需求。另外對於遊戲的程式設計方面對於多執行緒的需求也是巨大的。
伺服器端處理的人物基本上都是併發的因此對系統的多執行緒處理能力有很高的需求，另外，遊戲的伺服器端基本上都是採用反應式的，伺服器端的***時刻監聽客戶端所產生的短任務，並對這些短任務進行快速的處理。這些人物都是些簡短的易於處理的任務，但是由於併發程度高，因此處理壓力比較大。但是如果伺服器端採用多執行緒的任務處理方式便能有效的緩解這種壓力。
另外對於遊戲來說，與普通的web應用存在巨大的不同之處在於，一般的web應用基本上都是乙個瘦客戶端配合乙個胖伺服器，客戶端把請求傳送到伺服器在伺服器進行處理後把結果傳輸過來，主要的運算工作都是在伺服器端完成的。然而對於網路遊戲來說情況卻大有不同。網路遊戲為了提高使用者體驗，遊戲中的等資訊都比較大不適合用來在網上進行實時傳遞因此，遊戲的地圖，，聲音等具體資訊都在客戶端完成，另外影象的渲染及其他大量的計算人物也都在本機完成，只有當遊戲主人公與虛擬世界進行互動時才生成乙個短任務傳送給伺服器進行處理。在伺服器端一般只儲存乙個虛擬世界的抽象，和一些使用者的賬戶和遊戲相關資訊，當使用者與虛擬世界進行互動時伺服器端對虛擬世界的資訊進行修改，這樣便完成了具體的互動。也許說到這你也許會想到，在遊戲伺服器端對資料庫的訪問一般都是一些寫操作，而不是向其他web服務一樣讀操作居多，因為伺服器端的接收的的互動人物都是對虛擬世界資訊的修改，至於讀取一般都體現在客戶端。
至於解決遊戲的延時問題，現在一般都有兩種解決方式，第一種便是基於地理位置劃分來實現，也就是說遊戲種地圖的每乙個部分各自執行在一台伺服器上，這樣，玩家處在不同的區域也就使訪問壓力分散到各個伺服器上，然而這種解決方案存在一些問題，當某一時間段使用者有可能集中處於某乙個區域，那麼就給當前區域造成了很大的壓力，訪問延時也會比較高，另外如果採用這種方案，系統的伸縮性也會存在一定的問題，當系統程式設計實現時便要制定某一區域所處的伺服器，不利於系統的伸縮。第二種解決方案便是我們現在很常見的分割槽，每乙個伺服器上執行乙個遊戲的副本，玩家處於不同的伺服器上，這種方案存在的問題便是，不同分割槽上的玩家不能進行互動。
3.darkstar採用的遊戲架構
對於darkstar架構的整體架構如下：
其中元服務部分集中了遊戲所提供的全部服務的集合，這裡集中了遊戲的全部功能。
對於每乙個darkstar服務棧中包含了一部分元服務的有機組合為每個伺服器上執行的遊戲的真實副本。
遊戲伺服器便是為了接受客戶端訊息，與客戶端進行相應的互動。
對與所有的元服務中對於資料的服務是所有darkstar棧所共有的，也就是說所有darkstar棧所訪問的資料都是一致的，這也為系統的負載均衡和災難備份提供了方便。
在客戶端與伺服器端的互動上存在兩種方式：會話和管道。其中會話的方式工作方式為：當客戶端與伺服器鏈結後客戶端將發起乙個會話，伺服器端通過會話監聽客戶端傳送過來的訊息，進行處理後返回結果，其中會話隱藏了客戶端和伺服器端的真實端點。當然也就是由於這點也就為遊戲的負載均衡提供了方便，因為所有伺服器的資料服務是共享的客戶端又不知道為其服務的具體伺服器端是誰，那麼只需要底層服務修改該會話的伺服器端即可實現將此會話遷移到其他伺服器上的目的。另外一種互動方式也就是管道允許遊戲使用者可以以一種一對多的方式直接傳送到多個客戶端上，也就允許的客戶端的直接通訊，減小了伺服器端的負擔，但為了防止客戶端惡意傳輸資訊，一般這種管道通訊都要經過伺服器端的驗證。
這些也就是我對這個框架的理解了，確實很靈活，可以做適當的遷移，以完成其他的系統。
關於Darkstar集群中支援AION的遇到的問題
30日剛過完學生時代的最後乙個生日，回來就繼續投入開發中。仔細研究後發現了有乙個集群的問題會面臨，那就是原來的 協議中，有login redirect這麼乙個概念，那是當當前連線的節點狀態不是非常好的時候就會傳送這麼個資訊讓客戶端自動連線另外乙個節點。而在aion的模擬器實現中呢，就會面臨這個問題，...
學使用qeephp框架
1.在原有的能夠正常執行的apache2 php5 和mysql5 環境環境上 瀏覽器訪問的目錄中即可 例如http localhost 對應d www 目錄，那麼將qeephp 放置在d www qeephp 2.1 目錄中就可以通過http localhost qeephp 2.1 訪問到qee...
AsyncHttpClient 開源框架學習研究
overview asynchttpclient庫 基於apache的httpclient框架,是乙個非同步的httpclient,所有的http請求都在子執行緒中,但是callback執行的執行緒和建立這個callback的執行緒是同乙個 也即主線程建立的callback那麼執行的時候也是在主線程...