同事老是吐槽我的接口性能差，原来真凶就在这里！

一、前情回顾

上篇文章：《为什么每个程序员都必须坚持写博客？这篇文章教你怎么写！》聊了一下系统架构中，百亿流量级别高并发写入场景下，如何承载这种高并发写入，同时如何在高并发写入的背景下还能保证系统的超高性能计算。

这篇文章咱们继续来聊一下，百亿级别的海量数据场景下还要支撑每秒十万级别的高并发查询，这个架构该如何演进和设计？

咱们先来看看目前系统已经演进到了什么样的架构，大家看看下面的图：

首先回顾一下，整个架构右侧部分演进到的那个程度，其实已经非常的不错了，因为百亿流量，每秒十万级并发写入的场景，使用MQ限流削峰、分布式KV集群给抗住了。

接着使用了计算与存储分离的架构，各个Slave计算节点会负责提取数据到内存中，基于自研的SQL内存计算引擎完成计算。同时采用了数据动静分离的架构，静态数据全部缓存，动态数据自动提取，保证了尽可能把网络请求开销降低到最低。

另外，通过自研的分布式系统架构，包括数据分片和计算任务分布式执行、弹性资源调度、分布式高容错机制、主备自动切换机制，都能保证整套系统的任意按需扩容，高性能、高可用的的运行。

下一步，咱们来研究研究架构里的左侧部分

---

二、日益膨胀的离线计算结果

其实大家会注意到，在左侧还有一个MySQL，那个MySQL就是用来承载实时计算结果和离线计算结果放在里面汇总的。

终端的商家用户就可以随意的查询MySQL里的数据分析结果，支撑自己的决策，他可以看当天的数据分析报告，也可以看历史上任何一段时期内的数据分析报告。

但是那个MySQL在早期可能还好一些，因为其实存放在这个MySQL里的数据量相对要小一些，毕竟是计算后的一些结果罢了。但是到了中后期，这个MySQL可是也岌岌可危了。

---

给大家举一个例子，离线计算链路里，如果每天增量数据是1000万，那么每天计算完以后的结果大概只有50万，每天50万新增数据放入MySQL，其实还是可以接受的。

但是如果每天增量数据是10亿，那么每天计算完以后的结果大致会是千万级，你可以算他是计算结果有5000万条数据吧，每天5000万增量数据写入左侧的MySQL中，你觉得是啥感觉&