大型系统容量评估和性能保障（二）

跟小飞哥一起飞......不怕掉下来

综述：为方便阅读和整体把握，把整个系统性能方面学习整理为四篇，建议按顺序学习，如下：

第一篇—架构设计考虑的要素

第二篇（本篇）—提出的一个需求设计系统

第三篇—对设计的系统进行测试方案

第四篇 —常用的测试工具

===========本文主要内容===========

1，量级评估标准

——通用标准参考

——应用级参考标准

——系统级参考标准

2，案例容量评估设计

——需求描述

——数据库评估

——缓存评估

——应用服务器评估

3，记忆方法与总结

==================================

一、量级评估标准

注：标准只是单台测试机数据，实际会有差距，数据只是拿来评估容量。

通用标准参考

容量按照峰值5倍冗余计算

分库分表后的容量一般可存储30年的数据

第三方查询接口吞吐量为5000/s

单条数据库记录占用大约1KB的空间

应用级参考标准

1，应用服务器

单台：5000/s

2，Mysql

单端口读：1000/s

单端口写：700/s

单表容量：5000万条

3，Redis

单端口读：40000/s

单端口写：40000/s

单端口内容容量：32GB

系统级参考标准（见组成原理）

寄存器、内存

磁盘I/O

网络I/O

二、案例容量评估设计

需求说明：

1，维护用户常用地址，下单时提供其地址列表

2，设计为某一线电商平台（如**多）

用户量当前两亿，平均每天增长5万个，平时每天订单量为400万个，下单时段集中9-23点，促销时日订单为1400万个，50%的下单时段集中在19：30-20：00，22：00-23：00.

1，数据库评估：假设每个用户有3个常用地址

（1）表容量

30年后用户量Users: 2亿+30年*365*5万=7.4740亿

用户地址数量Address：3*Users =22.425亿

5倍冗余设计容量Data：5*Address = 112.125亿

每张表5千万条：Data/0.5=224.25，=>需要225张表

（2）读操作吞吐量评估（按照峰值）

订单集中量：1400万*1/2 = 700万

2小时内平均：700万/（2*60*60）=973/s

5倍冗余读：5*973/s=4861/s（取5000）

需要数据库读服务器：5000/s / 1000/s = 5台

（3）写操作评估,假设每增加一个用户，增加一个地址，高峰期20%订单增加地址.

需要增加地址量：5万+1400万*0.2=285万

2小时内平均：285万/（2*60*60）=396/s

5倍冗余读：5*396/s=1979/s（取2000）

需要数据库读服务器：2000/s / 700/s = 3台

综上：225张表，主从部署3主5从。可采用32个库，考虑对齐，可采用4主8从。

2，缓存评估：使用redis缓存常用用户地址，每天下单用户地址缓存24小时

需要缓存容量：1400万*3*1KB = 42000KB= 40G

5倍冗余：5*40G=200G

按照单机32G，需要7台。

3，应用服务器评估：

订单集中量：1400万*1/2 = 700万

2小时内平均访问：700万/（2*60*60）=973/s

单台可支持5000/s,一台即可。

三、记忆方法与总结

这里只是拿出一个环节分析，对于分布式，考虑使用消息队列的，还需要分析中间件等。

如有分析有误或更好意见欢迎反馈。

================= END ==================