高并发接口遇到的挑战

高并发接口遇到的挑战

以5W每秒的高并发的秒杀为例，整个系统应对时会遇到很多的问题和挑战，如果没有针对性的对待，可能会导致业务挂掉，甚至殃及其他业务。我们简单的看一下从几个方面进行优化。

业务接口需要支持高并发

对于秒杀这个业务而言，正确的处理业务外，响应时间是最重要的。一般秒杀会有针对库存的校验，除了针对库存这样的竞争资源加锁外，还需要将读取库存的操作从DB转移到内存中，使用redis做这样的事情的不错的选择，需要注意的是对库存的修改最终都应该到改底层方法，以避免多处使用造成库存不统一。如果有写入类似寄送地址的数据时，尽量保证与秒杀分离，不要设计在一个接口中，从功能层面就应该将寄送地址这样的功能与秒杀分离设计。如果有必须同步在秒杀接口中的，应该尽可能的异步写入，先保证存储到内存中，再保证从内存到持久化的不丢失。

涉及到的性能指标

一般使用吞吐量来检查指标，也就是经常说的QPS。这个值等于服务器接收到的请求数除以平均响应时间。在高并发的场景下，机器的其他指标可能处于高负载的情况，这个时候平均响应时间会被加大。 比如在线程非常多的情况下，CPU进行线程的上下文切换增加了CPU的消耗。网络带宽也是一个很大的影响因素，但一般秒杀业务中，提交的请求仅仅是几个字符串，带宽瓶颈的可能性比较低。

小心堵车

我们假设在增加了集群后，理论上我们可以提供10W/S的QPS,在高并发的情况下，平均时间变长，从理论10W的QPS降为实际8W的QPS，这样在高峰时，某一秒有2万的请求被阻挡了，这种被阻挡的请求堆积的越多，高并发峰值持续的时间越长，系统的可用性越差，最终很可能导致宕机。

这种情况的发生可能是我们太依赖理论的值了，面临这样的高并发峰值，我们必须时刻关注负载情况或有好用的监控预警。 系统需要针对这种情况进行自动扩容。

不要贸然重启

遇到堵车时，不能够贸然的重启机器来缓解问题，重启机器可能需要一定的时间，已经接受的请求可能会被转移到其他的节点。 这种情况应该设计满负载监测和过载保护，当认为节点已经处于满负载时，拒绝之后的请求，等待当前请求处理到负载下降时，自动恢复。

做好有效请求控制

秒杀按钮尽量控制用户只能点击一次，并且从nginx层面控制同一个用户的多个请求。尽量将请求拦截在上游，越靠近上游的筛选有效请求，收益越大。

当某些产品已经没有库存时，在前面的产品详情页面就将去秒杀入口屏蔽，以减少秒杀接口的负载。库存值尽量在活动开始前就已预估和设置好，尽量不要在活动期间调整库存值，以减少库存不够阻挡用户后，过一段时间又可以进行秒杀的情况。

支撑服务也需要进行高并发设计

尽量不要调用没有进行高并发设计的服务，开发过程中依赖到的非秒杀的其他的库表、服务器等要做好充分的隔离或高并发设计。特别是一些共用的服务、写系统日志、通用的拦截器等等，没有经过高并发设计，很容易造成性能瓶颈，也很容易导致支撑服务挂掉。

做好压力测试和峰值评估

上线前请务必在集群环境下做好压力测试以及做好峰值评估，在可预见的范围内做多倍峰值设计，如果无法保证多倍设计，要设计实施扩容或自动扩容机制。

                                            长按下方二维码，即可了解新贝学院更多内容