1.前言

新游开服保障是云厂商对游戏客户的重要支持举措之一，帮助客户实现云上稳定的开服也是获取游戏客户信任和长期合作的重要基石，因此作为PDSA需要不仅要掌握云上资源的稳定性，也要协助客户对游戏场景下常见风险的提前风险识别，今天重点就游戏场景下新游开服场景稳定性保障相关内容进行探讨，从全局看，新游戏开服的稳定性保障内容主要包含以下几个方面：

1.

ECS和网络稳定性：游戏服务器的机器配置和网络带宽要足够强大，能够承载大量玩家的同时在线访问。游戏服务器需要部署在可靠的数据中心，确保网络稳定性和电力供应稳定性。

2.

游戏引擎和代码稳定性：游戏引擎和代码需要经过充分的测试和调优，确保在各种情况下都能够稳定运行。在游戏开服前需要对游戏进行压力测试和负载测试，以确保游戏在高并发的情况下仍然能够稳定运行。

3.

数据库稳定性：游戏的数据库需要能够承载大量玩家的数据存储和查询请求，同时需要保证数据的安全性和可靠性。游戏开发者需要采用可靠的数据库管理系统和备份策略，以确保数据的稳定性和安全性。

4.

运营团队和客户支持稳定性：游戏开发者需要组建一支专业的运营团队和客户支持团队，及时响应玩家的问题和反馈，及时处理游戏中出现的问题和故障。

5.

安全稳定性：游戏开发者需要采取各种安全措施，保护游戏系统和玩家数据不受到攻击和泄露。这包括采用加密技术、安全认证、防火墙等技术手段，以及定期进行安全漏洞扫描和修复。 游戏开服的稳定性保障是一个全方位的工作，需要从多个方面进行考虑和保障。



本文主要从数据库角度分析新游场景下，数据库需要检查和准备的内容，开始之前先看下在游戏场景下，数据库面临一些独特的痛点和挑战：

1.

高并发读写：游戏场景通常需要处理大量的并发读写请求，尤其是在游戏开服、活动期间或者大规模多人在线游戏中。数据库需要能够高效地处理这些请求，避免出现性能瓶颈或延迟，以确保游戏的流畅性和响应速度。

2.

数据一致性：游戏中的数据一致性非常重要，尤其是在多人在线游戏中，玩家之间的交互和竞争需要保持数据的准确和一致。数据库需要提供事务支持和数据一致性保证，以避免因为并发操作导致数据不一致或损坏。

3.

数据安全：游戏数据库中通常包含玩家的个人信息、游戏进度和交易记录等敏感数据。保护这些数据的安全性是至关重要的。数据库需要提供安全的访问控制和加密机制，以防止未经授权的访问和数据泄露。

4.

可扩展性：随着游戏用户量的增加，数据库需要能够扩展以适应更高的负载和更大的数据量。游戏数据库需要支持水平扩展和分布式架构，以提供更好的性能和可靠性。

5.

实时数据处理：游戏中的某些数据需要实时处理和展示，例如玩家排行榜、实时战斗数据等。数据库需要能够提供实时查询和计算能力，以及快速的读写速度。

6.

数据备份和恢复：游戏中的数据是非常重要和有价值的，因此数据库需要定期备份和存档数据，以防止数据丢失或损坏。同时，数据库需要提供快速的数据恢复能力，以便在出现故障或灾难时能够迅速恢复运行。

以上是游戏场景下数据库的一些痛点和挑战。通过选择合适的数据库方案，确保数据库在游戏中的稳定性和可靠性。



2.基础信息

针对不同的场景下，数据库的诉求和瓶颈有很大的差异，一般分为：

（1）平台服场景下，典型的计算密集型场景，对锁冲突，高并发读写，SQL效率和性能有很高的要求，尤其是在开服注册登录的瞬间，由于涉及到全局唯一性，一般会使用单个数据库承载，有大量的读写请求，很容易打爆数据库

（2）游戏服场景下，非常典型的存储密集型，游戏的背包通常很大，而且随着游戏的迭代版更，一般会不断的增长，随着背包和道具的增多，对数据库的存储压力也不不断上涨

（3）缓存场景，一般选用redis数据库，数据热点导致的带宽压力大，大key热key，分布式锁，lua脚本也是常见的redis稳定性大杀器

（4）下游数据同步，一般分为实时和定期，在定期场景下拖取数据库的时候，由于背包很大并且是批量拉取数据，因此对带宽，网络稳定性，数据库的IO都有很大的调挑战，极端情况下可能影响数据库的在线业务，因此一般需要跟主节点分开，避免影响线上业务

为了提前预估相关的压力情况以及配合进行压测，需要收集游戏的一些基础信息，以下一些信息一般在压测中客户已经有了明确的目标，但是为了防止客户预估有误，可以提前跟客户在压测和优化阶段对齐：

