本文记录用全区全服的方式实现分区分服类型的游戏的一些思路。
持续更新，想到什么写什么。
1. 问题与挑战
今天跟一个大哥聊了用全区全服的架构做分区分服游戏的问题。这个让我想起了之前看过的一篇文章：《天美J3工作室服务器主程：我们怎么避免上线即炸服？》 。
用全区全服的方式来做分区分服，好处是：
- 合服或转服的场景，可以不用做数据迁移；
- 共用服务器、数据库，可以提高整体的资源使用率。
挑战是：
- 数据隔离；
- 压力隔离；
- 故障隔离。
todo
- 数据库选型
- 数据表设计
- 模块划分，进程功能划分
- 如何做好数据隔离、压力隔离、故障隔离
- 如何做到只维护部分服务器
- 如何满足过去分区分服的所有操作
2. 数据库选型
共用数据库，那么数据库的容量就是个需要考虑的问题，单靠 scale up 不太行，要能 scale out。所以，带 sharding 能力的数据库需要考察一下。
1、MySQL
带 sharding 能力的 MySQL 也有，但是用于生产，多少有些力不从心，分析如下。
数据源类型的：
a. TSpider，之前跟腾讯合作的时候用过，但是闭源的，而且腾讯云也不提供。
b. TDSQL 分布式版本，负载能力未知；腾讯云专有的，容易被锁定。
c. TiDB，还没怎么听过应用在游戏行业，更多是金融领域。
中间件类型的：
a. 华为云的 DDM，没用过，可靠性不详，扩展性不详；华为云专有的，容易被锁定。
b. Apache 的 ShardingSphere，没实际在生产上用过的，很容易翻车。
c. 某 Cat，这个很垃圾，不要用就是了。
2、tcaplus
腾讯内部基本上都是用的这个，腾讯云有提供。性能跟实践无需多言，肯定是支持海量数据的，sharding 能力不用担心。但腾讯云专有，容易被锁定。除非是跟腾讯合作发行的游戏，否则不应该使用。
另外，据内部消息，这个的使用费用较高。
3、MongoDB
MongoDB 的 scale out 方案是分片集群，相关的调研，我写在了这篇文章：《mongodb 笔记：分片集群》 。
MongoDB 从 1.6 版本就开始支持 sharding 了，至今（2024-8-22）已经迭代到 7.0 版本，技术上比较成熟了。
从 5.0 开始，支持自动的 reshard，即可以修改 shard key，后台自动进行 reshard，虽然这种操作仍然需要有不少的性能冗余，但至少是自动化执行的。使用 MongoDB 分片集群，首要就是做好 shard key 的选择，花足够多的注意力在这个上面，基本上不会翻车。
另外，有非常多的游戏使用 MongoDB 作为数据库，行业经验比较丰富。
总结
综合下来考虑，MongoDB 的分片集群是一个比较合适的方案。