游戏服务端框架之业务线程模型

请求消息绑定线程策略的选择

在上一篇文章中，我们看到，消息是直接在网络框架的io线程中处理的。这样做有一个非常严重的缺陷，如果业务处理比较耗时，那么io线程接受消息的速度就会下降，严重影响io的吞吐量。

典型的，我们应该另起线程池，专门用于异步处理玩家的请求消息。

在我之前的一篇文章（游戏服务端线程模型——无锁处理玩家请求），谈到可以通过某种映射，将玩家的请求分发到特定的线程进行处理，这样可以避免同一个玩家的请求需要进行线程同步。

在那篇文章，我们采用的映射策略是——将玩家的角色id与工作线程总数进行求模映射，这种模型其实是一种简单的策略。在极端的情况下，会造成非常多的玩家请求在同一条线程上（登录的玩家id不具有负载均衡性）。

采用什么映射策略，跟游戏本身的类型关联非常大。

举个例子，如果游戏的类型是一款MMORPG（大型多人在线游戏），场景地图非常大，游戏的战斗发生在服务端，pvp同步策略采用状态同步。这样的战斗方案为了减少锁竞争，往往要求同一张地图的所有玩家请求在一条线程上。特别的，由于战斗发生在服务端，怪物的行为，场景定时任务的执行，也应保证在同一条线程上。所以，这类游戏的请求消息映射策略往往跟场景id挂钩。

另外一些游戏类型，比如休闲游戏，或者虽然是rpg游戏，但战斗发生在客户端（服务端只做检验），映射策略跟场景没关系，只需保证负载均衡即可。

本文以第二种类型做演示。

为了达到负载均衡，我们可以在客户端链路的创建时