1： 天龍八部的邏輯處理子產品：
邏輯處理子產品：
void run
{
for(;;){
select(); //epoll wait();
process_inputs();
process_commands();
process_outputs();
process_execeptions();
}
}
天龍八部的socketoutputstream 和 socketinputstream 類設計最大程度的減少了記憶體拷貝，加上packet/packetfactory工廠模式的設計，在很多程度上面提升了單線程處理能力，無論是gameserver billingserver loginserver 都幾乎沒有加鎖的操作，這樣也就最大程度上消除了線程排程的性能消耗；如果我們把這個模式引入到頁遊，那麼就可以這樣設計：我們将天龍八部的select 模型換成現在流行的epoll模型。
圖1： 伺服器的分布
無論驗證服，聊天服，還是場景服都做類似的處理模式。場景内還需要添加日志線程、流水線程，專門用于處理日志的列印和流水的遷移。
這個模式的優點：
1： 每個角色對應一個連接配接，能夠友善的處理消息，減少附加資料結構的設計
2： 記憶體拷貝少
3： 單個程序内所有的玩家都在同一個程序，玩家之前的互動邏輯很容易處理
這個模式的缺點：
1：不能充分利用現在多核的設計
2： 另一種處理模式：
圖 2 另一種設計
通信線程：
void run()
{
for(;;){
select(); //select epoll wait();
process_input();
process_output();
process_disconnect();
}
}
邏輯處理邏輯：
void run()
while(true)
{
packet* packet = null;
packetlist.pop(packet);
if(packet != null)
{
process_packet(packet);
}
}
這裡的通信子產品更像是一個網關，通信子產品和邏輯處理子產品之間是經典的生産者和消費者模式，無論是采用巧奪天工的kfifo設計還是使用自旋鎖設計都可以，隻是要盡量解除線程切換和等待。
這個模式的優點
1： 能配置成多線程處理，比如 n:m
缺點：
1： 記憶體拷貝多
2： 資料遷移之後，需要map去映射玩家和連接配接
感想：
頁遊伺服器相對來說是端遊伺服器的弱化版，當然我們也可以設計一個網關服去加大伺服器承載的玩家數量，但是這樣經過不同程序之間轉發的消息又必然會帶來很多同步問題，比如幫派群組隊邏輯要坐在世界服，而走動打鬥邏輯要做在場景服，在玩家在場景之間切換的時候或者一些幫派、好友資料需頻繁同步。上面的兩種模式不過是工作之餘的思考，和參考其他的網友的分享想到的，還有很多的資料沒有經過測試，比如在記憶體拷貝、線程同步與多線程之間如何取舍。還是很想聽聽其他網友的意見。