高并发解决方案

忘是亡心i 2021-12-15 01:53 654阅读 0赞

一、什么是高并发

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

二、什么是秒杀

秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品，电商网站一般会在约定时间点对其进行限量销售，因为这些商品的特殊性，会吸引大量用户前来抢购，并且会在约定的时间点同时在秒杀页面进行抢购。

此种场景就是非常有特点的高并发场景，如果不对流量进行合理管控，肆意放任大流量冲击系统，那么将导致一系列的问题出现，比如一些可用的连接资源被耗尽、分布式缓存的容量被撑爆、数据库吞吐量降低，最终必然会导致系统产生雪崩效应。

一般来说，大型互联网站通常采用的做法是通过扩容、动静分离、缓存、服务降级及限流五种常规手段来保护系统的稳定运行。

三、扩容

由于单台服务器的处理能力有限，因此当一台服务器的处理能力接近或已超出其容量上限时，采用集群技术对服务器进行扩容，可以很好地提升系统整体的并行处理能力，在集群环境中，节点的数量越多，系统的并行能力和容错性就越强。

在无状态服务下，扩容可能是迄今为止效果最明显的增加并发量的技巧之一。

从扩容方式角度讲，分为垂直扩容（scale up）和水平扩容（scale out）。垂直扩容就是增加单机处理能力，怼硬件，但硬件能力毕竟还是有限；水平扩容说白了就是增加机器数量，怼机器，但随着机器数量的增加，单应用并发能力并不一定与其呈现线性关系， 此时就可能需要进行应用服务化拆分了。

从数据角度讲，扩容可以分为无状态扩容和有状态扩容。无状态扩容一般就是指我们的应用服务器扩容；有状态扩容一般是指数据存储扩容，要么将一份数据拆分成不同的多份，即sharding，要么就整体复制n份，即副本。sharding遇到的问题就是分片的可靠性，一般做转移、rehash、分片副本；副本遇到的问题是一致性性，一般做一致性算法，如paxos，raft等。

四、动静分离

动静分离，静态资源请求与动态请求分离，项目中需要访问的图片、声音、js/css等静态资源需要有独立的存放位置，便于将来实现静态请求分离时直接剥离出来，比如nginx可以直接配置图片文件直接访问目录，而不需要经过tomcat。这样tomcat就可以专注处理动态请求，操作数据库数据处理之类的。静态请求代理服务器性能比tomcat高很多。

动静分离是指，静态页面与动态页面分开不同系统访问的架构设计方法。

![2019070412001248.png][]

一般来说：

*  静态页面访问路径短，访问速度快，几毫秒
 *  动态页面访问路径长，访问速度相对较慢(数据库的访问，网络传输，业务逻辑计算)，几十毫秒甚至几百毫秒，对架构扩展性的要求更高
 *  静态页面与动态页面以不同域名区分

系统需要将动态数据 和静态数据分而治之，用户对静态数据的访问，应该避免请求直接落到企业的数据中心，而是应该在CDN中获取，以加速系统的响应速度。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NjY1MTk_size_16_color_FFFFFF_t_70][]

五、缓存

缓存之所以能够提高处理速度，是因为不同设备的访问速度存在差异。缓存的话题可以扯几本书不带重样的。从CPU可以一直扯到客户端缓存，即从最底层一直到扯到最特近用户的一层，每一层都可能或可以有缓存的存在。我们这里不扯这么多，只说简单服务端缓存。现在从几个不同角度来看一下缓存：

①从效果角度。命中率越高越好吗？10万个店铺数据，缓存了1000个，命中率稳定100%，那是不是说，有99000个店铺都是长尾店铺？缓存效果评估不能单看命中率。

②从回收策略。如果把缓存当做数据库一样的存储设备去用，那就没有回收的说法了（除非重启或者宕机，否则数据依然有效）；如果只存储热数据，那就有回收和替换的问题。回收有两种方式，一种是空间配额，另一种是时间配额。替换也有几种方式，LRU，FIFO，LFU。

③从缓存使用模式角度：用户直接操作缓存和db；用户直接操作缓存，缓存帮助我们读写DbB；

④从缓存分级角度。java堆内缓存、java堆外缓存、磁盘缓存、分布式缓存，多级缓存。

