聊聊全球同服-数据库高可用的保证

上一篇介绍了全球同服下的逻辑去中心化的解决方案，也看出对底层数据库的依赖，这一篇就介绍一下数据库的高可用集群。

在我们的项目中，游戏数据库主要使用的mongodb和redis，mongodb为主，redis为辅，这一篇主要介绍一下mongodb的高可用集群，redis后面结合在游戏中的使用再说。

为什么选择mongodb而不是mysql，主要是对于游戏逻辑而言，mongodb的文档类型更合适，可以很好的解决逻辑字段频繁变化的问题，至于统计数据，可以通过日志导到mysql里面去做，玩家的数据其实就是一大坨，这一点后面会结合entity系统再介绍一下，这里不多说。

先说一下mongodb的高可用基础。

mongodb 通过复制集 replica set 来实现高可用和数据备份

replica set 就是一组mongod进程，在我们生产环境中每个replica set 由一个primary 节点和 2个 secondary 节点组成，且备份节点与primary节点完全隔离。主节点接收所有的写操作。然后会通过oplog 同步给secondary节点。

节点之间有心跳来维护存活状态，当primary节点发生故障，心跳消失，secondary节点在10s（可配置）中还没有收到primary节点的心跳，就会发起投票，推荐自己为新的primary节点。集群根据算法会在发起投票的secondary节点中选举出一个作为新的primary节点，然后服务恢复正常。在选举过程中，集群无法对外提供写的操作，只能提供读操作。

这里可以看出高可用的基本策略，就是冗余备份，当主节点出现问题后，备胎可以接替主节点继续提供服务。备胎和主节点一般部署在不同的机器上，防止机器出现故障同时无法提供服务。

只有冗余还不够，出现故障时，还需要可以自动切换，也就是对应上面提到的选举的过程，选举中间的道道有很多可以讲的，mongodb的选举是一个简化的过程，而且还提供了arbit来进一步简化选举过程，业内通用的选举协议是raft，etcd就是基于raft实现了一个高可用的一致性数据库，后面会结合raft介绍一下选举过程。