1.3.4　业务处理框架

业务处理框架是为了便于业务功能开发，对影响业务功能开发的公共部分进行架构规划，尽量让开发人员专心于功能设计与开发，并提供底层的基础支持。一般有3个模块。

1.消息管理

游戏用户操作的过程，对服务器来讲就是修改游戏数据。在服务器架构中，网络层的数据接收和请求的业务处理会在不同的线程中，一个游戏用户的数据只有一份，用户有可能同时修改这份数据，这就有可能出现多线程操作共享数据的问题。解决这个问题的一种方式是对数据修改进行加锁。但是由于游戏用户数据很多，导致需要对服务器发送大量并发请求，多线程执行加锁代码时，为了获取执行权和保存线程执行状态，会导致CPU大量的上下文切换（指CPU从正在执行的线程切换执行另一个线程），反而减少了服务器的消息处理的吞吐量，使性能下降。而且如果控制不好加锁，也容易出现死锁的现象。

另一种方式是不加锁，让同一个用户的数据按顺序处理。一种实现方法是把同一个用户的请求先放到一个队列中，不同的用户的请求可以分到不同的队列中，再对每个队列固定启动一个对应的线程处理队列中的消息。这样可以避免加锁引起CPU产生大量的上下文切换，也保证同一个用户的数据，都在同一个线程中处理，避免并发修改共享数据。

2.线程管理

在游戏服务器中，线程是一种非常珍贵且重要的资源，也是处理并发的唯一手段。但并不是说线程越多越好，线程太多，也会使CPU产生大量的上下文切换，使线程处理业务的能力下降。要合理地规划线程的使用，才能使线程的利用率最大化。

对线程的合理分配，可以更好地优化服务器的性能。比如分配专门的线程池处理游戏业务，另外分配专门的线程池负责数据的操作，把耗时操作隔离到固定的线程中，减少对业务线程的卡顿，增加业务消息的吞吐量。因此在游戏服务开发中，不能随意地创建线程，一定要有规则和标准。

3.数据缓存与持久化

在业务服务中，所有的操作都是依赖于数据。数据存储于数据库，但是把数据缓存在内存之中，可以避免操作数据时查询数据库而浪费时间。因此游戏数据什么时候加载到内存，如何将内存中的数据更新到数据库之中，也是架构要解决的问题。这样可以把数据的管理统一化，业务开发中只需要操作内存的数据即可，即使不了解数据库相关的知识也能很快开发业务。