前几天在弄数据库方面的问题，之前来这边时就选择好了某个数据库，以往没有相关经验，但用起来挺方便的，也不知道会踩什么坑，没有时间去学习它。
因为后面数据库方面的维护和什么主备啥的都由腾讯那边或者公司运维的同事来搞，所以有些问题开发这边是无法掌控的。
开发这边主要保证按照一定的规则定时同步数据落地即可，不造成严重事故和回档。数据库可能跟业务进程在一台机器可能也不在，那就需要考虑断开链接情况。还有更新策略以及数据量大小等问题，以免造成数据库那边雪崩服务不可用。
因为游戏业务相比较来说，不是特别复杂，业务进程连接数据库后，需要保持这个链接存在，断开能自动重连，对上层业务无感知，要评估如果在同步数据的时候发现连接断开了那么对当前要同步的数据进行丢弃是否严重，重连的过程是同步的还是异步的是否会阻塞当前线程(协程)。由于使用底层框架，在与db的连接断开后，会发生某类型消息，回调到上层后进行处理，并把该连接从pool中删除，此时并没有重连。而在每次同步更新数据时，会检查这条连接是否还在pool中，如果断开则尝试一定次数的重连等操作，这些逻辑已经实现了，这里的重连交由底层的“业务”代码而不是更底层的socket，因为做到通用，那么具体则有上层去决定要不要重连。
之前同步数据是都自动更新的，由更上层模块注册存储功能，后者自动更新，而且是全量，当时设计可能并没有过多考虑优化的事情，先把功能做好，写对，再去优化。这里造成几个问题，一是要更新的数据量可能过大，造成db那边阻塞，如果不在一台机器而走网络可能有些问题，二是有些数据不怎么变化每次全部更新不可取，建议做增量更新，粒度更小些，还有些活动数据排名，某个时间段有变化其余时间不变，那么在其他时间可以取消注册更新，还有些数据需要做个预估，比如有的玩家不在线，再也不玩游戏了，那么给他发的不同邮件就不能一直发，不然造成严重堆积。
所有这些问题都可以解决，把自动更新的随机个超时时间不至于同一时间点都超时给数据库造成压力。对每个要更新的数据加个dirty字段，业务更新的时候设置true，存储那边要更新的时候检查下有没有设置true，然后再重置这个字段。这样先做到一级的粒度，后面可以再细化二级等，看怎么需要。有些数据不一定非的更新到数据库中，比如帮派的日志，这种丢失其实关系不大，反正细节是挺多的。
其实游戏中有好些系统功能都有着不错的设计方案，不管这些方案是要考虑复杂性，还是性能以及体验方面，改天写下邮件系统怎么做比较好些。
前面的几篇记录都是工作中相关的经历，有好一段时间没有分析开源项目。后面会找个时间记录下分析腾讯MMKV开源项目的几个技术点，之前没有接触过这几个技术点，算是学习，以后遇见相似的问题时可以作为参考。
网友评论