高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。
高并发一方面可以提高资源利用率,加快系统响应速度,但是同时也会带来安全性,分布式事务、死锁等问题。
并发:一个处理器同时处理多个任务。
并行:多个处理器或者是多核的处理器同时处理多个不同的任务。
并发的指标一般有QPS,TPS,IOPS,并发用户数,PV,响应时间等。
QPS:每秒响应请求数,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数,也即是最大吞吐能力。
Transactions Per Second,也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
QPS基本类似于TPS,但是不同的是,对于一个页面的一次访问,形成一个TPS;但一次页面请求,可能产生多次对服务器的请求,服务器对这些请求,就可计入“QPS”之中。
并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量一定程度上代表了系统的并发用户数。
响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。一般而言,用户感知友好的高并发系统,时延应该控制在250毫秒以内。
PV(Page View):页面访问量,即页面浏览量或点击量,用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。
互联网分布式架构设计,提高系统并发能力的方式,方法论上主要有两种:垂直扩展(Scale Up,也叫竖向扩展)与水平扩展(Scale Out,也叫横向扩展)。
1、垂直方向:提升单机能力
提升单机处理能力又可分为硬件和软件两个方面:
硬件方向,升级服务器硬件,购买多核高频机器,大内存,大容量磁盘等。
软件方向,包括用更快的数据结构(编程语言级别的并发编程),改进架构,应用多线程、协程(select/poll/epoll等IO多路复用技术),以及上性能优化各种手段,但是这种方式很容易出现瓶颈。
2、水平方向:分布式集群
为了解决分布式系统的复杂性问题,一般会用到架构分层和服务拆分,通过分层做隔离,通过微服务解耦。
这个理论上没有上限,只要做好层次和服务划分,加机器扩容就能满足需求,但实际上并非如此,一方面分布式会增加系统复杂性,另一方面集群规模上去之后,也会引入一堆服务发现、服务治理的新问题。
因为垂直向的限制,所以,我们通常更关注水平扩展,高并发系统的实施也主要围绕水平方向展开。
单机的硬件扩展成本较高,软件优化易出现性能瓶颈,因此利用集群解决高并发问题。负载均衡是常用的解决方案,即把前端流量分配到不同的服务节点上。
在集群化的架构下,可以采用池化(内存池,连接池,线程池),分布式缓存,分布式消息队列,流控技术(服务降级,应用拆分,限流)和数据库高并发(分库分表,读写分离等)提高并发能力。
负载均衡可以分为3种:
1、DNS负载均衡,客户端通过URL发起网络服务请求的时候,会去DNS服务器做域名解释,DNS会按一定的策略(比如就近策略)把URL转换成IP地址,同一个URL会被解释成不同的IP地址,这便是DNS负载均衡,它是一种粗粒度的负载均衡,它只用URL前半部分,因为DNS负载均衡一般采用就近原则,所以通常能降低时延,但DNS有cache,所以也会更新不及时的问题。
2、硬件负载均衡,通过布置F5,A10等专门的负载均衡设备到机房做负载均衡,性能高,但是价格昂贵。
3、软件负载均衡,利用软件实现四层负载均衡(LVS)和七层负载均衡(Nginx)。
内存池创建的方法:
1、对于用户申请的大块内存使用内存映射
2、对于小块内存从内存池合适的链表中取出
注:Linux本身有内存管理方式,但是系统级别的内存优化技术远不能满足实际需求,比较流行的内存优化技术包括tcmalloc、ptmalloc、jemalloc等。
内存池的作用:
1、存放大块数据
2、存放数据缓存
进程池和线程池的作用:
1、 避免动态启动的时间开销
2、 使得处理更加单一
3、 充分利用硬件资源
进程池和线程池的注意事项:
1、 典型的生产者消费者问题
2、 注意访问共享资源存在的竞争
连接池是创建和管理一个连接的缓冲池的技术,这些连接准备好被任何需要它们的线程使用,比如数据库连接池。
连接池创建的方法:
1、 预先分配固定数据的连接
2、 对每一个连接都分配相应的资源
连接池的作用:
1、 为创建新连接提速
2、 可用于集群内部永久性连接
缓存可以分为本地缓存和分布式缓存。
本地缓存:编程实现(成员变量、局部变量、静态变量)。
分布式缓存:借助Redis、Memcache实现。
一般系统的写入请求远少于读请求,针对写少读多的场景,很适合引入缓存集群。在写数据库的时候同时写一份数据到缓存集群里,然后用缓存承载大部分的读请求,当缓存中不存在的时候才去数据库查找,这样通过缓存集群,就可以用更少的机器资源承载更高的并发。
缓存的命中率一般能做到很高,而且速度很快,处理能力也强(单机很容易做到几万并发),是理想的解决方案。
当然,在使用分布式缓存的时候,需要格外注意处理一致性问题,缓存击穿,缓存穿透,缓存雪崩等问题。
分布式缓存在读多写少的场景性能优异,对于写操作较多的场景可以采用消息队列集群,它可以很好地做写请求异步化处理,实现削峰填谷的效果。
消息队列能做解耦,在只需要最终一致性的场景下,很适合用来配合做流控。
业界有很多著名的消息中间件,比如ZeroMQ,rabbitMQ,kafka等。
1、业务耦合;
2、最终一致性;
3、广播;
4、错峰与流控。
自动降级:超时、失败次数、故障、限流
人工降级:秒杀、双11大促等
服务降级要考虑的问题:
1、核心服务、非核心服务
2、是否支持降级,降级策略
应用拆分原则:
1、业务优先;
2、循序渐进;
3、兼顾技术:重构、分层;
4、可靠性测试
限流的常用处理手段有:计数器、滑动窗口、漏桶、令牌。
1、计数器法
计数器是一种比较简单的限流算法,在一段时间内,进行计数,与阀值进行比较,到了时间临界点,将计数器清0。
但是,计数器法存在一个时间临界点的问题。比如,在11:50:00到11:59:59这段时间内没有用户请求,然后在12:00:01这一瞬时发出1000个请求,12:00:59又出现1000个请求,在这个临界点可能会承受恶意用户的大量请求,甚至超出系统预期的承受。
2、滑动窗口
由于计数器存在临界点缺陷,后来出现了滑动窗口算法来解决。
滑动窗口的意思是说把固定时间片,进行划分,并且随着时间的流逝,进行移动,这样就巧妙的避开了计数器的临界点问题。也就是说这些固定数量的可以移动的格子,将会进行计数判断阀值,因此格子的数量影响着滑动窗口算法的精度。
3、漏桶算法
虽然滑动窗口有效避免了时间临界点的问题,但是依然有时间片的概念,而漏桶算法在这方面比滑动窗口而言,更加先进。
有一个固定的桶,进水的速率是不确定的,但是出水的速率是恒定的,当水满的时候是会溢出的。
4、令牌桶算法
从某种意义上讲,令牌桶算法是对漏桶算法的一种改进,桶算法能够限制请求调用的速率,而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。
在令牌桶算法中,存在一个桶,用来存放固定数量的令牌。算法中存在一种机制,以一定的速率往桶中放令牌。每次请求调用需要先获取令牌,只有拿到令牌,才有机会继续执行,否则选择选择等待可用的令牌、或者直接拒绝。
数据库高并发分为单机高并发(主要是存储引擎实现)和集群高并发:
1、单机高并发
InnoDB存储引擎采用多版本并发控制技术(MVCC)在不加锁的情况下,实现并发读写,同时通过事务隔离级别控制并发效率。
2、集群高并发
数据库集群高并发主要是通过分库分表、主备读写分离等方法实现的。