架构设计 | 高并发流量削峰，共享资源加锁机制 _架构设计

一、高并发简介在互联网的业务架构中，高并发是最难处理的业务之一，常见的使用场景：秒杀，抢购，订票系统；高并发的流程中需要处理的复杂问题非常多，主要涉及下面几个方面：

流量管理，逐级承接削峰；
网关控制，路由请求，接口熔断；
并发控制机制，资源加锁；
分布式架构，隔离服务和数据库；

高并发业务核心还是流量控制，控制流量下沉速度，或者控制承接流量的容器大小，多余的直接溢出，这是相对复杂的流程。其次就是多线程并发下访问共享资源，该流程需要加锁机制，避免数据写出现错乱情况。
二、秒杀场景1、预抢购业务活动未正式开始，先进行活动预约，先把一部分流量收集和控制起来，在真正秒杀的时间点，很多数据可能都已经预处理好了，可以很大程度上削减系统的压力。有了一定预约流量还可以提前对库存系统做好准备，一举两得。
场景：活动预约，定金预约，高铁抢票预购。
2、分批抢购分批抢购和抢购的场景实现的机制是一致的，只是在流量上缓解了很多压力，秒杀10W件库存和秒杀100件库存系统的抗压不是一个级别。如果秒杀10W件库存，系统至少承担多于10W几倍的流量冲击，秒杀100件库存，体系可能承担几百或者上千的流量就结束了。下面流量削峰会详解这里的策略机制。
场景：分时段多场次抢购，高铁票分批放出。
3、实时秒杀最有难度的场景就是准点实时的秒杀活动，假如10点整准时抢1W件商品，在这个时间点前后会涌入高并发的流量，刷新页面，或者请求抢购的接口，这样的场景处理起来是最复杂的。

首先系统要承接住流量的涌入；
页面的不断刷新要实时加载；
高并发请求的流量控制加锁等；
服务隔离和数据库设计的系统保护；

场景：618准点抢购，双11准点秒杀，电商促销秒杀。
三、流量削峰

文章插图

1、Nginx代理Nginx是一个高性能的HTTP和反向代理web服务器，经常用在集群服务中做统一代理层和负载均衡策略，也可以作为一层流量控制层，提供两种限流方式，一是控制速率，二是控制并发连接数。
基于漏桶算法，提供限制请求处理速率能力；限制IP的访问频率，流量突然增大时，超出的请求将被拒绝；还可以限制并发连接数。
高并发的秒杀场景下，经过Nginx层的各种限制策略，可以控制流量在一个相对稳定的状态。
2、CDN节点CDN静态文件的代理节点，秒杀场景的服务有这样一个操作特点，活动倒计时开始之前，大量的用户会不断的刷新页面，这时候静态页面可以交给CDN层面代理，分担数据服务接口的压力。
CDN层面也可以做一层限流，在页面内置一层策略，假设有10W用户点击抢购，可以只放行1W的流量，其他的直接提示活动结束即可，这也是常用的手段之一。
话外之意：平时参与的抢购活动，可能你的请求根本没有到达数据接口层面，就极速响应商品已抢完，自行意会吧。
3、网关控制网关层面处理服务接口路由，一些校验之外，最主要的是可以集成一些策略进入网关，比如经过上述层层的流量控制之后，请求已经接近核心的数据接口，这时在网关层面内置一些策略控制：如果活动是想激活老用户，网关层面快速判断用户属性，老用户会放行请求；如果活动的目的是拉新，则放行更多的新用户。
经过这些层面的控制，剩下的流量已经不多了，后续才真正开始执行抢购的数据操作。
话外之意：如果有10W人参加抢购活动，真正下沉到底层的抢购流量可能就1W，甚至更少，在分散到集群服务中处理。
4、并发熔断在分布式服务的接口中，还有最精细的一层控制，对于一个接口在单位之间内控制请求处理的数量，这个基于接口的响应时间综合考虑，响应越快，单位时间内的并发量就越高，这里逻辑不难理解。
言外之意：流量经过层层控制，数据接口层面分担的压力已经不大，这时候就是面对秒杀业务中的加锁问题了。
四、分布式加锁1、悲观锁机制描述
所有请求的线程必须在获取锁之后，才能执行数据库操作，并且基于序列化的模式，没有获取锁的线程处于等待状态，并且设定重试机制，在单位时间后再次尝试获取锁，或者直接返回。
过程图解