高并发-高可用-高性能

文章目录

• 参考
• 分布式事务
• 高可用
• 高并发，高可用，高性能
• • 简介
  • 高并发
  • 高性能
  • 高可用
  • 方案设计
• 架构图

参考

网站视频：亿级流量网站架构核心技术：https://www.bilibili.com/video/BV18h41117Wn?p=12

阿里内部的互联网三高架构是真的牛批：https://www.cnblogs.com/QLCZ/p/14793816.html

阿里P8面试官：如何设计一个扛住千万级并发的架构（超级详细）：https://www.cnblogs.com/mic112/p/15420129.html
【实践】网络货运平台的技术架构，其战略层和战术层设计原则，避免走哪些弯路？：https://www.kuotian.net/wlhy/125.html

1. 课程介绍以及高并发高可用复杂系统中的缓存架构有哪些东西：https://zq99299.github.io/note-book/cache-pdp/001-introduce.html#%E7%8E%B0%E5%9C%A8%E5%B8%B8%E8%A7%81%E7%9A%84-java-%E5%B7%A5%E7%A8%8B%E5%B8%88-%E6%9E%B6%E6%9E%84%E5%B8%88%E5%AF%B9%E7%BC%93%E5%AD%98%E6%8A%80%E6%9C%AF%E7%9A%84%E4%BA%86%E8%A7%A3%E5%92%8C%E6%8E%8C%E6%8F%A1%E7%A8%8B%E5%BA%A6

1.首先看是否能扩展机器，在有成本的情况下，尽量考虑mq，毕竟已经帮我们做好了重试，消息持久化等功能
2.RabbitMQ和RockteMQ选型，尽量采用RocketMQ，RabbitMQ不是用java语言编写，扩展能力比较差，而且抗并发能力与RocktMQ相差很远
3.lcn和seata之间选型，如果数据需要保证强一致性，就选择lcn。如果不需要，就选择seata。而且，lcn现在已经停止更新。

分布式事务

2PC、3PC、TCC、MQ、Seata 这五种分布式事务解决方案，还详细的实践了 Seata 中间件。但不管我们选哪一种方案，在项目中应用都要谨慎再谨慎，除特定的数据强一致性场景外，能不用尽量就不要用，因为无论它们性能如何优越，一旦项目套上分布式事务，整体效率会几倍的下降，在高并发情况下弊端尤为明显。
https://www.cnblogs.com/chengxy-nds/p/14046856.html

分布式事务选型
https://cloud.tencent.com/developer/article/1699619

高可用

jmeter—2000对订单服务压测

提交的任务被线程池拒绝了
HystrixRuntimeException: StockService#deductStock(Integer,Integer) could not be queued for execution and no fallback available
with root cause：
Task java.util.concurrent.FutureTask@e5fb rejected from java.util.concurrent.ThreadPoolExecutor@8da830e[Running, pool size = 10, active threads = 10, queued tasks = 0, completed tasks = 4261]

tomcat支持200个请求连接。

200个都过来访问创建订单接口，200个线程都走stock–>credit–>delivery.现在stock挂掉了，那么200个线程资源就都耗时在这里，不会被释放掉。后面在来的请求就都需要等待了，并且后面如果有请求过来想访问查询订单接口，也需要等待，因为tomcat没有线程能过来处理该请求了-----hystrix现在就说：默认我只给你创建订单接口分配一个10线程的线程池，如果我这10个线程处理不过来，那你在请求该接口我就会直接拒绝执行你的任务。这样话就算200个都过来访问创建订单接口，201个请求来访问查询订单接口也是可以用的。

高并发，高可用，高性能

简介

软件开发通常会提到一个名词 “三高”，即高并发、高性能、高可用。
具体的指标定义，如：高并发方面要求QPS 大于 10万；高性能方面要求请求延迟小于 100 ms；高可用方面要求系统可用性高于 99.99%。

高并发
我们使用 QPS（Queries Per Second，每秒查询率）来衡量系统承载能力

