游戏业务逻辑和DB无阻塞实现

程序阻塞的情况通常是等待资源，通常业务逻辑都是附带DB操作的，有时候因为DB阻塞或者执行时间过长，导致业务层的线程给占用，比如开了4个线程来处理业务,那么当4个线程

都处理阻塞时，其他新请求业务的用户将得不到满足，不管用户的业务逻辑是否有进行DB操作。通常作法是这样的
方法1(...参数){
 1.业务逻辑判断
 2.DB操作(一般事务处理)
 3.返回
}
通常是在第2步执行时间过长引起阻塞，那么是否可以将第2步放到另外的线程(或线程池)里跑呢？等第2步执行完了,我们再让该任务回来业务逻辑线程(或线程池)里,然后执行第3

步.如果这种方法可行，那么业务逻辑将变成这样
业务逻辑层方法1(...参数){
 1.业务逻辑判断
 2.DB任务(放到DB操作线程池)
}
DB层方法2(...参数){
 1.DB操作(一般事务处理)
 2.业务逻辑任务(回到业务逻辑池)
}
业务逻辑层方法3(...参数){
 1.业务逻辑返回
}
很多情况都可以这样处理，多人在线游戏在逻辑服务器跟DB服务器之间通常都有一个数据服务器,数据服务器就是专门来做第2步操作的，不管数据服务器处理多慢，其主要的逻辑服务器都能满足业务逻辑需要。
业务逻辑服务器处理业务的线程是有限的，那么我们不可能因为某个玩家请求某个特定的业务，因为这个业务DB执行时间过长而使该线程一直被该业务占用，在这种情况下，我们把DB任务入到数据服务器，由数据服务器去处理，当数据服务器返回时，这时候再继续未完成的逻辑。
端游作法一般就是多台服务台处理多个应用层，跟上面情况差不多。
页游一般是两台一组，DB和游戏服务器，游戏服务器可以靠开启多条线程或多个线程池来实现这样的架构逻辑。