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

因此，当时选择的一套kv集群降级的预案是：临时扩容Slave集群 + 小时级数据粒度 + 内存级分片存储。
简单来说，就是一旦发现kv集群故障，直接报警。我们收到报警之后，就会立马启动临时预案，手动扩容部署N倍的Slave计算集群。
接着同样会手动打开流控集群的一个降级开关，然后流控集群会直接按照预设的hash算法分发数据到各个Slave计算节点。
这就是关键点，不要再基于kv集群存数据了，本身我们的Slave集群就是分布式计算的，那不是刚好可以临时用作分布式存储吗！直接流控集群分发数据到Slave集群就行了，Slave节点将数据留存在内存中即可。
然后Master节点在分发数据计算任务的时候，会保证计算任务分发到某个Slave节点之后，他只要基于本地内存中的数据计算即可。
将Master节点和Slave节点都重构一下，重构成本不会太高，但是这样就实现了本地数据存储 + 本地数据计算的效果了。
但是这里同样有一个问题，要知道当日数据量可是很大的！如果你都放Slave集群内存里还得了？
所以说，既然是降级，又要做一个balance了。我们选择的是小时级数据粒度的方案，也就是说，仅仅在Slave集群中保存最近一个小时的数据，然后计算数据指标的时候，只能产出每个小时的数据指标。
但是如果是针对一天的数据需要计算出来的数据指标，此时降级过后就无法提供了，因为内存中永远只有最近一个小时的数据，这样才能保证Slave集群的内存不会被撑爆。
对用户而言，就是只能看当天每个小时的数据指标，但是全天汇总的暂时就无法看到。

文章插图
四、实时计算链路高可用保障方案计算任务重分配 + 主备切换机制
下一块就是实时计算链路的高可用保障方案了，其实这个之前给大家说过了，实时计算链路是一个分布式的架构，所以要么是Slave节点宕机，要么是Master节点宕机。
其实这个倒没什么，因为Slave节点宕机，Master节点感知到了，会重新分配计算任务给其他的计算节点；如果Master节点宕机，就会基于Active-Standby的高可用架构，自动主备切换。
咱们直接把架构图里的实时计算链路中的高可用环节标成红色就可以了。

文章插图
五、热数据高可用保障方案自研缓存集群查询引擎 + JVM本地缓存 + 限流机制
接着咱们来看左侧的数据查询那块，热数据也就是提供实时计算链路写入当日数据的计算结果的，用的是MySQL集群来承载主体数据，然后前面挂载一个缓存集群。
如果出现故障，只有两种情况：一种是MySQL集群故障，一种是缓存集群故障。
咱们分开说，如果是MySQL集群故障，我们采取的方案是：实时计算结果直接写入缓存集群，然后因为没有MySQL支撑，所以没法使用SQL来从MySQL中组装报表数据。
因此，我们自研了一套基于缓存集群的内存级查询引擎，支持简单的查询语法，可以直接对缓存集群中的数据实现条件过滤、分组聚合、排序等基本查询语义，然后直接对缓存中的数据查询分析过后返回。
但是这样唯一的不好，就是缓存集群承载的数据量远远没有MySQL集群大，所以会导致部分用户看不到数据，部分用户可以看到数据。不过这个既然是降级，那肯定是要损失掉部分用户体验的。
【亿级流量系统架构之如何设计全链路99.99%高可用架构】如果是缓存集群故障，我们会有一个查询平台里的本地缓存，使用ehcache等框架就可以实现，从mysql中查出来的数据在查询平台的jvm本地缓存里cache一下，也可以用作一定的缓存支撑高并发的效果。而且查询平台实现限流机制，如果查询流量超过自身承载范围，就限流，直接对查询返回异常响应。

文章插图
六、冷数据高可用保障方案收集查询日志 + 离线日志分析 + 缓存高频查询
其实大家看上面的图就知道，冷数据架构本身就比比较复杂，涉及到ES、HBase等东西，如果你要是想做到一点ES、HBase宕机，然后还搞点儿什么降级方案，还是挺难的。
你总不能ES不能用了，临时走Solr？或者HBase不能用了，临时走KV集群？都不行。那个实现复杂度太高，不合适。
所以当时我们采取的方法就是，对最近一段时间用户发起的离线查询的请求日志进行收集，然后对请求日志在每天凌晨进行分析，分析出来那种每个用户会经常、多次、高频发起的冷数据查询请求，然后对这个特定的查询（比如特殊的一组条件，时间范围，维度组合）对应的结果，进行缓存。