跟小飞哥一起飞......不怕掉下来
综述:为方便阅读和整体把握,把整个系统性能方面学习整理为四篇,建议按顺序学习,如下:
第一篇—架构设计考虑的要素
第二篇(本篇)—提出的一个需求设计系统
第三篇—对设计的系统进行测试方案
第四篇 —常用的测试工具
===========本文主要内容===========
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 ==================
领取专属 10元无门槛券
私享最新 技术干货