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去映射玩家和连接

 

感想：

     页游服务器相对来说是端游服务器的弱化版，当然我们也可以设计一个网关服去加大服务器承载的玩家数量，但是这样经过不同进程之间转发的消息又必然会带来很多同步问题，比如帮派和组队逻辑要坐在世界服，而走动打斗逻辑要做在场景服，在玩家在场景之间切换的时候或者一些帮派、好友数据需频繁同步。上面的两种模式不过是工作之余的思考，和参考其他的网友的分享想到的，还有很多的数据没有经过测试，比如在内存拷贝、线程同步与多线程之间如何取舍。还是很想听听其他网友的意见。