⑤从缓存使用角度。null穿透问题、惊群问题、缓存热点问题、缓存一致性问题、读写扩散问题。。。。。。

⑥更新方式。读更新、写更新、异步更新。

如果缓存集群涉及到异地多集群部署，再结合大数据量高并发业务场景，还会遇到很多更加复杂的问题，这里就不一一列举了。

六、服务降级

业务高峰期，为了保证核心服务，需要停掉一些不太重要的业务，eg 商品评论、论坛或者粉丝积分等

另外一些场景就是某些服务不可用时，又不能直接让整个流程失败就本地Mcok(模拟)实现，做流程放通

eg 用户登录余额鉴权服务不能正常工作，需要做业务放通，记录消费话单允许用户继续访问，而不是返回失败

为了保证以上两种场景的正常服务，服务需要有降级。

服务降级主要包括容错降级和屏蔽降级

屏蔽降级：

1）throw null 不发起远程调用，直接返回空

2）throw exception 不发起远程调用，直接抛出指定异常

3）execute bean 不发起远程调用，直接执行本地模拟接口实现

服务降级是可逆操作，当系统压力恢复到一定值不需要降级服务时，要重新发起远程调用，服务状态改为正常

容错降级:

非核心服务不可调用时，可以对故障服务做业务放通，保证主流程不受影响

1）RPC异常：通常指超时、消息解码异常、流控异常、系统拥塞保护异常等

2）Service异常 eg登录校验异常、数据库操作失败异常等

七、限流

通过对并发访问和请求进行限速或者一个时间窗口内的请求进行限速来保护系统的可用性，一旦达到限制速率就可以拒绝服务（友好定向到错误页或告知资源没有了），排队或者等待（比如秒杀，评论，下单），降级（返回默认数据）。

通过压测的手段找到每个系统的处理峰值，然后通过设定峰值阈值，来防止当系统过载时，通过拒绝处理过载的请求来保障系统 可用性，同时也应该根据系统的吞吐量，响应时间，可用率来动态调整限流阈值。

分类：

*  限制总并发数---数据库连接池，线程池
 *  限制瞬时并发数---nginx的limit\_conn模块，用来限制瞬时并发连接数
 *  限制时间窗口内的平均速率---guava的RateLimiter，nginx的limit\_req模块，限制每秒平均速率
 *  其他---限制远程接口调用速率，限制MQ消费速率，另外，还可以根据网络连接数，网络流量，CPU或内存负载等来限流。

算法：

*  滑动窗口协议---改善吞吐量的技术
 *  漏桶---强制限制数据的传输速率，限制的流出速率
 *  令牌桶---（控制（流入）速率类型的限流算法）系统以恒定的速度往桶中放入令牌，如果请求需要被处理，则需要先从桶中获取一个令牌，当桶中没有令牌可取，则拒绝服务。当平时处理速率小于桶中令牌的速率，那么在突发流量时桶内有堆积可以有效预防。

令牌桶

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NjY1MTk_size_16_color_FFFFFF_t_70 1][]

漏桶

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NjY1MTk_size_16_color_FFFFFF_t_70 2][]

八、总结

任何一个分布式系统的容量都会存在上限，哪怕天猫这种级别的网站也不例外。一旦用户流量过载，系统的吞吐量便会开始下降，RT线上升，最终导致系统容量被撑爆而出现雪崩效应。因此，架构师在对系统架构进行设计时，一定要考虑到系统整个链路的各个环节。上述介绍的五种手段，看似平淡无奇，但是组合在一起却能爆发出惊人的力量。根据自己所处的场景，尝试各个方式进行解决，找到最适合的。

转载：[https://blog.51cto.com/13587708/2102818][https_blog.51cto.com_13587708_2102818]

[2019070412001248.png]: /images/20211214/370222e6c7c34405b18784053be3d18e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NjY1MTk_size_16_color_FFFFFF_t_70]: /images/20211214/24ca69c28dac4d50a290b447caba085d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NjY1MTk_size_16_color_FFFFFF_t_70 1]: /images/20211214/8473cfa73fd4453180ce5eba445654fc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA3NjY1MTk_size_16_color_FFFFFF_t_70 2]: /images/20211214/0512c7aaefa0475990b2b731e22a4f95.png
[https_blog.51cto.com_13587708_2102818]: https://blog.51cto.com/13587708/2102818