|
逻辑服务器多线程设计 1. 背景 分离数据库之后，逻辑服务器只有网络的IO，因此逻辑服务器是强计算类型的服务。单线程逻辑服务器固然可以实现，而且具有编码高效、简单的优点，但是不能够很好的利用多核CPU，因此本文就多线程的逻辑服务器设计分析一下。 2. 服务 游戏中有很多不同的逻辑模块为玩家提供了不同的玩法以及游戏内部数据的维护，例如：定时刷新脏数据、组队等等。姑且称这些模块为服务。这些服务可以分为两类：a.只处理玩家个人的数据（定时刷新脏数据）或者局部几个玩家的数据（打副本），它的特点是跟数据具有局部性；b. 处理服务器中所有的玩家数据（组队），它的特点就是数据全局性。b类服务会生成a类服务，例如：组队（b服务）之后去打副本（a服务）。不管什么服务，每个服务中的指令必须按照玩家提交顺序按序处理。 3. 逻辑线程 3.1 每个逻辑线程独自跑所有的服务 针对a类服务，逻辑线程是完美的实现，因为数据局部性不需要处理其他玩家的数据，任何操作都可以在同一个逻辑线程中，各个线程之间没有任何的数据同步。能够充分利用多核CPU。 但是，对于b类服务，显然无法实现。因为，它有一个全局的数据状态（比如由各个队员的状态决定的队伍状态），不能每个线程都需更新。 结论：不能满足游戏的需求。 3.2 一个服务只跑在一个逻辑线程 针对a类服务，跑服务的逻辑线程与数据所在的线程之间具有数据竞争，如果数据繁多，会导致同步很困难。例如：定时刷新脏数据，它涉及的数据包括玩家的众多属性，那么需要为每个属性的更新进行同步，不然会导致垃圾数据。还有一问题，当数据涉及到多个局部玩家的时候，必须保证局部几个玩家的指令按序处理，但是不能保证所有的数据都在同一个逻辑线程，因此无法实现这类服务。 针对b类服务，能够弥补3.1的缺点。同样，存在针对a类服务的问题。但是，全局服务好在竞争的数据不是很多，例如：组队最终的状态一般只涉及每个队员一个状态。 结论：不能满足游戏的需求。 3.3 3.1和3.2混合线程 针对a类服务，用3.1所述的线程，针对b类服务，采用3.2所述的线程，针对b类服务生成a类服务，玩家的数据需要进行线程转移，保证指令的按序处理。 玩家的数据转移 b类服务准备就绪了，生成a类服务，这时需要把b类涉及到的玩家转移到同一个逻辑线程。由于接受玩家指令的线程是网络库中的一个线程，导致在转移玩家数据和通知接受指令线程玩家所在逻辑线程的时间窗口中，玩家还会往非玩家所在的逻辑线程（旧的或者是新的，根据转移和通知的顺序而定）发送指令。解决方式：1.不是同一个逻辑线程的指令就不处理；2.保证在这个时间窗口内不发指令，例如，客户端出现无法操作的画面并向服务端发送该提示，服务端接受到所有的玩家的该提示后进行转移，转移以后通知客户端。 4 总结 服务是需求，是基础，多线程设计是解决方案而已！实现难度大，编写逻辑需要考虑线程同步问题。 |
|
|
