您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

亿级流量系统架构之如何设计全链路99.99%高可用架构

时间:2019-08-26 15:33:39  来源:  作者:

来自:石杉的架构笔记

一、前情回顾

上篇文章(《亿级流量系统架构之如何设计每秒十万查询的高并发架构》),聊了一下系统架构中的查询平台。

我们采用冷热数据分离:

  • 冷数据基于HBase+Elasticsearch+纯内存自研的查询引擎,解决了海量历史数据的高性能毫秒级的查询
  • 热数据基于缓存集群+MySQL集群做到了当日数据的几十毫秒级别的查询性能。

最终,整套查询架构抗住每秒10万的并发查询请求,都没问题。

本文作为这个架构演进系列的最后一篇文章,我们来聊聊高可用这个话题。所谓的高可用是啥意思呢?

简单来说,就是如此复杂的架构中,任何一个环节都可能会故障,比如MQ集群可能会挂掉、KV集群可能会挂掉、MySQL集群可能会挂掉。那你怎么才能保证说,你这套复杂架构中任何一个环节挂掉了,整套系统可以继续运行?

这就是所谓的全链路99.99%高可用架构,因为我们的平台产品是付费级别的,付费级别,必须要为客户做到最好,可用性是务必要保证的!

我们先来看看目前为止的架构是长啥样子的。

亿级流量系统架构之如何设计全链路99.99%高可用架构

二、MQ集群高可用方案

异步转同步 + 限流算法 + 限制性丢弃流量

MQ集群故障其实是有概率的,而且挺正常的,因为之前就有的大型互联网公司,MQ集群故障之后,导致全平台几个小时都无法交易,严重的会造成几个小时公司就有数千万的损失。我们之前也遇到过MQ集群故障的场景,但是并不是这个系统里。

大家想一下,如果这个链路中,万一MQ集群故障了,会发生什么?

看看右上角那个地方,数据库binlog采集中间件就无法写入数据到MQ集群了啊,然后后面的流控集群也无法消费和存储数据到KV集群了。这套架构将会彻底失效,无法运行。

这个是我们想要的效果吗?那肯定不是的,如果是这样的效果,这个架构的可用性保障也太差了。

因此在这里,我们针对MQ集群的故障,设计的高可用保障方案是:异步转同步 + 限流算法 + 限制性丢弃流量

简单来说,数据库binlog采集环节一旦发现了MQ集群故障,也就是尝试多次都无法写入数据到MQ集群,此时就会触发降级策略。不再写入数据到MQ集群,而是转而直接调用流控集群提供的备用流量接收接口,直接发送数据给流控集群。

但是流控集群也比较尴尬,之前用MQ集群就是削峰的啊,高峰期可以稍微积压一点数据在MQ集群里,避免流量过大,冲垮后台系统。

所以流控集群的备用流量接收接口,都是实现了限流算法的,也就是如果发现一旦流量过大超过了阈值,直接采取丢弃的策略,抛弃部分流量。

但是这个抛弃部分流量也是有讲究的,你要怎么抛弃流量?如果你不管三七二十一,胡乱丢弃流量,可能会导致所有的商家看到的数据分析结果都是不准确的。因此当时选择的策略是,仅仅选择少量商家的数据全量抛弃,但是大部分商家的数据全量保存。

也就是说,比如你的平台用户有20万吧,可能在这个丢弃流量的策略下,有2万商家会发现看不到今天的数据了,但是18万商家的数据是不受影响,都是准确的。但是这个总比20万商家的数据全部都是不准确的好吧,所以在降级策略制定的时候,都是有权衡的。

这样的话,在MQ集群故障的场景下,虽然可能会丢弃部分流量,导致最终数据分析结果有偏差,但是大部分商家的数据都是正常的。

大家看看下面的图,高可用保障环节全部选用浅红色来表示,这样很清晰。

亿级流量系统架构之如何设计全链路99.99%高可用架构

三、KV集群高可用保障方案

临时扩容Slave集群 + 内存级分片存储 + 小时级数据粒度

下一个问题,如果KV集群挂了怎么办?这个问题我们还真的遇到过,不过也不是在这个系统里,是在另外一个我们负责过的核心系统里,KV集群确实出过故障,直接从持续好多个小时,导致公司业务都几近于停摆,损失也是几千万级别的。

大家看看那个架构图的右侧部分,如果KV集群挂了咋办?那也是灾难性的,因为我们的架构选型里,直接就是基于kv集群来进行海量数据存储的,要是KV挂了,没任何高可用保障措施的话,会导致流控集群无法把数据写入KV集群,此时后续环节就无法继续计算了。

我们当时考虑过要不要引入另外一套存储进行双写,比如引入一套hbase集群,但是那样依赖会搞的更加的复杂,打铁还需自身硬,还是要从自身架构来做优化。

