针对高并发系统的解决思路与方案

柔情只为你懂 2022-05-15 03:16 334阅读 0赞

总体上：

![70][]

开涛大神在博客中说过：**在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流**。

### 1.扩容 ###

![70 1][]

根据业务系统的类型，考虑不同的针对在数据库方面的扩容：

![70 2][]

### 2.缓存（特别重要） ###

缓存设置的地方

![70 3][]

手段

主要是Redis、CDN、浏览器等，其次可能一些问题

2.3可能存在的问题

![70 4][]

2.3.1一致性

缓存一致性的话，主要可能考虑到以下几种可能导致一致性问题：

![70 5][]

2.3.2缓存并发

由于并发时大量请求瞬间涌入，那么在建立或修改缓存时（还没完成），就可能已经打到DB或老缓存上了，造成雪崩或缓存一致性问题

![70 6][]

解决方案：

锁机制

**2.3.3缓存穿透**

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，如果从存储层查不到数据则不写入缓存，这将导致这个**不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能****DB****就挂掉了**，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决方案：

最常见的则是采用**布隆过滤器，将所有可能存在的数据哈希到一个足够大的****bitmap****中，一个一定不存在的数据会被****这个****bitmap****拦截掉，从而避免了对底层存储系统的查询压力。**另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

**2.3.4雪崩**

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致**缓存在某一时刻同时失效，请求全部转发到****DB****，****DB****瞬时压力过重雪崩**。

解决方案

大多数系统设计者**考虑用加锁或者队列的方式保证缓存的单线****程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上**。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们**可以在原有的失效时间基础上增加一个随机值，比如****1-5****分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。**

### **3.消息队列** ###

**做到了大量请求异步与解耦**，比如下单与短信验证码请求 的处理，及早返回处理。

比如远程调用较慢，可以用消息队列攒一堆去完成调用。

基于消息的模型，等通知即可，而不是处理（那是RPC），以及索引库更新，只是一个通知，而不是强完成（重量级），只是通知而不是职责所在（比如上游系统对下的通知）。

仅仅最终一致性。

**需求场景**

![70 7][]

及一些非核心业务或者多个对象、数据量小时，而

相比RPC框架（dubbo等），RPC场景是需要 强一致性、对延迟敏感、注重结果立马返回、重量级

### **4.应用拆分** ###

SOA 微服务等

个人看法，原则是：

1.业务是否适合拆分，拆分后耦合度不能高

2.是否需要拆分，拆分是为了高并发高可用，是否解决了高并发热点问题？

### **5.应用限流** ###

比如股票系统中，收盘后，你有几百万数据需要入库了，如果不做限流，瞬间将会把带宽全部打满，其它服务暂时GG或者主从延迟很大等等问题。

**限流的算法**

常见的限流算法有：计数器、漏桶和令牌桶算法。

**计数器**

计数器是最简单粗暴的算法。比如某个服务最多只能每秒钟处理100个请求。我们可以设置一个1秒钟的滑动窗口，窗口中有10个格子，每个格子100毫秒，每100毫秒移动一次，每次移动都需要记录当前服务请求的次数。内存中需要保存10次的次数。可以用数据结构LinkedList来实现。格子每次移动的时候判断一次，当前访问次数和LinkedList中最后一个相差是否超过100，如果超过就需要限流了。

![70 8][]

很明显，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

![70 9][]

**漏桶算法**

漏桶算法即leaky bucket是一种非常常用的限流算法，可以用来实现流量整形（Traffic Shaping）和流量控制（Traffic Policing）。贴了一张维基百科上示意图帮助大家理解：

![70 10][]

漏桶算法的主要概念如下：

*  一个固定容量的漏桶，按照常量固定速率流出水滴；
 *  如果桶是空的，则不需流出水滴；
 *  可以以任意速率流入水滴到漏桶；
 *  如果流入水滴超出了桶的容量，则流入的水滴溢出了（被丢弃），而漏桶容量是不变的。

漏桶算法比较好实现，在单机系统中可以使用队列来实现（.Net中TPL DataFlow可以较好的处理类似的问题，你可以在[这里][Link 1]找到相关的介绍），在分布式环境中消息中间件或者Redis都是可选的方案。

令牌桶算法

