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

来自：石杉的架构笔记
一、前情回顾上篇文章（《亿级流量系统架构之如何设计每秒十万查询的高并发架构》），聊了一下系统架构中的查询平台。
我们采用冷热数据分离：

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

最终，整套查询架构抗住每秒10万的并发查询请求，都没问题。
本文作为这个架构演进系列的最后一篇文章，我们来聊聊高可用这个话题。所谓的高可用是啥意思呢？
简单来说，就是如此复杂的架构中，任何一个环节都可能会故障，比如MQ集群可能会挂掉、KV集群可能会挂掉、MySQL集群可能会挂掉。那你怎么才能保证说，你这套复杂架构中任何一个环节挂掉了，整套系统可以继续运行？
这就是所谓的全链路99.99%高可用架构，因为我们的平台产品是付费级别的，付费级别，必须要为客户做到最好，可用性是务必要保证的！
我们先来看看目前为止的架构是长啥样子的。

文章插图
二、MQ集群高可用方案异步转同步 + 限流算法 + 限制性丢弃流量
MQ集群故障其实是有概率的，而且挺正常的，因为之前就有的大型互联网公司，MQ集群故障之后，导致全平台几个小时都无法交易，严重的会造成几个小时公司就有数千万的损失。我们之前也遇到过MQ集群故障的场景，但是并不是这个系统里。
大家想一下，如果这个链路中，万一MQ集群故障了，会发生什么？
看看右上角那个地方，数据库binlog采集中间件就无法写入数据到MQ集群了啊，然后后面的流控集群也无法消费和存储数据到KV集群了。这套架构将会彻底失效，无法运行。
这个是我们想要的效果吗？那肯定不是的，如果是这样的效果，这个架构的可用性保障也太差了。
因此在这里，我们针对MQ集群的故障，设计的高可用保障方案是：异步转同步 + 限流算法 + 限制性丢弃流量。
简单来说，数据库binlog采集环节一旦发现了MQ集群故障，也就是尝试多次都无法写入数据到MQ集群，此时就会触发降级策略。不再写入数据到MQ集群，而是转而直接调用流控集群提供的备用流量接收接口，直接发送数据给流控集群。
但是流控集群也比较尴尬，之前用MQ集群就是削峰的啊，高峰期可以稍微积压一点数据在MQ集群里，避免流量过大，冲垮后台系统。
所以流控集群的备用流量接收接口，都是实现了限流算法的，也就是如果发现一旦流量过大超过了阈值，直接采取丢弃的策略，抛弃部分流量。
但是这个抛弃部分流量也是有讲究的，你要怎么抛弃流量？如果你不管三七二十一，胡乱丢弃流量，可能会导致所有的商家看到的数据分析结果都是不准确的。因此当时选择的策略是，仅仅选择少量商家的数据全量抛弃，但是大部分商家的数据全量保存。
也就是说，比如你的平台用户有20万吧，可能在这个丢弃流量的策略下，有2万商家会发现看不到今天的数据了，但是18万商家的数据是不受影响，都是准确的。但是这个总比20万商家的数据全部都是不准确的好吧，所以在降级策略制定的时候，都是有权衡的。
这样的话，在MQ集群故障的场景下，虽然可能会丢弃部分流量，导致最终数据分析结果有偏差，但是大部分商家的数据都是正常的。
大家看看下面的图，高可用保障环节全部选用浅红色来表示，这样很清晰。

文章插图
三、KV集群高可用保障方案临时扩容Slave集群 + 内存级分片存储 + 小时级数据粒度
下一个问题，如果KV集群挂了怎么办？这个问题我们还真的遇到过，不过也不是在这个系统里，是在另外一个我们负责过的核心系统里，KV集群确实出过故障，直接从持续好多个小时，导致公司业务都几近于停摆，损失也是几千万级别的。
大家看看那个架构图的右侧部分，如果KV集群挂了咋办？那也是灾难性的，因为我们的架构选型里，直接就是基于kv集群来进行海量数据存储的，要是KV挂了，没任何高可用保障措施的话，会导致流控集群无法把数据写入KV集群，此时后续环节就无法继续计算了。
我们当时考虑过要不要引入另外一套存储进行双写，比如引入一套hbase集群，但是那样依赖会搞的更加的复杂，打铁还需自身硬，还是要从自身架构来做优化。