# 集群能力评估

+ 写入 QPS
+ 读取 QPS

![`smart`](ClusterCapacityAssessment_zh_001_20240314.png)

----------------------------------------------------
数据库迁移容量评估还涉及源数据库能力和目标数据库能力的转换。

- 写入 QPS
通过以上容量评估方法获取基准实例的写入 QPS，不过需要注意的是在传统单机数据库的单机写入 QPS 一般是远大于主从复制 QPS 的，所以单个集群写入能力是不能超过复制 QPS 的，否则会导致从库无法读取到最新数据。所以这种情况下单个集群真正的写入能力一般会取主从复制 QPS 能力，除非是仅单机部署。
如果是云厂商的云数据库 Aurora，因为是单点写入，数据同步通过底层共享存储来实现，一般情况下复制吞吐能力会比传统 MySQL 逻辑复制上限高很多。但是 Aurora 在写入时候就需要同时向共享存储写 redo log 6 次，如果在单行长度较大的场景，比如游戏服习惯的用 JSON 或者 Blob 存储玩家数据，单行长度可能会到几百 KB 级别，这时如果写入量较大，可能会导致主节点的网卡被打满，容量评估时需要考虑这种情况对写入能力的限制。

- 复制 QPS
上面也说到传统单机关系型数据库写入能力不只受限于实例的配置，同时还受限于主从复制能力，并且主从复制能力一般情况下是小于主节点写入能力的，尤其是 MySQL 基于逻辑日志复制的机制下。例如典型的 MySQL 5.7 集群，电商订单业务的主从并行复制最大 QPS 大概在 10000 QPS 左右，运维人员容量评估时为了保险起见，会将单集群写入能力限定在 5000 - 8000 QPS 左右，避免业务写入量大导致主从延迟，进而导致用户在从节点无法读取到最新的用户数据产生数据不一致问题。所以如果遇到写入大于  5000 - 8000 QPS 的业务，除非经过实际的业务流量压测出实际的主从复制能力，否则则需要进行分库分表或者迁移到分布式关系型数据库。
同时需要评估的是同步到下游数据的能力，确保写入的数据可以准实时（秒级）的发送到下游业务及时的进行消费和处理。

- 读取 QPS
如果是传统单机关系型数据库读取 QPS 需要在有主从复制写入情况下测试。读取 QPS 不管是在传统关系型数据库（通过增删读实例，读实例上线一般在 10-20 个左右）还是分布式数据库，一般情况下是可以做到近似线性扩展，所以一般只需要评估出参考集群的读取能力即可按照业务需求进行水平或者垂直扩展。

- 读写混合 QPS
有了单元数据库集群单独的读取和写入 QPS 评估数据，并不代表就能通过计算得到业务需要的容量，因为有部分数据库在读写混合模式下，可能会出现写入影响读取的情况，比如 Aurora，在写入量大的情况下，读节点引用 redo 日志的速度会受到影响，进而影响读取的性能，所以还需要根据一定的读写比例压测出该型数据库在参考集群配置下的读写 QPS 容量。