专栏首页天马行空布鲁斯空谈系统架构设计之高并发、高可用

空谈系统架构设计之高并发、高可用

对于一个应用系统,特别是互联网系统,高并发、高可用是两个非常重要的非功能性需求,这篇文章尝试从应用系统架构角度分析如何满足这两个特性。

1

高并发,high concurrency,简单讲就是说系统可以同时支撑大量的并发请求,反映的是系统的计算能力。个人理解,高并发都可以基于scalability来实现,而scalability通常可分为两个维度:垂直扩展(scale up)和水平扩展(scale out)。垂直扩展(scale up)就是通过不断增加单机计算资源(cpu、memory等)来提高并发处理能力,而水平扩展(scale out)则是通过增加机器数量来提高并发处理能力;相对来说,scale up可能更加容易,因为对于单机系统,不用考虑分布式事务等很tricky的问题,但是由于计算机硬件发展的瓶颈,并且基于成本的考虑,通常我们优先考虑的方向是scale out,因为scale out不但可以实现高并发,同时也可以一定程度上实现高可用。

高可用,high availability,简单讲就是说系统可以在“任何时候”都保持服务在线,即使是在有服务器宕机的情况下,反映的是系统的稳定性。从理论上来说,高可用则是通过增加冗余(replication)来实现,当有节点发的故障时,自动切换到备份节点上。

2

一个典型的应用系统架构可能都包含这三层结构:web server层(比如nginx),app server层(比如tomcat)和数据库层(比如postgres),要实现高并发和高可用,一般来说都是针对这三层分别考虑实现。

2.1

web server层,通常架构在app server层前面,主要功能是负载均衡、反向代理等,显然这提高了app server层的并发处理能力,但是随之而来的就是web sever本身可能成为性能瓶颈和单点故障点。web server层可选的方案,除了常见的nginx,还有一些其它流行的方案,比如haproxy、lvs等,甚至基于硬件优化的F5。

web server的单点故障问题,反过来讲也就是高可用问题,主流的解决方案是部署多台web server,使用keepalived把多台web server组成一个集群,对外暴露一个虚拟IP(VIP),集群在任意时候只有主web server提供服务,其它从web server作为备份,如果主web server宕机,VIP则自动漂移到一台从web server。

这个方案虽然实现了高可用,但却还是存在单点性能瓶颈的问题,因为即使是号称再好的web server组件,也终究会有高并发的极限,其实本质上这就是一个如何实现web server层高并发的问题。要解决这个问题,只能做水平扩展(scale out),部署多个web server集群,每个暴露一个VIP,通过DNS轮询(或者gslp、gtm等技术)把用户请求分散到不同的web server集群上,以此实现高并发。

2.2

app server层,常规的做法就是直接scale out,部署多个duplicated的app server,借助web server层的负载均衡,一定程度既实现了高可用,也实现了高并发。

在app server层做scale out之前,需要考虑另外一个问题:由于application常常需要保存一些状态信息(比如用户的session等),如果直接scale out,用户的session可能会丢失或者不能保持。针对这个问题,现在流行的解决方案是把这些状态信息持久化到缓存中(比如redis等),这样application就是一个无状态的服务,对于无状态的服务,scale out就不会有问题。

从高并发实现的角度,可以分别从scale up和scale out两个方向考虑;回到application功能实现层面,也可以有scale up和scale out两个方向,其实它们分别对应的就是monolith模式和micro service模式,个人认为,正如scale out所展现的扩展性优点,micro service的最大好处则是一种团队合作开发模式的提高,更加敏捷高效,易于扩展。

2.3

数据库层,由于所有用户的数据都是存储在数据库,一旦数据库挂了,即使上面层的高可用、高并发做得再好,整个系统也不可用,所以数据库层的高可用、高并发尤其重要。由于数据库层是有状态的,如果和app server层类似,通过简单的scale out实现高可用、高并发,并且各个数据库节点都可以读写的话,则可能会产生数据不一致的问题(CAP理论);并且,即使可以规避这个问题,比如采用读写分离(只允许主节点写,从节点读),最终也会由于单个数据库表太大,而导致读数据性能降低,这种情况也许可以通过分表解决,但是由于只能是主节点接收写请求,主节点则很容易成为高并发写的性能瓶颈。

