互联网性能与容量评估的方法论和典型案例

3.3 方案描述

方案1

整个方案需要参考技术评审指标提出的各方面指标来考虑满足系统的非功能质量需求。

• 概述

  一句话概括方案的亮点，比如说: 双写，主从分离，分库分表，扩容，归档等。

• 详细说明

  方案的具体描述，文字描述不清楚的话可以结合图（任何图：UML，概念图，框图等）的方式说明，如果是改造方案最好突出变动的地方，以下列举了几种描述的角度：

  • 中间件架构（应用服务器、数据库、缓存、消息队列等）
  • 逻辑架构（模块划分、模块通信、信息流、时序等）
  • 数据架构（数据结构、数据分布、拆分策略、缓存策略、读写分离策略、查询策略、数据一致性策略）
  • 异常处理，容灾策略，灰度发布

• 性能评估

  给出方案的基准数据，并按性能需求评估需要使用的资源数量。

  • 单机并发量
  • 单机容量
  • 按照预估性能需求，预估资源数量(应用服务器、缓存、存储、队列等)
  • 伸缩方式

• 方案优缺点

  列出方案的优缺点，优缺点要具有确定性，不要有“存在一定风险”这种描述，也就是要量化。

4 性能和容量评估经典案例

4.1 背景

物流系统包含如下两个质量优先需求：

1. 维护会员常用地址，下单时提供会员地址列表。
2. 下单时异步产生物流订单，物流系统后台任务从第三方物流轮循拉取物流状态，已经下单用户查询订单的物流订单和物流记录。

由于会员数量较大，可能有较快的增长速度，订单数量更是巨大，促销期峰值的订单产生量可能很高，这两个业务模块的数据存储需要分库分表，并借助消息队列和缓存抗写和读的流量，因此，本方案主要涉及这两个业务的容量评估。

4.2 目标数据量级

选取行业内一线电商平台的量级作为目标：

1. 会员量2亿，平均增长5万/天。
2. 平时订单量400万/天，所有订单下单时段集中在9:00-23:00，促销日订单量1400万/天，50%订单下单时段集中在晚上7:30-8:30和晚上22:00-23:00。

4.3 量级评估标准

通用标准

1. 容量按照峰值5倍冗余计算。
2. 会员常用地址容量按照30年计算，而物流订单时效性较强按照3年计算。
3. 第三方查询接口5000 QPS。

Mysql

1. 单端口读：1000 QPS
2. 单端口写：700 TPS
3. 单表容量：5000万条

Redis

1. 单端口读：4万 QPS
2. 单端口写：4万 TPS
3. 单端口内存容量：32G

Kafka

1. 单机读：3万 QPS
2. 单机写：5000 TPS

应用服务器

1. 请求量每秒峰值：5000 QPS

4.4 方案

方案1. 最大性能方案

由于整个电商网站刚刚上线，数据量级还无法清晰的确定，我们根据行业内知名电商当前数据量级设计最大性能方案，本方案可以应对行业内电商巨头的各种促销所带来的服务请求峰值，并且拥有最快的响应时间，达到服务性能的最大化。

需求1. 会员常用地址

整体流程：

1. 提供Restful服务增加会员常用地址。
2. 提供Restful服务获取会员常用地址列表。

数据库资源评估：

读QPS：

会员每次下单，拉取一次会员地址列表，按照促销日订单量1400万/天，50%订单下单时段集中在两个小时内计算：

(1400万 × 0.5) / (2 × 60 × 60) = 1000/秒

容量评估按照5倍冗余计算，读QPS峰值1000/秒 * 5 = 5000/秒，需要5端口数据库服务读。

写TPS：

假设每天增加的会员全部添加一次常用地址，并且高峰期会员下订单时有20%的会员会增加一条常用地址：

(1400万 × 0.2 + 5万) / (2 × 60 × 60) = 400/秒

容量评估按照5倍冗余计算，400/秒 * 5 = 2000/秒，需要3端口数据库服务写。

数据容量：

当前有2亿会员，每天增长5万会员，平均每个会员有5个常用地址，30年会员常用地址表数量计算：

（2亿 + 5万 × 365 × 30年） × 5 = 35亿

容量评估按照5倍冗余计算，35亿 * 5 = 175亿，需要350张表即可容纳。

根据以上读QPS、写TPS的评估，如果读写混布我们共需要8端口，可以使用8主8备，如果读写分离，我们需要做主从部署，需要3主6从，与2倍数对齐，使用4主8从即可。

根据表容量，需要350张表，和2的指数对齐，选择512张表，上面计算需要主库端口为4，考虑到将来端口扩展不用拆分数据库，尽量设计更多的库，使用32个库。

设计结果：4端口 × 32库 × 4表， 4主8从

缓存资源评估：

为了提高用户下单的体验，需要使用Redis缓存活跃用户的常用地址。

定义当天下订单的会员为活跃会员，活跃会员的地址缓存24小时，假定每天下订单的会员均为不同会员，每个会员有5个常用地址，缓存大小计算如下：

1400万 × 5 × 1k = 70G

容量评估按照5倍冗余计算，70G×5=350G，按照每台Redis 32G内存计算，需要11台机器，根据数据库对数据存取QPS/TPS的设计，11台机器完全可以满足5000/秒的读QPS和2000/秒的写TPS。

设计结果：11台，主从

应用服务器资源评估：

根据数据库的读QPS（5000/s）峰值和写TPS（2000/s）峰值计算，单台应用服务器即可，选择2台避免单点。

设计结果：2台

需求2. 物流订单和物流记录

整体流程：

