某天，老板带着运营总监拎着刚在菜市场买的刀"轻声细语"地问：6.18到了，我们需要在30分钟内push大概5000万用户优惠券,预计点击率10%，我们现有的机器还能扛得住吗？
对于我来说，这是一道接近于送命的题，赶紧组织头脑风暴，不然......。
第一步：
5000万用户的推送，10%的点击率，也就是5000X10% = 500w
第二步：
评估平均的访问量也就是我们说的QPS：总量/总时间即可。一天大概是24X60X60=86400秒。但是我们的请求都是在白天发生的，即4w秒。
第三步：
上面算出来 push实际的落地是30分钟有500w的访问量，那平均QPS就是 500w/(30* 60) = 2778，我们进一位也就是3000Qps。
在此，我们大概计算出了每秒钟平均我们的业务需要抗住3000Qps。
其实这还是不够的，我们继续分析下来：
举个栗子：我们的APP首页日均访问量pv为8000w(稍微吹点牛，不上税)，求平均访问QPS？一天按4w秒算，8000w/4w = 2000QPS
继续：我们评估高峰QPS？需要根据业务曲线评估
从图中可以看出，峰值QPS大概是均值QPS的2.5倍，于是估算出峰值QPS是5000。
再者我们评估下我们的单机服务器的极限QPS？
压力测试
通过测试发现，瓶颈出现在web层，tomcat的单机只能抗住1200的QPS。1%的流量到DB，大概就是500的QPS这对于mysql来说不是瓶颈，cache层是否能抗住，需要设置下云服务器的带宽。
现在我们大概能计算出来了？单机能扛住1200的QPS，取整1000QPS，峰值是5000QPS，大概需要5台机器，前置通过负载均衡分流过来。
总结一下：
1.评估总的访问量
2.评估平均访问量
3.评估高峰QPS
4.评估系统，单机的峰值QPS