高并发系统的三把利器

目录

1.限流

2.缓存

2.1.缓存的使用场景

3.降级

3.1.什么是降级？

3.2.服务降级方式

4.其他高并发手段 

4.1. 集群

4.2.拆分

4.2.1 应用拆分

4.2.2 数据库

4.3. 静态化

4.4.削峰

4.5.限流

5.总结

参考

---

保护高并发系统的三大利器：限流、熔断降级、缓存

• 限流：控制系统的请求量，防止系统被过度压力而崩溃。
• 缓存：将一些常用的数据存储在内存中，减轻数据库的压力，提高系统的响应速度。
• 降级：当系统不能承受更多的请求时，可以有意识地关闭一些不必要的功能或服务，以保证核心功能的正常运行。

1.限流

        限流是保护高并发系统的三把利器之一。限流在很多场景中用来限制并发和请求量。实现系统限流的方式有很多种，比如令牌桶算法、漏桶算法等。

采用限流策略来控制用户的请求速率

限流常用的几种算法

1）计数器限流

你要是仔细看了上面的内容，就会发现上面举例的每秒阈值1000的那个例子就是一个计数器限流的思想，计数器限流的本质是一定时间内，访问量到达设置的限制后，在这个时间段没有过去之前，超过阈值的访问量拒绝处理，举个例，你告诉老板我一个小时只处理10件事，这是你的处理能力，但领导半个小内就断续断续给你分派了10件事，这时已经到达你的极限了，在后面的半个小时内，领导再派出的活你是拒绝处理的，直到下一个小时的时间段开始。

2）漏斗限流

漏斗限流，意思是说在一个漏斗容器中，当请求来临时就从漏斗顶部放入，漏斗底部会以一定的频率流出，当放入的速度大于流出的速度时，漏斗的空间会逐渐减少为0，这时请求会被拒绝，其实就是上面开始时池塘流水的例子。流入速率是随机的，流出速率是固定的，当漏斗满了之后，其实到了一个平滑的阶段，因为流出是固定的，所以你流入也是固定的，相当于请求是匀速通过的

2.缓存

2.1.缓存的使用场景

• 经常需要读取的数据

• 频繁访问的数据

• 热点数据缓存

• IO 瓶颈数据

• 计算昂贵的数据

• 无需实时更新的数据

• 缓存的目的是减少对后端服务的访问，降低后端服务的压力

 1）CDN 缓存

• CDN 的全称是 Content Delivery Network，即内容分发网络。CDN 是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

• CDN 它本身也是一个缓存，它把后端应用的数据缓存起来，用户要访问的时候，直接从CDN 上获取，不需要走后端的 Nginx，以及具体应用服务器 Tomcat，它的作用主要是加速数据的传输，也提高稳定性，如果从 CDN 上没有获取到数据，再走后端的Nginx缓存，Nginx 上也没有，则走后端的应用服务器，CDN主要缓存静态资

2）应用缓存：

        内存缓存

                在内存中缓存数据，效率高，速度快，应用重启缓存丢失

        磁盘缓存

                在磁盘缓存数据，读取效率跟内存比较，磁盘缓存稍低，但应用重启缓存不会丢失3）

3）多级缓存

在整个应用系统的不同层级进行数据的缓存，多层次缓存，来提升访问效率；比如：浏览器 -> CDN -> Nginx -> Redis -> DB (磁盘、文件系统)

随着业务的不断增加，服务器性能很快又到达瓶颈

3.降级

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的

3.1.什么是降级？

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

3.2.服务降级方式

延迟服务：定时任务处理、或者mq延时处理。

页面降级：页面点击按钮全部置灰，或者页面调整成为一个静态页面显示"系统正在维护中......"。

关闭非核心服务：比如电商关闭推荐服务、关闭运费险、退货退款等。保证主流程的核心服务下单付款就好。

写降级：比如秒杀抢购，我们可以只进行Cache的更新返回，然后通过mq异步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。

读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存

4.其他高并发手段 

4.1. 集群

• 有一个单体应用，当访问流量很大无法支撑，那么可以集群部署，也叫单体应用「水平扩容」，原来通过部署一台服务器提供服务，现在就多部署几台，那么服务的能力就会提升。

• 部署了多台服务器，但是用户访问入口只能是一个，比如 www.evanshare.com，所以就需要 「负载均衡」，负载均衡是应用集群扩容后的必须步骤，集群部署后，用户的会话 session 状态 要保持的话，就需要实现 session 共享。

4.2.拆分

4.2.1 应用拆分

应用的拆分：分布式 （微服务）

单体应用，随着业务的发展，应用功能的增加，单体应用就逐步变得非常庞大，很多人 维护这么一个系统，开发、测试、上线都会造成很大问题，比如代码冲突，代码重复，逻辑错综混乱，代码逻辑复杂度增加，响应新需求的速度降低，隐藏的风险增大，所以需要按照 「业务维度进行应用拆分，采用分布式开发」；

