简述互联网三高架构
简述互联网三高架构
李同
(石家庄铁道大学,河北省 石家庄市 050000)
摘要:本文章对互联网三高架构,即高并发、高性能、高可用进行描述,主要概述了三高的概念、产生的场景,然后对解决三高问题提出了解决思路,最后举例子说明大公司时如何优化三高问题的。
关键词:互联网;三高;高性能;高并发;高可用;架构
中图分类号: 文献标志码:A
0 引言
互联网的三高架构就是指设计互联网系统架构时需要满足高可用,高性能,高并发。随着互联网的普及,网民越来越多,带来的是对互联网公司系统的压力,下面介绍一下互联网三高架构和解决三高问题的思路。
1 高并发
1.1 概念
高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等
1.2 高并发场景
互联网应用以及云计算的普及,使得架构设计和软件技术的关注点从如何实现复杂的业务逻 辑,转变为如何满足大量用户的高并发访问请求。
一个简单的计算处理过程,如果一旦面对大量的用户访问,整个技术挑战就会变得完全不同,软件开发方法、技术团队组织、软件的过程管理都会完全不同。
2 高性能
简单的说,高性能(High Performance)就是指程序处理速度快,所占内存少,cpu占用率低。
高并发和高性能是紧密相关的,提高应用的性能,是肯定可以提高系统的并发能力的。
3 高可用
3.1 概念
高可用性(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性(一直都能用)。
3.2 高可用场景
我们知道,Web 应用在各种情况下都有可能不可访问,也就是不可用。各种硬件故障,比如应用服务器及数据库宕机、网络交换机宕机、磁盘损坏、网卡松掉等等。还有各种软件故障,程序 Bug 什么的。即使没有 Bug,程序要升级,必须要关闭进程重新启动,这段时间应用也是不可用的;此外,还有外部环境引发的不可用,比如促销引来大量用户访问,导致系统并发压力太大而崩溃,以及,黑客攻击、机房火灾、挖掘机挖断光缆,各种情况导致的应用不可用。而互联网的高可用是说,在上面各种情况下,应用都要是可用的,用户都能够正常访问系统,完成业务处理。
4 解决思路
4.1 缓存
在计算机中,缓存是存储数据的硬件或软件组件,以便可以更快地满足将来对该数据的请求。存储在缓存中的数据可能是之前计算结果,也可能是存储在其他位置的数据副本。
4.2 预处理和延后处理
预先延后,这其实是一个事物的两面,不管是预先还是延后核心思想都是将本来该在实时链路上处理的事情剥离,要么提前要么延后处理。降低实时链路的路径长度, 这样能有效提高系统性能。
4.3 池化
这些池子包括:内存池、连接池、线程池、对象池等等。内存、连接、线程这些都是资源,创建线程、分配内存、数据库连接这些操作都有一个特征, 那就是创建和销毁过程都会涉及到很多系统调用或者网络 IO。 每次都在请求中去申请创建这些资源,就会增加请求处理耗时,但是如果我们用一个容器(池)把它们保存起来,下次需要的时候,直接拿出来使用,避免重复创建和销毁浪费的时间。池化实际上是预处理和延后处理的一种应用场景,通过池子将各类资源的创建提前和销毁延后。
4.4 同步变异步
对于处理耗时的任务,如果采用同步的方式,那么会增加任务耗时,降低系统并发度。可以通过将同步任务变为异步进行优化。
4.5 消息队列
消息队列的核心思想就是把同步的操作变成异步处理,异步处理会带来相应的好处,比如:
服务解耦、提高系统的并发度,将非核心操作异步处理,不会阻塞住主流程等,但是异步处理也不全是好处,也会导致一些问题:比如降低了数据一致性,从强一致性变为最终一致性,有消息丢失的风险。
4.5 批量处理
在涉及到网络连接、IO等情况时,将操作批量进行处理能够有效提高系统的传输速率和吞吐量。在前后端通信中,通过合并一些频繁请求的小资源可以获得更快的加载速度。比如我们后台 RPC 框架,经常有更新数据的需求,而有的数据更新的接口往往只接受一项,这个时候我们往往会优化下更新接口,使其能够接受批量更新的请求,这样可以将批量的数据一次性发送,大大缩短网络 RPC 调用耗时。
4.7 数据库
索引是我们平时在使用数据库过程中接触得最多的优化方式,它可以有效的加快查询速度。
读写分离避免读写锁争用。
分库分表中,常见的拆分类型有垂直拆分和水平拆分,它也可以有效的加快查询速度。
5 案例
支付宝春节集五福活动,这类活动中奖奖金一般会显示 “稍后到账”,为什么呢?那当然是到账这个操作不简单!
到账即转账,A 账户给 B 账户转钱,A 减钱, B 就必须要同时加上钱,也就是说不能 A 减了钱但 B 没有加上,这就会导致资金损失。资金安全是支付业务的生命线,这可不行。
这两个动作必须一起成功或是一起都不成功,不能只成功一半,这是保证数据一致性。保证两个操作同时成功或者失败就需要用到事务。
如果去实时的做到账,那么大概率数据库的 TPS(每秒处理的事务数) 会是瓶颈。通过产品提示,将到账操作延后处理,解决了数据库 TPS 瓶颈。
考虑拼多多电商系统,一般有订单表、用户表、支付表、商品表、商家表等,最初这些表都在一个数据库里。后来随着砍一刀带来的海量用户,拼多多后台扛不住了! 于是紧急从阿里巴巴那里挖来了几个大佬对系统进行重构。
参考文献
[1] 叁歲伎倆. 蒲公英云原创文章. https://www.dandelioncloud.cn/article/details/1433361093473050625, 2021