令牌桶算法是一个存放固定容量令牌（token）的桶，按照固定速率往桶里添加令牌。令牌桶算法基本可以用下面的几个概念来描述：

*  令牌将按照固定的速率被放入令牌桶中。比如每秒放10个。
 *  桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝。
 *  当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上。
 *  如果桶中的令牌不足n个，则不会删除令牌，且该数据包将被限流（要么丢弃，要么缓冲区等待）。

如下图：

![70 11][]

令牌算法是根据放令牌的速率去控制输出的速率，也就是上图的to network的速率。to network我们可以理解为消息的处理程序，执行某段业务或者调用某个RPC。

**应用级限流**

**限流总并发/连接/请求数**

对于一个应用系统来说一定会有极限并发/请求数，即总有一个TPS/QPS阀值，如果超了阀值则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过载保护，防止大量请求涌入击垮系统。

如果使用过Tomcat，其Connector其中一种配置有如下几个参数：

acceptCount：如果Tomcat的线程都忙于响应，新来的连接会进入队列排队，如果超出排队大小，则拒绝连接；

maxConnections：瞬时最大连接数，超出的会排队等待；

maxThreads：Tomcat能启动用来处理请求的最大线程数，如果请求处理量一直远远大于最大线程数则可能会僵死。

详细的配置请参考官方文档。另外如[**MySQL**（如max\_connections）、][MySQL_max_connections][**Redis**（如tcp-backlog）都会有类似的限制连接数的配置。][Redis_tcp-backlog]

[ ][Redis_tcp-backlog]

**[限流总资源数][Redis_tcp-backlog]**

[如果有的资源是稀缺资源（如数据库连接、线程），而且可能有多个系统都会去使用它，那么需要限制应用；可以使用池化技术来限制总资源数：连接池、线程池。比如分配给每个应用的数据库连接是100，那么本应用最多可以使用100个资源，超出了可以等待或者抛异常。][Redis_tcp-backlog]

[ ][Redis_tcp-backlog]

**[限流某个接口的总并发/请求数][Redis_tcp-backlog]**

[如果接口可能会有突发访问情况，但又担心访问量太大造成崩溃，如抢购业务；这个时候就需要限制这个接口的总并发/请求数总请求数了；因为粒度比较细，可以为每个接口都设置相应的阀值。可以使用][Redis_tcp-backlog][**Java**中的AtomicLong进行限流：][Java_AtomicLong]

[=================================][Java_AtomicLong]

[**try**\{   
**if**(atomic.incrementAndGet() > 限流数) \{   
*//**拒绝请求*  
\}  
*//**处理请求*  
\} **finally**\{   
atomic.decrementAndGet();  
\}][Java_AtomicLong]

[=================================][Java_AtomicLong]

[适合对业务无损的服务或者需要过载保护的服务进行限流，如抢购业务，超出了大小要么让用户排队，要么告诉用户没货了，对用户来说是可以接受的。而一些开放平台也会限制用户调用某个接口的试用请求量，也可以用这种计数器方式实现。这种方式也是简单粗暴的限流，没有平滑处理，需要根据实际情况选择使用；][Java_AtomicLong]

[ ][Java_AtomicLong]

**[限流某个接口的时间窗请求数][Java_AtomicLong]**

[即一个时间窗口内的请求数，如想限制某个接口/服务每秒/每分钟/每天的请求数/调用量。如一些基础服务会被很多其他系统调用，比如商品详情页服务会调用基础商品服务调用，但是怕因为更新量比较大将基础服务打挂，这时我们要对每秒/每分钟的调用量进行限速；一种实现方式如下所示：][Java_AtomicLong]

[=================================][Java_AtomicLong]

[LoadingCache<Long, AtomicLong> counter =  
 CacheBuilder.*newBuilder*()  
 .expireAfterWrite(2, TimeUnit.***SECONDS***)  
 .build(**new**CacheLoader<Long, AtomicLong>() \{   
@Override  
**public**AtomicLong load(Long seconds) **throws**Exception \{   
**return new**AtomicLong(0);  
 \}  
 \});  
**long**limit = 1000;  
**while**(**true**) \{   
*//**得到当前秒*  
**long**currentSeconds = System.*currentTimeMillis*() / 1000;  
**if**(counter.get(currentSeconds).incrementAndGet() > limit) \{   
 System.***out***.println(**"****限流了:"**\+ currentSeconds);  
**continue**;  
 \}  
*//**业务处理*  
\}][Java_AtomicLong]

