架构设计（容量分析）

架构设计（容量分析）

容量分析

性能标准（不同机器数值会有差异）

# mysql
单端口读：5000/s
单端口写：3000/s
单表容量：5000万

# redis
单端口读写：4万/s
单端口内存容量：32g

# kafka
单端口读：3万/s
单端口写：5000/s

# 应用服务器
处理请求的峰值：5000/s

场景1：用户下单地址读写，使用缓存存储常用地址

用户量2亿，每天增长5万
促销日订单量1400万，且50%的订单集中在2个小时内
假设新增的用户全部增加一条地址，并且高峰期20%的用户在下单时添加地址
当前2亿用户，每天增长5万，平均每个用户5个地址，按照30年计算
按照峰值的5倍冗余设计，常用地址容量按照30倍计算

# 数据库mysql计算
读吞吐量：(1400万*0.5)/(2*60*60)=1000/s，5倍冗余：5000/s，需要1个端口
写吞吐量：(1400万*0.2+5万)/(2*60*60)=400/s，5倍冗余：2000/s，需要1个端口
数据容量：(2亿+5万*365*30)*5=35亿，5倍冗余：175亿，需要350张表
读写混合部署：2主2从
读写分离部署：1主1从
表的数量：2的指数对齐，需要512张表（考虑到端口拓展时不用拆分数据库，尽可能使用更多的库）
设计结果：1端口*32库*16表、1主1从

# 缓存Redis计算
当天下单用户全部为活跃用户，缓存24小时，
每个用户5调地址，每条地址数据大小1kb
读写：redis可以处理读5000/s、写2000/s
数据容量：1400万*5*1kb=70g，5倍冗余350g，360g/32g=11，需要11台redis服务器
设计结果：11主11从

# 应用服务器计算
单台服务器可以处理读5000/s、写2000/s
为防止单点故障，使用2台应用服务器

场景2：通过消息队列异步产生物流订单，并提供查询服务

用户下单3天后到货，三天内50%的用户每天查询一次物流订单、物流记录
用户下单产生一次物流订单，促销日订单量1400万，50%的下单集中在2个小时
按照促销日每天产生1400万订单，订单3天到货，每个订单产生8个物流记录，8条记录在3天内均匀产生
当前又2亿条订单数据，每天新增400万订单，按照3年订单量存储数据
三方物流记录查询接口吞吐量峰值：5000/s

# 数据库计算
读吞吐量：(1400万*3*0.5)/(24*60*60)=250/s，5倍冗余1250/s，1个端口
写吞吐量：(1400万*0.5)/(2*60*60)=1000/s，
         (1400万*3*8)/(3*24*60*60)=1200/s，
          5倍冗余(1000/s+1200/s)*5=11000/s，需要4个端口
数据容量：物流订单数据2亿+400万*365*3=46亿，5倍冗余；230亿，需要460张表
         物流记录数据是订单的8倍，需要460*8=3580张表
混合读写：5主5从
读写分离：4主4从
考虑到端口拓展师不拆分数据库，尽可能设置更多的库
设计结果：物流订单表 4端口*16库*8表、
         物流记录表 4端口*16库*64表
         4主4从

# 消息队列计算
物流订单通过kafka发送，5倍冗余峰值为5000/s，单台kafka可以满足需求
设计结果：考虑到单点问题，至少使用2台kafka机器

# 定时任务轮询物流记录时间间隔
每天产生1400万订单，平均3天到货
1400万*3/5000=2h，定时任务每隔2小时查询一次

# 应用服务器计算
读吞吐量：1250、写吞吐量：11000/s，3台应用服务器可以处理
定时任务轮询三方记录服务器：单台服务器就可处理，考虑单点故障，使用2台服务器

性能分析

性能指标

响应时间：请求得到响应花费的时间
并发数：服务器可以同时处理的请求数，与cpu数有关
tps=1/响应时间 * 并发数

压测观察指标

# 性能查看命令：free、top、iostat、netstat等
系统：cpu、内存、磁盘io、网络带宽等

# 可用ab测试、jmeter进行压测，获取压测数据
服务：接口吞吐量、响应时间、超时情况
数据库：慢查询、sql是否发生死锁、索引优化、吞吐量
缓存：缓存占用大小、缓存读写吞吐量、响应时间、超时时间
消息队列：消息队列吞吐量、响应时间、超时情况等