高性能
性能直接影响用户的感官体验，访问一个系统，如果超过5秒没有响应，绝大数用户会选择离开。

高可用
高可用指标是指用来衡量一个系统可用性有多高。

高并发

我们使用 QPS（Queries Per Second，每秒查询率）来衡量系统承载能力。 架构策略有哪些？

1、负载均衡

正所谓双拳难敌四手，高并发撑场面的首选方案就是集群化部署，一台服务器承载的QPS有限，多台服务器叠加效果就不一样了。

如何将流量转发到服务器集群，这里面就要用到负载均衡，比如：LVS 和 Nginx。

常用的负载算法有轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接数法等

业务实战：对于千万级流量的秒杀业务，一台LVS扛不住流量洪峰，通常需要 10 台左右，其上面用DDNS（Dynamic DNS）做域名解析负载均衡。搭配高性能网卡，单台LVS能够提供百万以上并发能力。

注意， LVS 负责网络四层协议转发，无法按 HTTP 协议中的请求路径做负载均衡，所以还需要 Nginx

2、池化技术(连接复用)

复用单个连接无法承载高并发，如果每次请求都新建连接、关闭连接，考虑到TCP的三次握手、四次挥手，有时间开销浪费。池化技术的核心是资源的“预分配”和“循环使用”，常用的池化技术有线程池、进程池、对象池、内存池、连接池、协程池。

连接池的几个重要参数：最小连接数、空闲连接数、最大连接数

Linux 内核中是以 进程 为单元来调度资源的，线程也是轻量级进程。所以说，进程、线程都是由内核来创建并调度。协程是由应用程序创建出来的任务执行单元，比如 Go 语言中的协程“goroutine”。 协程本身是运行在线程上，由应用程序自己调度，它是比线程更轻量的执行单元。

在 Go 语言中，一个协程初始内存空间是 2KB（Linux 下线程栈大小默认是 8MB），相比线程和进程来说要小很多。协程的创建和销毁完全是在用户态执行的，不涉及用户态和内核态的切换。另外，协程完全由应用程序在用户态下调用，不涉及内核态的上下文切换。协程切换时由于不需要处理线程状态，需要保存的上下文也很少，速度很快。

Go语言中协程池的实现方法有两种：抢占式和调度式。

抢占式协程池，所有任务存放到一个共享的 channel 中，多个协程同时去消费 channel 中的任务，存在锁竞争。

调度式协程池，每个协程都有自己的 channel，每个协程只消费自己的 channel。下发任务的时候，采用负载均衡算法选择合适的协程来执行任务。比如选择排队中任务最少的协程，或者简单轮询。

3、流量漏斗

上面讲的是正向方式提升系统QPS，我们也可以逆向思维，做减法，拦截非法请求，将核心能力留给正常业务！

互联网高并发流量并不都是纯净的，也有很多恶意流量（比如黑客攻击、恶意爬虫、黄牛、秒杀器等），我们需要设计流量拦截器，将那些非法的、无资格的、优先级低的流量过滤掉，减轻系统的并发压力。

拦截器分层：

网关和 WAF（Web Application Firewall，Web 应用防火墙）

采用封禁攻击者来源 IP、拒绝带有非法参数的请求、按来源 IP 限流、按用户 ID 限流等方法

风控分析。借助大数据能力分析订单等历史业务数据，对同ip多个账号下单、或者下单后支付时间过快等行为有效识别，并给账号打标记，提供给业务团队使用。

下游的每个tomcat实例应用本地内存缓存化，将一些库存存储在本地一份，做前置校验。当然，为了尽量保持数据的一致性，有定时任务，从 Redis 中定时拉取最新的库存数据，并更新到本地内存缓存中。

高性能

性能直接影响用户的感官体验，访问一个系统，如果超过5秒没有响应，绝大数用户会选择离开。

那么有哪些因素会影响系统的性能呢？

1. 用户网络环境
2. 请求/响应的数据包大小
3. 业务系统 CPU、内存、磁盘等性能
4. 业务链路的长度
5. 下游系统的性能
6. 算法实现是否高效