[=================================][Java_AtomicLong]

[我们使用Guava的Cache来存储计数器，过期时间设置为2秒（保证1秒内的计数器是有的），然后我们获取当前时间戳然后取秒数来作为KEY进行计数统计和限流，这种方式也是简单粗暴，刚才说的场景够用了。][Java_AtomicLong]

[ ][Java_AtomicLong]

**[平滑限流某个接口的请求数][Java_AtomicLong]**

[之前的限流方式都不能很好地应对突发请求，即瞬间请求可能都被允许从而导致一些问题；因此在一些场景中需要对突发请求进行整形，整形为平均速率请求处理（比如5r/s，则每隔200毫秒处理一个请求，平滑了速率）。这个时候有两种算法满足我们的场景：令牌桶和漏桶算法。Guava框架提供了令牌桶算法实现，可直接拿来使用。][Java_AtomicLong]

[Guava RateLimiter提供了令牌桶算法实现：平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。][Java_AtomicLong]

**分布式限流**

分布式限流最关键的是要将限流服务做成原子化，而解决方案可以使使用redis+lua或者nginx+lua技术进行实现，通过这两种技术可以实现的高并发和高性能。

使用redis+lua实现时间窗内某个接口的请求数限流，实现了该功能后可以改造为限流总并发/请求数和限制总资源数。Lua本身就是一种编程语言，也可以使用它实现复杂的令牌桶或漏桶算法。

### **6.服务降级与熔断** ###

**1.服务降级**

**当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行**。

降级后的处理可以设置一些默认的页面或返回，如：

*  服务接口拒绝服务：页面能访问，但是添加删除提示服务器繁忙。页面内容也可在Varnish或CDN内获取。
 *  页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
 *  延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
 *  随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。

**2.服务熔断**

服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。

**3.对比区别和共性**

![70 12][]

类似性的：

1.  **目的很一致**，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
2.  **最终表现类似**，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
3.  **粒度一般都是服务级别**，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
4.  **自治性要求很高**，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；

而两者的区别也是明显的：

1.  **触发原因不太一样**，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
2.  **管理目标的层次不太一样**，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
3.  **实现方式不太一样**

### 7.数据库分库、分表 ###

出现以下情况时开始考虑

![70 13][]

以下为数据库优化，参考之前写的MySQL优化部分。

### 8.高可用-方案 ###

![70 14][]

[70]: /images/20220515/99fcdae574c543a6b222fb0eb3e59d5f.png
[70 1]: /images/20220515/cc0548539e884a95b30c29067be006e6.png
[70 2]: /images/20220515/d3dc651113b34aed86c9f4a27a68db19.png
[70 3]: /images/20220515/8787c171701748a28663271f1fe552d8.png
[70 4]: /images/20220515/0ac7fa8b87bc44a297c0e5f24e405373.png
[70 5]: /images/20220515/d3f71c26e6a340009d3d8ef522d081e6.png
[70 6]: /images/20220515/109c7cefd3dd4d54aba313ecf41c4655.png
[70 7]: /images/20220515/b40cba9bbbc249bd9f18e3c573dbdf0d.png
[70 8]: /images/20220515/f394112691b349e782a9b3a4bc07a1c7.png
[70 9]: /images/20220515/9f00096a3d4d42a68cdeb6111ee297f9.png
[70 10]: /images/20220515/900b568a9e644103a05bd611f3b15398.png
[Link 1]: http://www.cnblogs.com/haoxinyue/archive/2013/03/01/2938959.html
[70 11]: /images/20220515/f0d053a565274ef6831ab07d71b89910.png
[MySQL_max_connections]: http://lib.csdn.net/base/mysql
[Redis_tcp-backlog]: http://lib.csdn.net/base/redis
[Java_AtomicLong]: http://lib.csdn.net/base/javaee
[70 12]: /images/20220515/d18aeac9a6c54574942af4a3e914a749.png
[70 13]: /images/20220515/e8027efef61a4c72a00c736f8c72c9c9.png
[70 14]: /images/20220515/8aff593333f14910ac3b3e03ea47812d.png