“软件系统三高问题”高并发、高性能、高可用系统设计经验

简介: ​ 总的来说解决三高问题核心就是 “分字诀”业务分层、系统分级、服务分布、数据库分库/表、动静分离、同步拆分成异步、单线程分解成多线程、原数据缓存分离、分流等等。。。。直观的表述就是:从前端用的CDN、动静分离,到后台服务拆分成微服务、分布式、负载均衡、缓存、池化、多线程、IO、分库表、搜索引擎等等。都是强调一个“分”字。

总的来说解决三高问题核心就是 “分字诀”

业务分层、系统分级、服务分布、数据库分库/表、动静分离、同步拆分成异步、单线程分解成多线程、原数据缓存分离、分流等等。。。。
直观的表述就是:从前端用的CDN、动静分离,到后台服务拆分成微服务、分布式、负载均衡、缓存、池化、多线程、IO、分库表、搜索引擎等等。都是强调一个“分”字。

v2-29adfd1f2c519a5d92d3825b432f3460_r.jpg

原文地址:

【高并发、高性能、高可用】系统设计经验

软件开发通常会提到一个名词 “三高”,即高并发、高性能、高可用。

具体的指标定义,如:高并发方面要求QPS 大于 10万;高性能方面要求请求延迟小于 100 ms;高可用方面要高于 99.99%。

接下来,我们重点来介绍这 三高

一、高并发

我们使用 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秒没有响应,绝大数用户会选择离开。

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

用户网络环境
请求/响应的数据包大小
业务系统 CPU、内存、磁盘等性能
业务链路的长度
下游系统的性能
算法实现是否高效
当然,随着并发数的提升,系统压力增大,平均请求延迟也会增大。

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 的使用率都超过了预警水位,可以对一些非核心的功能进行降级,降低系统压力,比如把商品评价、成交记录等功能临时关掉。弃车保帅,保证 创建订单、支付 等核心功能的正常使用。

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

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

相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
5月前
|
消息中间件 NoSQL Java
Java高级开发:高并发+分布式+高性能+Spring全家桶+性能优化
Java高架构师、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师之路
|
6月前
|
存储 缓存 安全
高并发内存池实战:用C++构建高性能服务器(下)
高并发内存池实战:用C++构建高性能服务器
高并发内存池实战:用C++构建高性能服务器(下)
|
6月前
|
消息中间件 缓存 应用服务中间件
Nginx系列教程(02) - 高可用与高并发介绍
Nginx系列教程(02) - 高可用与高并发介绍
59 0
|
2月前
|
编解码 分布式计算 网络协议
一文让你深入了解 Java-Netty高性能高并发
一文让你深入了解 Java-Netty高性能高并发
76 1
|
8月前
|
消息中间件 存储 缓存
Kafka为什么是高性能高并发高可用架构
Kafka为什么是高性能高并发高可用架构
251 0
|
5月前
|
消息中间件 缓存 监控
直呼内行!阿里大佬离职带出内网专属“高并发系统设计”学习笔记
我们知道,高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。
|
5月前
|
消息中间件 缓存 算法
阿里技术专家,用257页文档分享多线程高并发性能调试经验
多线程和高并发这两大块,现在面试问得越来越多,也是相对一个初级的程序员向中高级迈进的必须要踏过的一个坎儿。
|
6月前
|
缓存 容灾 网络协议
Java面试题 -高并发、高可用、分布式
Java面试题 -高并发、高可用、分布式
89 0
|
6月前
|
存储 缓存 Linux
高并发内存池实战:用C++构建高性能服务器(上)
高并发内存池实战:用C++构建高性能服务器
|
7月前
|
缓存 监控 容灾
0-1设计高可用、高并发、高伸缩的分布式项目架构
0-1设计高可用、高并发、高伸缩的分布式项目架构

热门文章

最新文章