dbmgr数据缓存实现方式

在游戏服务器的开发中，在数据库的前端常常采用一个数据服务器用来缓存游戏数据，并批量提交事务来提高整套系统的整体性能。
请参考   < 系统架构之一（RPG游戏常用架构）> 中描述的dbmgr
在这里我描述一种经过实践并在大型游戏项目中使用的dbmgr采用的缓存策略:


dbmgr 采用内存数据库fastdb来缓存非日志类的数据，
对于象玩家状态等这些数据始终缓存在fastdb的内存数据库中
对于日志类的流水表那些更新进DB后，就不会在FASTDB保存了。


dbmgr收到事务请求后，先组织一个事务对象，对象里面包括了对当前事务中所有库表对象的更新操作
同时在fastdb内存数据库中执行事务，并将事务对象保存到事务日志队列中。
dbmgr启动单独的线程定时从事务日志队列中批量取出事务对象更新到DB中



这种方案存在的问题：如果DB出现故障的情况下，dbmgr的内存会被写的越来越大，可能会出现大量数据同步不到DB的风险，
另dbmgr程序崩溃，会导致未同步到DB的数据丢失。 往往某些项目从商业上来说可能允许一定时间范围内的数据回档故障，
我们在设计上可以要求必须在这个时间范围内同步到DB，一旦超过这个时间，就只能报警，并停止系统运营，直到恢复正常。
对于那种不允许任何数据丢失，不可能容忍数据回档的项目，那么就必须实时同步到DB中了，当然实时同步到DB中时，也可以将
大量事务集中到一起采用批量事务提交，来提高整套系统的吞吐量。


dbmgr在同步数据到DB中时，采用多个线程同时批量提交事务的方式，线程个数，每个批量事务中允许事务最多的个数，
这些都可以通过配置参数根据系统环境，软硬件配置来调整以获得最优效果。



在这个项目中 为了简单起见所有的事务控制由dbmgr来控制，dbmgr不允许请求方来开始事务，结束事务，每一个请求就是一个事务，
如果要做的复杂些允许请求者控制事务的话 ，dbmgr中要加进事务状态管理。以及处理各种事务异常的情况，例如要
有一个定时检查事务状态的功能， 例如某些情况下，客户端启动了一个事务，但一直没有调用结束事务， 或网络断了，
这些情况要自动识别并回滚事务。