亿级流量系统架构之如何设计全链路99.99%高可用架构【石杉的架构笔记】

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）

周一至周五早8点半！精品技术文章准时送上！

1、前情回顾

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

咱们采用冷热数据分离：

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

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

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

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

这就是所谓的全链路99.99%高可用架构，由于咱们的平台产品是付费级别的，付费级别，必需要为客户作到最好，可用性是务必要保证的！

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

2、MQ集群高可用方案

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

MQ集群故障实际上是有几率的，并且挺正常的，由于以前就有的大型互联网公司，MQ集群故障以后，致使全平台几个小时都没法交易，严重的会形成几个小时公司就有数千万的损失。咱们以前也遇到过MQ集群故障的场景，可是并非这个系统里。

你们想一下，若是这个链路中，万一MQ集群故障了，会发生什么？

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

这个是咱们想要的效果吗？那确定不是的，若是是这样的效果，这个架构的可用性保障也太差了。

所以在这里，咱们针对MQ集群的故障，设计的高可用保障方案是：异步转同步 + 限流算法 + 限制性丢弃流量。

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

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

因此流控集群的备用流量接收接口，都是实现了限流算法的，也就是若是发现一旦流量过大超过了阈值，直接采起丢弃的策略，抛弃部分流量。

可是这个抛弃部分流量也是有讲究的，你要怎么抛弃流量？若是你无论三七二十一，胡乱丢弃流量，可能会致使全部的商家看到的数据分析结果都是不许确的。所以当时选择的策略是，仅仅选择少许商家的数据全量抛弃，可是大部分商家的数据全量保存。

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

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

你们看看下面的图，高可用保障环节所有选用浅红色来表示，这样很清晰。

3、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集群的内存不会被撑爆。

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

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

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

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

其实这个倒没什么，由于Slave节点宕机，Master节点感知到了，会从新分配计算任务给其余的计算节点；若是Master节点宕机，就会基于Active-Standby的高可用架构，自动主备切换。

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

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

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

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

若是出现故障，只有两种状况：一种是MySQL集群故障，一种是缓存集群故障。

我们分开说，若是是MySQL集群故障，咱们采起的方案是：实时计算结果直接写入缓存集群，而后由于没有MySQL支撑，因此无法使用SQL来从MySQL中组装报表数据。

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

可是这样惟一的很差，就是缓存集群承载的数据量远远没有MySQL集群大，因此会致使部分用户看不到数据，部分用户能够看到数据。不过这个既然是降级 ，那确定是要损失掉部分用户体验的。

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

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

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

其实你们看上面的图就知道，冷数据架构自己就比比较复杂，涉及到ES、HBase等东西，若是你要是想作到一点ES、HBase宕机，而后还搞点儿什么降级方案，仍是挺难的。

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

因此当时咱们采起的方法就是，对最近一段时间用户发起的离线查询的请求日志进行收集，而后对请求日志在天天凌晨进行分析，分析出来那种每一个用户会常常、屡次、高频发起的冷数据查询请求，而后对这个特定的查询（好比特殊的一组条件，时间范围，维度组合）对应的结果，进行缓存。

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

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

7、最终总结

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

其实再日后这套系统架构还能够继续演进，由于大型系统的架构演进，能够持续N多年，好比咱们后面还有分布式系统全链路数据一致性保障、高稳定性工程质量保障，等等一系列的事情，不过文章就再也不继续写下去了，由于文章承载内容量太少，很难写清楚全部的东西。

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

我以为对于一些年轻的同窗，主要仍是了解一下系统架构演进的过程，对于一些年长已经作架构设计的兄弟，应该能够启发一些思路，欢迎公众号后台给我留言，探讨这些技术问题。

END

一大波微服务、分布式、高并发、高可用的原创系列

文章正在路上,欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授

推荐阅读：

一、拜托！面试请不要再问我Spring Cloud底层原理

二、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？

三、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战

四、微服务架构如何保障双11狂欢下的99.99%高可用

五、兄弟，用大白话告诉你小白都能听懂的Hadoop架构原理

六、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问

七、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍

八、拜托，面试请不要再问我TCC分布式事务的实现原理坑爹呀！

九、【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？

十、拜托，面试请不要再问我Redis分布式锁的实现原理！

十一、【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提高10倍以上？

十二、亿级流量系统架构之如何支撑百亿级数据的存储与计算

1三、亿级流量系统架构之如何设计高容错分布式计算系统

1四、亿级流量系统架构之如何设计承载百亿流量的高性能架构

1五、亿级流量系统架构之如何设计每秒十万查询的高并发架构