一.性能优化概述
根据不同应用，业务场景及指标的情况下，制定要达到的性能指标。
找到性能问题，然后分析瓶颈，解决性能问题。
通常的瓶颈有：应用层代码，算法，本身应用架构，数据库层,jvm等。
常见的指标有：
吞吐量，tps,qps，响应延时。
tps，吞吐量及qps与业务指标有关。
响应延时，更加侧重客户体现上，这会影响转化率。
响应延时又分为最长延时，平均延时及最短延时。
一般最长延时及平均延时会比较关注。
之前做的一个电商项目，首页延时响应时间最长是20ms。
一天按1000万订单来算，一天24小时，则平均每秒下单tps必须在115以上。
购买还需要考虑购买时间点，不可能流量都比较平均，这部分数据就需要实际的数据分析了。
这里假设早上9点到晚上9点是高峰期，则按12小时算，则tps必须在230以上。
因为还有峰值访问，所以一般可以设置这个平均tps乘以一个系数，这里是3，则要求tps在690以上。
二.性能优化怎么做
首先是性能测试，分析瓶颈。
jmeter等可以用来压测。
如果发现下单tps不符合业务指标，就要分析性能瓶颈在哪一块了。
一般下单包含以下几个核心操作（实际还有优惠券等）：
1.创建订单
2.扣产品库存
3.扣用户钱
4.更新订单状态为成功
可以看出有许多涉及很多服务。
这时如果有调用链监控，则对于性能定位就比较方便。
如果扣产品库存服务比较慢，则需要分析这个服务具体的实现。库存本身是线程竞争的资源。而本身的瓶颈在于数据库。
对于这块常见的优化是：
1.将热点产品库存分散在多个服务器，比如产品a总库存为10000，分散在2台服务器，则每台库存为5000，这样压力可以少一半。
而对于库存扣减请求需要按load banlance形式去循环扣减。
2.底层扣减库存的优化，底层不要对产品加锁再在程序层做扣减。
直接在sql层写：update product set stock=stock-[请求库存] where stock>=[请求库存]
这个方式比上面的方法少一次数据库请求。
3.更为极端的优化是库存操作在redis内存
但缺点是如果redis挂了，则会导致超卖情况，这个与具体实现有关。
还有一种比较好的做法是：
购买车阶段库存扣减从redis做，最终实现下单的时候以数据库库存为主。这个不会导致超卖。
这种对于抢购类业务场景还是有优势的，因为最终进入到数据库层下单流程的只有实际库存数的用户流量。
比如，某产品之前库存是1000，其中100件已经加入购买车，数据库库存是1000。
redis挂了，这时从数据库恢复库存，内存库存就变为：1000，而这多出来的100再被其他用户加入购买车后，最终下单会告诉用户【产品已被抢光】，并不会发生超卖。
这时实现上涉及一个在redis挂了，如何恢复库存的情况，其实可以从用户对应购买车中购买了哪些产品，来进行库存的恢复。但缺点是用户数比较大时，恢复比较慢。