關於服務器中玩家數據緩存：
服務器在啓動的時候會從數據庫中導入大量的信息，包括玩家的基本信息，玩家的活動信息，郵件，好友，組隊等等。
問題：哪些信息是必須在服務器初始化時導入的？
考慮這個問題的因素：並不是所有的玩家角色活動頻繁，有一部分的玩家長時間是不登陸的，全部導入會增加服務器的內存，而且查詢服務器數據也會帶來效率的影響。
考慮的方案：服務器啓動初始化時，僅僅從數據庫獲取一些經常需要用到的數據，如玩家角色信息，其他數據在需要用到時動態的添加到服務器緩存中。賬號服務器也可以採取這樣的方案，單個賬號服務器存放大量的玩家賬號數據，賬號服務器啓動時候，不導入任何數據，當玩家第一次登陸時候，從數據庫獲取數據，此時也將玩家數據加入到緩存中，以後登陸直接從緩存中獲取數據。此類方案的優勢是服務器佔用內存小，但可能帶來的問題是首次獲取數據的時候會相對比較慢，這個需要綜合各個因素，如使用的數據庫，MYSQL還是MSSQL或者其他的商業數據庫。
一般來說，玩家的數據類型爲非字符串，且佔用空間小的數據是可以保存中緩存中的，但長字串如郵件類是信息，還是直接從數據庫獲取會比較好。
2010-07-23 17:53:45
關於服務器邏輯的錯誤處理：
方式一：採用錯誤代碼的方式 ，客戶端直接通過錯誤代碼進行判斷髮生了什麼錯誤。
方式二：定義一個專門處理錯誤的消息通道，或者說錯誤提示，有錯誤直接以字符串的形式發送給客戶端。
2010-07-26 16:15:59
服務器消息轉發機制，半解包，避免冗餘代碼
一般在設計服務器的時候，服務器組是不會全部暴露在外網，通過一個叫網關或代理的服務器與外網進行通訊。很大程度上，此服務器都在進行消息轉發，如果按照通用的編碼格式，在網關服務器上也會定義消息，
然後進行轉發，但實際上消息的內容沒有任何變化。所以考慮在設計的時候，直接使用一個通道，避免在網關服務器上再進行一次消息定義。
玩家ID：
服務器不能相信客戶端發送的任何數據，所以玩家的唯一標識不能由客戶端來提供，而是由服務器來生成。
考慮的一種方案：客戶端發的數據包中留一個空位，到網關服務器根據某些信息來生成唯一的標識符，如賬號ID+角色索引+其他信息。
2010-08-10 09:51:00
設計中可能用到的設計模式：singleton,reactor,factory menthod
單例模式，保證一個類僅有一個實例,提供一個全局的訪問點;
在具體的實現中，有很多類僅僅是爲了實現功能，只需要使用一個唯一的實例就行了，以前一般的做法是extern ClassName g_Name;
工廠方法,定義一個用於創建對象的接口，讓子類決定實例化哪一個類;
設計服務器中，肯定會要有交互的消息，可以設計一個基類，然後所有的消息都由這個基類派生（產品）；實現一個工廠方法，根據自己的需求創建不同的產品。
反應器模式
每個實現的函數地址對應一個函數ID，並與消息ID對應，此ID便是所謂的句柄了；事件分發機制即是用IOCP或者EPOLL了；
服務器不斷的從客戶端接收數據包，根據消息ID，觸發對應的事件。
只是暫時的想法，標記下，等待實現，先從LINUX下的EPOLL開始吧！