游戏服务端线程模型——无锁处理玩家请求

一般来说，游戏服务端是采用线程池来处理所有玩家的业务请求。也就是说，在游戏服务端启动的时候，就初始一个足够大的线程池。这样，可以利用多核处理器的优势，提高业务处理能力。

但问题也随之而来，对于同一个玩家所发出的多个请求包，到了服务端可能被不同的线程同时处理，这里就出现了线程同步的问题。比较简单粗暴的解决方法是，每个玩家自带一个动作锁，当请求包上来的时候，立即将玩家的个人锁锁住。这样玩家的个人行为将从并行状态改成串行状态，也就解决了同步问题。但从本质而言，不一定所有请求都需要同步，多余的锁会消耗不必要的资源。

有没有一种方法可以实现，对于每一个玩家，都固定指派到指定线程。如此，对于每一个玩家的多个请求都将放到同一个消息队列。这些消息队列在固定的线程里按顺序执行，从而达到无锁处理玩家个人请求。

实现这一目标，典型的解决方案可以采用Actor消息模式，每一个玩家都设计为一个Actor，将对玩家的请求都发到该玩家的邮箱里。这里不作具体说明。

本文将采用线程池组的技术，说明如何优雅地解决该问题。

关于这个问题，我们只要能将角色请求通过某种关系，映射到给固定的线程执行即可。为此，我们可以初始化若干线程池，对于计算型的任务，可以将线程池的大小N设为略多于处理器的数量。但需要注意的是，我们不是初始化一个线程池࿰