因此,当时选择的一套kv集群降级的预案是:临时扩容Slave集群 + 小时级数据粒度 + 内存级分片存储。

简单来说,就是一旦发现kv集群故障,直接报警。我们收到报警之后,就会立马启动临时预案,手动扩容部署N倍的Slave计算集群。

接着同样会手动打开流控集群的一个降级开关,然后流控集群会直接按照预设的hash算法分发数据到各个Slave计算节点。

这就是关键点,不要再基于kv集群存数据了,本身我们的Slave集群就是分布式计算的,那不是刚好可以临时用作分布式存储吗!直接流控集群分发数据到Slave集群就行了,Slave节点将数据留存在内存中即可。

然后Master节点在分发数据计算任务的时候,会保证计算任务分发到某个Slave节点之后,他只要基于本地内存中的数据计算即可。

将Master节点和Slave节点都重构一下,重构成本不会太高,但是这样就实现了本地数据存储 + 本地数据计算的效果了。

但是这里同样有一个问题,要知道当日数据量可是很大的!如果你都放Slave集群内存里还得了?

所以说,既然是降级,又要做一个balance了。我们选择的是小时级数据粒度的方案,也就是说,仅仅在Slave集群中保存最近一个小时的数据,然后计算数据指标的时候,只能产出每个小时的数据指标。

但是如果是针对一天的数据需要计算出来的数据指标,此时降级过后就无法提供了,因为内存中永远只有最近一个小时的数据,这样才能保证Slave集群的内存不会被撑爆。

对用户而言,就是只能看当天每个小时的数据指标,但是全天汇总的暂时就无法看到。

亿级流量系统架构之如何设计全链路99.99%高可用架构

四、实时计算链路高可用保障方案

计算任务重分配 + 主备切换机制

下一块就是实时计算链路的高可用保障方案了,其实这个之前给大家说过了,实时计算链路是一个分布式的架构,所以要么是Slave节点宕机,要么是Master节点宕机。

其实这个倒没什么,因为Slave节点宕机,Master节点感知到了,会重新分配计算任务给其他的计算节点;如果Master节点宕机,就会基于Active-Standby的高可用架构,自动主备切换。

咱们直接把架构图里的实时计算链路中的高可用环节标成红色就可以了

亿级流量系统架构之如何设计全链路99.99%高可用架构

五、热数据高可用保障方案

自研缓存集群查询引擎 + JVM本地缓存 + 限流机制

接着咱们来看左侧的数据查询那块,热数据也就是提供实时计算链路写入当日数据的计算结果的,用的是MySQL集群来承载主体数据,然后前面挂载一个缓存集群。

如果出现故障,只有两种情况:一种是MySQL集群故障,一种是缓存集群故障。

咱们分开说,如果是MySQL集群故障,我们采取的方案是:实时计算结果直接写入缓存集群,然后因为没有MySQL支撑,所以没法使用SQL来从MySQL中组装报表数据。

因此,我们自研了一套基于缓存集群的内存级查询引擎,支持简单的查询语法,可以直接对缓存集群中的数据实现条件过滤、分组聚合、排序等基本查询语义,然后直接对缓存中的数据查询分析过后返回。

但是这样唯一的不好,就是缓存集群承载的数据量远远没有MySQL集群大,所以会导致部分用户看不到数据,部分用户可以看到数据。不过这个既然是降级 ,那肯定是要损失掉部分用户体验的。

如果是缓存集群故障,我们会有一个查询平台里的本地缓存,使用ehcache等框架就可以实现,从mysql中查出来的数据在查询平台的jvm本地缓存里cache一下,也可以用作一定的缓存支撑高并发的效果。而且查询平台实现限流机制,如果查询流量超过自身承载范围,就限流,直接对查询返回异常响应。

亿级流量系统架构之如何设计全链路99.99%高可用架构

六、冷数据高可用保障方案

收集查询日志 + 离线日志分析 + 缓存高频查询

其实大家看上面的图就知道,冷数据架构本身就比比较复杂,涉及到ES、HBase等东西,如果你要是想做到一点ES、HBase宕机,然后还搞点儿什么降级方案,还是挺难的。

你总不能ES不能用了,临时走Solr?或者HBase不能用了,临时走KV集群?都不行。那个实现复杂度太高,不合适。

所以当时我们采取的方法就是,对最近一段时间用户发起的离线查询的请求日志进行收集,然后对请求日志在每天凌晨进行分析,分析出来那种每个用户会经常、多次、高频发起的冷数据查询请求,然后对这个特定的查询(比如特殊的一组条件,时间范围,维度组合)对应的结果,进行缓存。

这样就直接把各个用户高频发起的冷数据查询请求的结果每天动态分析,动态放入缓存集群中。比如有的用户每天都会看一下上周一周的数据分析结果,或者上个月一个月的数据分析结果,那么就可以把这些结果提前缓存起来。

