1.所有的物件都放在記憶體，20萬用戶以下無壓力。

2.如果遊戲的使用者很多，例如超過50萬，記憶體就會不夠，可使用LRU演算法來淘汰一些資料。

流程：收到使用者請求-在記憶體查詢使用者物件-如果不存在就從資料庫中載入-放入記憶體cache-如果cache中的使用者超過20萬-用LRU演算法淘汰最古老的使用者資料。

3.避免同步的IO操作，所有會發生寫資料庫的操作：例如角色獲得了經驗，要更新資料庫；這類和遊戲邏輯相關、安全性要求不高的儲存操作，一律用非同步操作，由後臺的資料庫儲存執行緒定期儲存。

流程：如果要儲存到資料庫-檢查該物件是否已有標誌為在儲存佇列中-如果為假-將物件放入儲存佇列。後臺儲存執行緒的流程：從佇列中獲取要儲存的物件-儲存-置儲存標誌位為假。

記憶體cache+非同步儲存模式，併發每秒1000+不會有任何壓力，而且正常情況下每個請求的處理時間不會超過50毫秒。

郵件操作一定產生大量IO操作，而且都是同步操作，可用上面的cache機制處理，或者專門的郵件伺服器。

如果是DNF之類的格鬥類遊戲，因為對系統響應的時間要求特別高，50毫秒都嫌慢，這種情況下，瓶頸是在網路上，可用UDP包來解決。搜尋UDP，有大量文件。

如果使用者數是海量的，例如超過500萬，或者對併發的要求更高，例如每秒5000+次請求，這種指標明顯超過了單機的處理能力，這個時候就必須採用分散式結構，使用多臺伺服器。可參照EJB二次遠端呼叫的原理實現多機分散式結構，搜尋EJB，也有大量文件。

沒事不要用c或者c++寫遊戲伺服器端，c#和java這類歷史悠久、有大量工具包、程式設計師一抓一大把的語言最好。效能不是問題，少BUG、穩定、開發週期短才是最重要的。