1.事务的问题
如果是mysql，一般的设计是在处理玩家数据时，一个业务内操作多张表，如果有一个操作失败，则所有的数据回滚。
mongodb的话，无法回滚，针对这种问题的解决方案是：操作mongodb，其实在落地前，是存放到临时的json中，如果操作业务异常了，那么就也不会落地，这样子变相解决了事务的问题。
2.mongodb和redis不一致的问题
如果是mysql，一般是：使用mysql的binlog，实现最终一致性。
mongodb则没有这些，我们解决方案是：由于mongodb存储业务尽量用一个document解决，因此我们针对每一部分，设计了一个模块缓存。当数据落地 时，就同时修改了redis，这样子就保证了redis一定是一致的。
别的服务器访问redis的数据，一般都是只读的。想修改，则要rpc到这个对应的线程中。
