性能优化1-概述

一.性能优化概述

根据不同应用，业务场景及指标的情况下，制定要达到的性能指标。

找到性能问题，然后分析瓶颈，解决性能问题。

通常的瓶颈有：应用层代码，算法，本身应用架构，数据库层,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挂了，如何恢复库存的情况，其实可以从用户对应购买车中购买了哪些产品，来进行库存的恢复。但缺点是用户数比较大时，恢复比较慢。