上篇文章（《亿流量大考（3）：不加机器，如何抗住每天百亿级高并发流量？》）聊了一下系统架构中，百亿流量级别高并发写入场景下，如何承载这种高并发写入，同时如何在高并发写入的背景下还能保证系统的超高性能计算。
这篇文章咱们继续来聊一下，百亿级别的海量数据场景下还要支撑每秒十万级别的高并发查询，这个架构该如何演进和设计？
咱们先来看看目前系统已经演进到了什么样的架构，大家看看下面的图：
首先回顾一下，整个架构右侧部分演进到的那个程度，其实已经非常的不错了，因为百亿流量，每秒十万级并发写入的场景，使用MQ限流削峰、分布式KV集群给抗住了。
接着使用了计算与存储分离的架构，各个Slave计算节点会负责提取数据到内存中，基于自研的SQL内存计算引擎完成计算。同时采用了数据动静分离的架构，静态数据全部缓存，动态数据自动提取，保证了尽可能把网络请求开销降低到最低。
另外，通过自研的分布式系统架构，包括数据分片和计算任务分布式执行、弹性资源调度、分布式高容错机制、主备自动切换机制，都能保证整套系统的任意按需扩容，高性能、高可用的的运行。
下一步，咱们来研究研究架构里的左侧部分
其实大家会注意到，在左侧还有一个MySQL，那个MySQL就是用来承载实时计算结果和离线计算结果放在里面汇总的。
终端的商家用户就可以随意的查询MySQL里的数据分析结果，支撑自己的决策，他可以看当天的数据分析报告，也可以看历史上任何一段时期内的数据分析报告。
但是那个MySQL在早期可能还好一些，因为其实存放在这个MySQL里的数据量相对要小一些，毕竟是计算后的一些结果罢了。但是到了中后期，这个MySQL可是也岌岌可危了。
给大家举一个例子，离线计算链路里，如果每天增量数据是1000万，那么每天计算完以后的结果大概只有50