（1）游戏玩家平均背包/道具等在数据库中的行长大小，一般使用protobuffer格式存储，并且会有压缩，也有直接基于json在mongodb里面存储

（2）峰值的预估PCU大小

（3）预估总的玩家引流数

（4）登录注册峰值，通常新游开服会限制每秒登录注册数，登录注册需要一系列的基础信息操作，因此整体的链路较长

（5）读写请求模型，主要关注最复杂的场景，一般游戏服的读写模型很简单，直接按照uid单行读写，但是有些老游戏由于历史原因，读写存档跟玩家其他信息混在一起，可能有大事务；平台服场景下读写要严格保障事务特性，因此通常会有多SQL的事务

（6）数据库部署情况，比如polardb存储打散情况，redis单分片带宽上限，mongodb分片数等

（7）预估数据库峰值TQPS，直接决定数据库压力和负载

（8）redis上复杂命令使用，排行榜大小（百万千万全局排行榜很容易产生大key），多平台场景下唯一登录控制通过事务保证等

（9）数据库schema设计，比如一行中blob字段个数，更新方式（全量增量更新）

（10）扩展方式，分库分表，分布式数据库，纵向扩展等

（11）连接配置，通常是在使用mongodb场景下，连接串配置情况，保证HA之后继续可用；写配置，直接影响写入的效率，一般游戏场景下可以接受回档，所以为了高效率可以适当放低

3.数据库基本信息

通常基于基本收集的信息，可以大概判断数据库压力情况，以下是一些经验值

（1）PCU = DAU/10

（2）假如玩家背包行长为10KB，则峰值的wal大小为

WAL_IO = PCU * 10KB

上面只是日志大小，一般持久化数据库还包括了其他日志信息和刷脏页，因此总的压力大概为

总IO = WAL_IO * [3-5]

（3）每个数据库的压力

单个数据库压力=（PCU/分库数据（分片数））* 行长大小

（4）业务RPS跟数据库tqps的比例，假如一次登录涉及3次数据库读写

则登录注册人数限制3万的时候，数据库指标为9w tqps

基于以上信息可以大概判断出持久化数据库的压力大小，并且基于此信息在存储上，计算层，以及数据库分分库分表或者分片数进行拆分，评估总的压力大小；对于数据库缓存层，由于请求模式变化非常多，并且影响因素过多，因此通常需要实际压测才能确定相对准确的值

4.数据库巡检

以下分不同的数据库类型，重点在各个指标上进行巡检和保障，并且制作全局大盘，全局分析数据库整体的压力情况



5.数据库参数优化

主要针对游戏场景下常见的数据包含polardb，mongodb，redis等，对相关的参数进行优化和巡检

polardb：

（1）稳定性相关

loose_thread_pool_enabled=ON // 集群参数，建议开启线程池

（2）IO优化相关

loose_innodb_log_file_split_num=4 // 集群参数，并发写redo

loose_innodb_replica_share_log=OFF // 只刷RO节点，redo cache

loose_innodb_redo_log_buf_enable = ON // 打开redo buff

（3）锁和性能优化相关

innodb_thread_concurrency=96 限制单次进入innodb的并发数，降低锁冲突概率，默认640

innodb_polar_blink_tree=on 8.0上特有，打开新的引擎数据结构blink

mongodb：

（1）稳定性相关

ecs 上的 readahead 参数，blockdev --setra 8 /dev/nvme1n1

net.compression.compressors 开启压缩

（2）IO优化相关

调整 mongod 的参数，降低 history snapshot window 到 0，eviction_dirty_target 刷脏阈值到 3%，提升 eviction 的线程数到 8

db.adminCommand( { setParameter: 1, minSnapshotHistoryWindowInSeconds: 0, wiredTigerEngineRuntimeConfig: "eviction_dirty_target=3,eviction=(threads_min=8,threads_max=8)" } )

（3）性能相关

ShardingTaskExecutorPoolMinSize 调整至 100 最小保持连接数

ShardingTaskExecutorPoolMaxConnecting 调整至 8 最大同时并发【创建】连接的个数。

redis：

（1）性能相关

关闭AOF落盘 appendonly = no

定期任务频率 hz hz的取值范围为1~500。增大hz参数的值会提升各项定期任务的执行频率，但也会提高Redis服务的CPU使用率。默认值10在一般情况下已经可以满足需求，如果业务场景对于某些定期任务的执行频率有很高的要求，您可以尝试在100以内调整参数值。将hz的值增加到100以上对CPU使用率有相对较大的影响，请谨慎操作。

（2）内存大小

client-output-buffer-limit pubsub

（3）稳定性

admin连接数 只能后台修改，主要控制watch multi exec lua脚本 pubsub等的连接数使用

详情参考：

https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis?spm=a2c4g.11186623.0.0.77153471uxDtJl