所以,对于有状态的数据库层,要实现高并发、高可用,应该怎样设计呢?简单讲,高可用还是通过增加冗余(replication)实现,主从节点无缝切换可以使用上面提到的keepalived方法。而高并发则是通过分库实现,把数据通过一定的算法分散到不同的数据库节点存放,这样每个数据库节点只需要处理部分流量,相比简单的scale out,这种方式一定程度减少了数据冗余,并且支持高并发写,所以我们也许可以称这种scale out方式为“复杂的scale out”。

从整体上来讲,数据库层实现高并发、高可用的方式和 kafka、redis等中间件实现的原理类似,即分别通过partition和replication来实现。

3

提高系统的高并发、高可用,除了上面提到的infrastructure层面的一些设计之外,有时候我们还需要从application本身架构层面考虑,比如:对于一个秒杀系统,也需要支持高并发、高可用,但是由于这类系统可能只是用于促销,意即可能只会在活动开始一段时间有高并发请求,并不会持续,所以可能不需要从基础架构层面提升,因为那样也意味着更高的成本。那么,针对这类场景,如何从application本身架构层面实现高并发、高可用呢?

其实,网上有很多文章介绍得很详细,但总结下来,有两个方面:

一、限流,防止突然出现大流量把系统搞挂。具体实现可以有:1)rate limit,限制用户发达请求的频率;2)把商品库存信息维护在redis中,库存扣减完了就直接返回后续所有请求。

二、削峰,秒杀请求先不做校验,直接存数据库,然后马上返回给用户“正在排队中”等信息,接着通过queue通知订单处理服务异步处理请求,完成下单操作。这样做的一个好处是,由于真正完成下单处理的时间较长,而秒杀请求直接存数据库可以很快,利用queue做一个缓冲,提高了用户可见的高并发。并且,基于这样的实现,使得系统更加resilient,在面对突发的高并发时,可以保证高可用。

4

对于高并发,除了架构层面的考虑,从服务器物理连接层面,也需要能支持更多的并发连接;随着技术的发展,现在主流的tomcat、nginx、redis等都是基于多路复用技术epoll实现,大大提高了并发连接数,进而从这的个层面有效的实现了高并发。

5

对于高可用,为了兼顾一致性(consistency)和可用性(availability),分布式数据系统常常会借助于一些分布式共识算法(consensus algorithm)来实现replication,比如zookeeper、etcd等;或者再考虑到性能,会采用一些基于分布式共识算法延伸而来的折中方案,比如kafka的ISR。数据库的高可用,除了上面提到的keepalived方法,也可以使用zookeeper来管理主从节点,并且实现主从节点自动切换(选举),类似于kafka。

本文分享自微信公众号 - 天马行空布鲁斯(gh_2feda5c053bd),作者:huazailmh

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-11-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 浅析一个sql server数据库事务死锁问题

    一个学生管理系统,数据库是sql server,有一个Web API用于创建student。student对象的表结构如下:

    Bruce Li
  • 关于设计模式的那些事(一)

    通常我们说的设计模式,指的是GoF23(Gang of Four),包括23个常用的设计模式。这里尝试从不同的角度聊一聊其中几个设计模式。

    Bruce Li
  • 关于html的input元素,property和attribute的区别

    之前在项目中遇到一个很tricky的关于html的input元素的问题,个人觉得挺有意思,于是记录下来。这个问题也是在ui的自动化测试中,可能会碰到的一个问题。

    Bruce Li
  • Yii2中使用order by locate的写法

    素描
  • MySQL 5.7 vs 8.0,哪个性能更牛?

    出处:https://www.cnblogs.com/YangJiaXin/p/11234591.html

    程序IT圈
  • MySQL 5.7 vs 8.0,哪个性能更牛?

    测试mysql5.7和mysql8.0 分别在读写、只读、只写模式下不同并发时的性能(tps,qps)

    民工哥
  • 一周 Go World 新鲜事Asta 优选

    01 ServiceMesh时代选边与站队(附PPT ) 在2017年,Service Mesh技术在快速成长。我们看到在年中的时候,Istio非常霸气的登场。...

    企鹅号小编
  • python 基础篇(一)

    默认的python的文件为:文件名.py #!/usr/bin/env python    # coding=utf-8     对中文的支持(切记:等号两...

    py3study
  • Nacos入门指南03 - 服务发现实践

    然后在 service-consumer 的 Controller 中实现对 service-provider 的接口调用。

    dys
  • Leetcode 67 Add Binary

    Given two binary strings, return their sum (also a binary string). For example...

    triplebee

扫码关注云+社区

领取腾讯云代金券