阅读天龙八部的代码有感----两种逻辑处理模式的比较

  1. 云栖社区>
  2. 博客>
  3. 正文

阅读天龙八部的代码有感----两种逻辑处理模式的比较

石门-archy 2016-04-20 17:04:20 浏览992
展开阅读全文

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

 

感想:

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

网友评论

登录后评论
0/500
评论
石门-archy
+ 关注