一旦ES、HBase等集群故障,直接对外冷数据查询,仅仅提供这些提前缓存好的高频查询即可,非高频无缓存的查询结果,就是看不到了。

亿级流量系统架构之如何设计全链路99.99%高可用架构

七、最终总结

上述系统到目前为止,已经演进到非常不错的状态了,因为这套架构已经解决了百亿流量高并发写入,海量数据存储,高性能计算,高并发查询,高可用保障,等一系列的技术挑战。线上生产系统运行非常稳定,足以应对各种生产级的问题。

其实再往后这套系统架构还可以继续演进,因为大型系统的架构演进,可以持续N多年,比如我们后面还有分布式系统全链路数据一致性保障、高稳定性工程质量保障,等等一系列的事情,不过文章就不再继续写下去了,因为文章承载内容量太少,很难写清楚所有的东西。

其实有不少同学跟我反馈说,感觉看不懂这个架构演进系列的文章,其实很正常,因为文章承载内容较少,这里有大量的细节性的技术方案和落地的实施,都没法写出来,只能写一下大型系统架构不断演进,解决各种线上技术挑战的一个过程。

我觉得对于一些年轻的同学,主要还是了解一下系统架构演进的过程,对于一些年长已经做架构设计的兄弟,应该可以启发一些思路。

来源:掘金 原文:https://juejin.im/entry/5c0085276fb9a049a5709fce



Tags:系统架构   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
一:业务背景优惠券是电商常见的营销手段,具有灵活的特点,既可以作为促销活动的载体,也是重要的引流入口。优惠券系统是vivo商城营销模块中一个重要组成部分,早在15年vivo商城还是...【详细内容】
2021-08-06  Tags: 系统架构  点击:(74)  评论:(0)  加入收藏
昨天有网友问我,他原先没有学过奥数,问能不能当系统架构师?其他也有人有疑问,是不是应该先学数学,然后在考研的时候转入计算机? 我先说一下结论,没有学过奥数,完全可以当系统架构师...【详细内容】
2021-03-09  Tags: 系统架构  点击:(233)  评论:(0)  加入收藏
UML对系统架构的定义是:系统的组织结构,包括系统分解的组成部分,它们的关联性,交互,机制和指导原则,例如对系统群就是定义各子系统的功能和职责,如贷款系统群可能分为进件申请、核...【详细内容】
2021-02-24  Tags: 系统架构  点击:(164)  评论:(0)  加入收藏
分布式理论知识1、分布式系统架构1.1基础概念分布式 : 将一个单体项目分成很多个模块,各个模块协同工作,各个模块构成了分布式系统集群:针对单个模块或者单个系统在多台服务器上...【详细内容】
2021-01-28  Tags: 系统架构  点击:(111)  评论:(0)  加入收藏
由于多年前开发了一款聊天软件,今天朋友给我打电话,说他们公司准备开发一款内部使用的沟通交流工具,找我咨询关于即时聊天软件一些经验,于是跟他聊了一些关于这方面的东西,所以在...【详细内容】
2020-12-22  Tags: 系统架构  点击:(284)  评论:(0)  加入收藏
搭建自己的DNS服务器是一个很常见的诉求,尤其是在公司内部。Linux下架设DNS服务器通常是使用BIND程序来实现,BIND是美国加利福尼亚大学伯克利分校开发的软件,是一套域名服务器...【详细内容】
2020-10-15  Tags: 系统架构  点击:(104)  评论:(0)  加入收藏
一、数据仓库体系架构公司借助的第三方数据平台,在此平台之上建设数据仓库。因为第三方平台集成了很多东西,所以省去了不少功夫。数据仓库的体系架构,无外乎就是数据源、数据采...【详细内容】
2020-10-04  Tags: 系统架构  点击:(1002)  评论:(0)  加入收藏
在数字化革命和AI赋能的大背景下,推荐场景逻辑越来越复杂,推荐细分场景越来越丰富,对业务迭代和效果优化的效率有了更高的要求。推荐系统业务和技术在传统架构支撑下自然堆砌,变...【详细内容】
2020-09-07  Tags: 系统架构  点击:(86)  评论:(0)  加入收藏
目前,各专业领域复杂系统在设计过程中,都会面临功能、性能、可靠性以及研发周期等问题,而基于传统的人工方案设计方法,使得文档、模型传递及更新迭代难度加大,同时耗时耗力。世冠...【详细内容】
2020-08-17  Tags: 系统架构  点击:(174)  评论:(0)  加入收藏
接着文章「系统架构」如何使用Dockerfile制作Docker容器?(1)我们继续介绍ENV、ARG、VOLUME、EXPOSE、WORKDIR、USER、HEALTHCHECK、ONBUILD几个命令。7、ENV这个指令很简单,就...【详细内容】
2020-08-16  Tags: 系统架构  点击:(77)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条