昨天一大神又做了一次精彩的分享，关于服务容量预估和常用的优化策略。鄙人将分享内容case及个人理解写出来，一在自我回顾总结，二在分享给大家，一起讨论。
Case
用户运营提出某活动价促销需求(优惠力度很大)，且活动商品无限量供应。计划给1000w用户发送促销短信。
问：你是负责该活动的RD，这次活动需要加机器吗？
回答这个问题需应基于历史活动的访问量、机器性能指标表现而定；且是否加机器首先还得清楚机器硬件配置数据、从web到db各节点层的最大、最优访问数值。
笔者考虑思路是，活动、促销必与并发量、接口qps相关；且前期研究系统服务限流时思考过这样两个问题
1、如何预估接口qps？
2、以及如何统计线上接口qps？
后一个问题当然简单，最终采用awk命令方可得到数据。但第一个问题最直接的QPS测量方式除了模拟线上环境进行接口压测之外，开发人员应有一个哪种合理的思路去进行预估，笔者一直没有想出一个比较好的方案。但肯定需要有这么一套完备的思路（体现互联网老兵久经沙场的牛逼之处）。
看看大神思路
服务容量的核心指标
1、吞吐量(Throughput)：每秒钟可以处理的请求数、任务数
2、系统延迟(Latency)：系统处理一个请求、任务的延迟（请求处理时间+数据传输时间）
服务容量预估
一、服务本身访问量、QPS预估
1、估算活动总访问量，通过PV、UV、交易量数据评估
1000w营销短信活动当天发送完
UV：1000w * 10% = 100w(估算10%的用户收到短信回打开链接)
PV：100w * 3 = 300w（估算其中每个用户可能会来回打开3次）
注：估算数据也需要根据历史实际活动数据统计得来，是个概率值。
UV：Unique Vistor，1天内同一访客的多次访问只计为1个访客，以cookie为依据
PV：page view 用户每打开一个页面便记录1次PV，多次打开同一页面则浏览量累计
IP：独立IP数，同一IP无论访问了几个页面，独立IP数均为1
2、估算活动平均QPS
短信发送时间一般为：8:00 – 20:00
13h * 60 * 60 = 46800 ~= 4w 秒
300w 链接请求/ 4w 秒 = 75 次访问每秒
3、活动峰值QPS
这个就需要根据系统历史访问情况，统计线上最高的qps量是多少，进行大致预估。除awk命令外，笔者提供一个比较笨的方法，如下：
cat trade.log|grep 'createTrade result:' | cut -d' ' -f2 | cut -d':' -f3 | uniq -c
取增量 | 一个请求取一行 | 把时间截取出来 | 把秒数截取出来 | 去重取计数
4、估算单机极限QPS *
基于网站流量分布：峰值流量 / 平均流量 = 70k / 50k = 1.4
峰值QPS = 75 * 1.4 = 105（活动的平均QPS *最高倍数 约等于最高qps）
5、确定节点数量
通过以上针对该活动期间的系统访问量、系统平均QPS以及最高QPS的预估，对活动的峰值本身有了一个大致的范围。接下来就需要对系统中的固有瓶颈，如WebServer 最高QPS、MySql读写请求最大值等，结合这些参数进行评估。
二、各网络节点性能指标
常用性能指标
1、操作时延：
Heap：1us
Off-Heap: 10us
Memory Mapped File: 100us
文件顺序读写：接近ms
Socket: >1ms
2、MySQL读写 ：2 000RW/秒，ms级
3、Redis ：40 000RW/秒，ms级
4、Tomcat：3 200req/秒，13ms延迟，40线程
5、代码执行开销：逻辑分支、对象创建、
6、框架、软件执行开销：Spring、MyBatis、Tomcat
7、外部依应用行开销：JDBC、Rpc、Http、Redis
8、内部应用执行开销：锁、条件
9、其他硬件开销：IO、带宽、CPU
三、Case：结合以上数据分析某接口最大QPS值
actionA通过了两次mysql查询，3次写入操作，最后将请求返回页面。us忽略不计，3次db IO姑且评估action A执行时间为3ms
Tomcat：1ms时延下,tomcat吞吐量为20k，20k/3 = 6.6k
MySQL：2000/3 = 666
最终actionA的吞吐量为：666 （短板理论，系统性能取决于最小吞吐节点）
最终确定节点数量：
通过计算，活动请求峰值QPS为105，单机能承担的极限QPS为666，666 > 105, 理论节点数量为1即可。实际部署了2个服务节点。不需要加机器。
四、总结
这就是容量预估的整理分析流程。想必618 双11之前无数工程师或通过工具、或凭借历年团队项目经验，不断重复的评估多少台机器能抗住。
另外除技术本身，我从这位同事身上看到了一点：经验这东西是装不出来的，也是我或缺的。需要在日常工作中多思考，多提问，多设想，多找解决方案。看别人很多参数、指标，不同延时下tomcat的最大吞吐量、不同业务逻辑每个接口大致执行时间这些确切的数据随便信手拈来，很是屌屌的。