应用拆分之后，就将原来在同一进程里的调用变成了远程方法调用，此时就需要使用到 一些「远程调用技」 httpClient、hessian、dubbo、webservice 等；

随着业务复杂度增加，我们需要采用一些开源方案进行开发，提升开发和维护效率，比 如 Dubbo、SpringCloud；

通过应用拆分之后，扩容就变得容易，如果此时系统处理能力跟不上，只需要「增加服务 器即可」（把拆分后的每一个服务再多做几个集群）

4.2.2 数据库

1）数据库拆分

数据库拆分分为：「垂直拆分和水平拆分 （分库分表）」

 「按照业务维度把相同类型的表放在一个数据库，另一些表放在另一个数据库」，这种方式 的拆分叫「垂直拆分」，也就是在 不同库建不同表，把表分散到各个数据库

比如产品、订单、用户三类数据以前在一个数据库中，现在可以用三个数据库，分别为 「产品数据库、订单数据库、用户数据库」，这样可以将不同的数据库部署在不同的服务器上，提升单机容量和性能问题，也解决多 个表之间的 IO 竞争问题

根据数据行的特点和规则，将表中的「某些行切分到一个数据库，而另外的某些行又切分 到另一个数据库」，这种方式的拆分叫「水平拆分」

单库单表在数据量和流量增大的过程中，大表往往会成为性能瓶颈，所以数据库要进行「水平拆分」

2）读写分离 + 主从复制

3）数据库优化

4.3. 静态化

对于一些访问量大，更新频率较低的数据，可直接定时生成静态 html 页面，供前端访问，而不是访问 jsp

常用静态化的技术：freemaker、velocity 定时任务，每隔 2 分钟生成一次首页的静态化页面

页面静态化首先可以大大提升访问速度，不需要去访问数据库或者缓存来获取数据，浏览器直接加载 html 页即可

页面静态化可以提升网站稳定性，如果程序或数据库出了问题，静态页面依然可以正常 访问

4.4.削峰

   削峰本质上是更多地延缓用户请求，层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则

1. 限流算法：通过限制单位时间内请求的数量或速率，来控制访问流量。常见的限流算法包括令牌桶算法和漏桶算法。

2. 缓存：将一部分数据缓存在内存中，减少对数据库的访问次数，从而降低服务器压力。

3. 负载均衡：将访问流量分散到多台服务器上，避免单一服务器过载，提高系统的可用性和稳定性。

4. 异步处理：将一些耗时的操作异步处理，如发送邮件、生成报表等，避免阻塞主线程，提高系统的并发能力。

5. CDN加速：通过将静态资源缓存在CDN节点上，加速用户对静态资源的访问，降低服务器压力

4.5.限流

        通过削峰策略来平衡供需，从而保证系统的正常运行

       像漏斗一样，尽量把数据量和请求量一层一层地过滤和减少，需要查询的用户，在缓存中能能查询到需要的信息，无需通过每次查询数据库，那么最后留下的，就是真正需要成交的客户，大大减轻DB的读写压力

1）分层过滤的核心思想

•  通过在不同的层次尽可能地过滤掉无效请求。
•  通过CDN过滤掉大量的图片，静态资源的请求。
•  再通过类似Redis这样的分布式缓存，过滤请求等就是典型的在上游拦截读请求。

2）分层过滤的基本原则

•  对写数据进行基于时间的合理分片，过滤掉过期的失效请求。
•  对写请求做限流保护，将超出系统承载能力的请求过滤掉。
•  涉及到的读数据不做强一致性校验，减少因为一致性校验产生瓶颈的问题。
•  对写数据进行强一致性校验，只保留最后有效的数据。

        最终，让“漏斗”最末端(数据库)的才是有效请求。例如：当用户真实达到订单和支付的流程，这个是需要数据强一致性的。

5.总结

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一。

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。

同时结合一些策略达到分流、限流的目的

1.对于秒杀这样的高并发场景业务，最基本的原则就是将请求拦截在系统上游，降低下游压力。如果不在前端拦截很可能造成数据库(mysql、oracle等)读写锁冲突，甚至导致死锁，最终还有可能出现雪崩等场景。

2.划分好动静资源，静态资源使用CDN进行服务分发。

3.充分利用缓存(redis等)：增加QPS，从而加大整个集群的吞吐量。

4.高峰值流量是压垮系统很重要的原因，所以需要RocketMQ消息队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。

以上，为个人工作之余一些浅薄看法，记录下来，与诸位共享，不足之处，多多指点，感激不尽

参考

[1]高并发场景，你要如何实现系统限流？

[2]分布式高并发服务三种常用限流方案简介

[3] 九师兄的博客 - 高并发之限流 RateLimiter使用