当然，随着并发数的提升，系统压力增大，平均请求延迟也会增大。

1、高性能缓存

对一些热点数据每次都从 DB 中读取，会给 DB 带来较大的压力，导致性能大幅下降。所以，我们需要用缓存来提升热点数据的访问性能，比如将活动信息数据在浏览器的缓存中保存一段时间。

缓存根据性能由高到低分为：寄存器、L1缓存、L2缓存、L3缓存、本地内存、分布式缓存

上层的寄存器、L1 缓存、L2 缓存是位于 CPU 核内的高速缓存，访问延迟通常在 10 纳秒以下。L3 缓存是位于 CPU 核外部但在芯片内部的共享高速缓存，访问延迟通常在十纳秒左右。高速缓存具有成本高、容量小的特点，容量最大的 L3 缓存通常也只有几十MB。

本地内存是计算机内的主存储器，相比 CPU 芯片内部的高速缓存，内存的成本要低很多，容量通常是 GB 级别，访问延迟通常在几十到几百纳秒。

内存和高速缓存都属于掉电易失的存储器，如果机器断电了，这类存储器中的数据就丢失了。

特别说明：在使用缓存时，要注意缓存穿透、缓存雪崩、缓存热点问题、缓存数据一致性问题。当然为了提升整体性能通常会采用多级缓存组合方案（浏览器缓存+服务端本地内存缓存+服务端网络内存缓存）

2、日志优化，避免IO瓶颈

当系统处理大量磁盘 IO 操作的时候，由于 CPU 和内存的速度远高于磁盘，可能导致 CPU 耗费太多时间等待磁盘返回处理的结果。对于这部分 CPU 在 IO 上的开销，我们称为 “iowait”。

在IO中断过程中，如果此时有其他任务线程可调度，系统会直接调度其他线程，这样 CPU 就相应显示为 Usr 或 Sys；但是如果此时系统较空闲，无其他任务可以调度，CPU 就会显示为 iowait（实际上与 idle 无本质区别）。

磁盘有个性能指标：IOPS，即每秒读写次数，性能较好的固态硬盘，IOPS 大概在 3 万左右。对于秒杀系统，如果单节点QPS在10万，每次请求产生3条日志，那么日志的写入QPS在 30W/s，磁盘根本扛不住。

Linux 有一种特殊的文件系统：tmpfs（临时文件系统），它是一种基于内存的文件系统，由操作系统管理。当我们写磁盘的时候实际是写到内存中，当日志文件达到我们的设置阈值，操作系统会将日志写到磁盘中，并将tmpfs中的日志文件删除。

这种批量化、顺序写，大大提升了磁盘的吞吐性能！

高可用

高可用指标是指用来衡量一个系统可用性有多高。

MTBF（Mean Time Between Failure），系统可用时长

MTTR（Mean Time To Repair），系统从故障后到恢复正常所耗费的时间

SLA（Service-Level Agreement），服务等级协议，用于评估服务可用性等级。计算公式是 MTBF/(MTBF+MTTR)

一般我们所说的可用性高于 99.99%，是指 SLA 高于 99.99%。

技术架构，高可用有哪些策略？

多云架构、异地多活、异地备份

主备切换，如redis缓存、mysql数据库，主备节点会实时数据同步、备份。如果主节点不可用，自动切换到备用节点

微服务，无状态化架构，业务集群化部署，有心跳检测，能最短时间检测到不可用的服务。

通过熔断、限流，解决流量过载问题，提供过载保护

重视web安全，解决攻击和XSS问题

1、主备切换，缩减故障时间

当系统出现故障时，首要任务不是立马查找原因，考虑到故障的复杂样，定位排查要花些时间，等问题修复好，SLA也降了好几个档。有没有更快的方式解决这个问题？ 那就是故障转移。

当发现故障节点的时候，不是尝试修复它，而是立即把它隔离，同时将流量转移到正常节点上。这样通过故障转移，不仅减少了 MTTR 提升了 SLA，还为修复故障节点赢得了足够的时间。