1. 订单提交后，通过消息队列产生物流订单，消息传入物流系统，物流系统消费物流订单消息然后入库。
2. 后台任务轮循未完成物流订单，查询第三方物流接口状态，填写物流记录信息。按照每天1400万的订单，订单平均3天到货，第三方查询接口5000 QPS，每次状态查询需要时间计算如下： 1400万 × 3 / 5000 = 8400 / 60 / 60 = 2小时，定时任务2小时查一次。
3. 提供REST服务获取物流订单信息。
4. 提供REST服务获取物流记录信息。
5. 提供REST服务获取物流订单和物流记录信息。

数据库资源评估：

读QPS：

会员下单三天到货，三天内50%客户会查询一次物流订单和一次物流记录，计算如下：

(1400万 × 3 × 0.5) / (24 × 60 × 60) = 250/秒

容量评估按照5倍冗余计算，2 × 250/秒 × 5倍 = 2500/秒，需要3端口数据库服务读。

写TPS：

会员每次下单，产生一次物流订单，按照促销日订单量1400万/天，50%订单下单时段集中在两个小时内计算：

(1400万 × 0.5) / (2 × 60 × 60) = 1000/秒

按照每天1400万的订单，订单平均3天到货，每条物流订单产生8条物流记录，并且8条物流记录在三天内均匀产生，物流记录写TPS计算如下：

1400万 × 3 × 8 / 3 / （24 × 60 × 60） = 1200/秒

容量评估按照5倍冗余计算，(1000/秒 + 1200/秒) * 5 = 11000/秒，需要15端口数据库服务写。

数据容量：

当前2亿物流订单积累，每天增长400万订单，30年订单数量计算：

2亿 + 400万 × 365天 × 3年 = 46亿

容量评估按照5倍冗余计算，46亿 * 5 = 230亿，需要460张表即可容纳, 物流记录表是物流订单的8倍，460 × 8 = 3680张表。

根据以上读QPS和写TPS，如果读写混布，我们共需要18端口，18主18备，如果读写分离，我们需要16主16从。

根据表容量，需要3680张表，和2的指数对齐，选择4096张表，上面计算需要主库端口为16，考虑到将来端口扩展不用拆分数据库，尽量设计更多的库，使用32个库。

设计结果：16端口 × 32库 × 8表，16主16从

消息队列资源评估：

为了让系统能够应对峰值的突增，采用消息队列Kafka接收物流订单。

根据上面对写TPS的计算，考虑5倍冗余后，峰值为5000/秒，单台Kafka和单台处理机即可处理。

如果峰值有突增，可以增加Kafaka集群的节点来抗写流量，处理机根据后端入库性能来决定。例如写峰值增加10倍，达到5万/秒，需要10台Kafka，每台Kafka读QPS可达3万，理论上需要2台处理机，然而，处理机的瓶颈是后端入库的写TPS，根据上面计算，入库的写TPS峰值按照5000/秒设计，因此，单台处理机即可，这个场景下会有消息的堆积，但是最终会处理完毕，达到消峰的效果。

设计结果：1台Kafka，主从，1台处理机

应用服务器资源评估：

根据数据库的读QPS（2500/s）峰值和写TPS（11000/s）峰值计算，3台应用服务器即可。

用于查询第三方接口的后台任务服务器，由于受到第三方接口5000/s的QPS的限制，单台机器即可，为了避免单点，2台处理机即可。

设计结果：2台

方案2. 最小资源方案

由于当前系统线上数据量并不多，增长量也不大，读QPS和写TPS单台机器完全可以处理，暂时不考虑使用缓存和消息队列，但是保留使用缓存和消息队列的接口，如果缓存和消息队列的资源可用，可以通过开关进行切换。

当前的数据量使用单库单表即可处理，然而，考虑到将来扩容方便，数据库端口暂时使用一个，但是保留我们在最大性能方案中对数据库的分库分表，当读QPS和写TPS突增时，DBA可以把库重新拆分到多个端口来抗请求流量。

因此，方案如下：

会员常用地址

设计结果：1端口 × 32库 × 16表， 1主1从

物流订单和物流记录

设计结果：1端口 × 128库 × 32表，1主1从

4.5 总结

倾向于采用最小资源方案：

1. 当前线上流量并不大，使用最小资源方案节省成本。
2. 最小资源方案充分的考虑了数据库的分库分表，当读QPS和写TPS突增时，DBA可以拆分库到不同的端口，也就是增加端口来应对。
3. 最小资源方案在应用层设计了开关，如果性能突增可以临时申请和开启缓存和消息队列。

5 性能评估参考标准

以下标准是使用PC X86机器的经验值，仅供参考，评审时应该随着机器的不同而做调整。

通用标准

1. 容量按照峰值5倍冗余计算。
2. 分库分表后的容量一般可存储30年的数据。
3. 第三方查询接口5000 QPS。
4. 单条数据库记录占用大约1K空间。

Mysql

1. 单端口读：1000 QPS
2. 单端口写：700 TPS
3. 单表容量：5000万条

Redis

1. 单端口读：4万 QPS
2. 单端口写：4万 TPS
3. 单端口内存容量：32G

Kafka

1. 单机读：3万 QPS
2. 单机写：5000 TPS

DB2

1. 单机读峰值：20000
2. 单机写峰值：20000
3. 单表容量：1亿数据

6 总结

本文以互联网企业重点关注的非功能质量为主线，总结了非功能质量需求的总体目标，并针对不同的服务和资源列举了不同的非功能质量需求，帮助读者在做技术评审的过程整理思路，尽量穷举评审时关注的评审点，并随后提供了一个简单有效的评审提纲，最后根据提纲实现一个互联网容量和性能评估的经典案例，大家可以在案例中了解高并发互联网系统是如何进行拆分的，以及依据哪些数据进行拆分。