主备切换大致分为三步：

第一步故障自动侦测（Auto-detect），采用健康检查、心跳等技术手段自动侦测故障节点；

第二步自动转移（FailOver），当侦测到故障节点后，采用摘除流量、脱离集群等方式隔离故障节点，将流量转移到正常节点；

第三步自动恢复（FailBack），当故障节点恢复正常后，自动将其加入集群中，确保集群资源与故障前一致。

2、熔断，提供过载保护

所谓过载保护，是指负载超过系统的承载能力时，系统会自动采取保护措施，确保自身不被压垮。

熔断就是在系统濒临崩溃的时候，立即中断服务，从而保障系统稳定避免崩溃。它类似于电器中的“保险丝”，当电流过大的时候，“保险丝”会先被烧掉，断开电流，以免电路过热烧毁电器引起火灾。

例子：熔断触发条件往往跟系统节点的承载能力和服务质量有关，比如 CPU 的使用率超过 90%，请求错误率超过 5%，请求延迟超过 500ms， 它们中的任意一个满足条件就会出现熔断。

3、限流，提供过载保护

限流的原理跟熔断有点类似，都是通过判断某个条件来确定是否执行某个策略。但是又有所区别，熔断触发过载保护，该节点会暂停服务，直到恢复。限流，则是只处理自己能力范围之内的请求，超量的请求会被限流。

限流算法主要有：计数器限流、滑动窗口限流、令牌桶限流、漏桶限流。网上的资料很多，这里就不多赘述。

4、降级

比如电商大促，业务在峰值时刻，系统抵挡不住全部的流量时，系统的负载、CPU 的使用率都超过了预警水位，可以对一些 非核心的功能进行降级 ，降低系统压力，比如把 商品评价 、 成交记录 等功能临时关掉。 弃车保帅 ， 保证 创建订单、支付 等核心功能的正常使用 。

当然不同业务、不同公司处理方式也各不相同，需要结合实际场景，和业务方一块讨论，最后达成一个统一认可的降级方案。

总结下来：降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性

方案设计

分布式架构中的三高：高并发、高性能、高可用：https://cloud.tencent.com/developer/article/1905374
垂直伸缩，就是提升单台服务器的处理能力。比如用更快频率的 CPU，用更多核的 CPU，用更大的内存，用更快的网卡，用更多的磁盘组成一台服务器，使单台服务器的处理能力得到提升。（在互联网以及物联网领域，并不使用垂直伸缩这种方案，而是使用水平伸缩）
水平伸缩指的是不去提升单机的处理能力，而是使用更多的服务器，将这些服务器构成一个分布式集群，通过这个集群，对外统一提供服务，以此来提高系统整体的处理能力（这就是互联网应用和云计算中普遍采用的分布式架构方案）

消息队列&反向代理&CDN&分布式数据库架构
海量数据的存储，主要通过分布式数据库、分布式文件系统、NoSQL 数据库解决。

直接在数据库上查询已经无法满足这些数据的查询性能要求，还需要部署独立的搜索引擎提供查询服务。

同时减少数据中心的网络带宽压力，提供更好的用户访问延时，使用 CDN 和反向代理提供前置缓存，尽快返回静态文件资源给用户。

为了使各个子系统更灵活易于扩展，则使用分布式消息队列将相关子系统解耦，通过消息的发布订阅完成子系统间的协作。

使用微服务架构将逻辑上独立的模块在物理上也独立部署，单独维护，应用系统通过组合多个微服务完成自己的业务逻辑，实现模块更高级别的复用，从而更快速地开发系统和维护系统。

架构图

https://www.upyun.com/tech/article/668/%E4%BA%BF%E7%BA%A7%E6%B5%81%E9%87%8F%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E6%BC%94%E8%BF%9B%E4%B9%8B%E8%B7%AF.html

亿级流量电商网站中台微服务架构图

https://blog.youkuaiyun.com/qq_41063141/article/details/123157152