亿级流量系统架构之如何设计承载百亿流量的高性能架构【石杉的架构笔记】

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

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

1、往期回顾

上篇文章《大型系统架构演进之如何设计高容错分布式计算系统》，主要聊了一下将单块系统重构为分布式系统，以此来避免单台机器的负载太高。同时引伸出来了弹性资源调度、分布式容错机制等相关的东西。

这篇文章咱们继续来聊聊这个系统后续的重构演进过程，先来看下目前的系统架构图，一块儿来回顾一下。

2、百亿流量的高并发技术挑战

上篇文章说到，若是仅仅只是天天亿级流量的话，其实基本上目前的系统架构就足够支撑了，可是呢，咱们面临的可不只仅是亿级流量那么简单。咱们面对的是日益增多和复杂的各类业务系统，咱们面对的是不断增长的系统用户，咱们面对的是即将迎来天天百亿级的高并发流量。

给你们先说下当时的系统部署状况，数据库那块一共部署了8主8从，也就是16台数据库服务器，每一个库都是部署在独立的数据库服务器上的，并且所有用的是物理机，机器的配置，若是没记错的话，应该是32核+128G+SSD固态硬盘。

为啥要搞这么多物理机，并且所有都是高配置呢？不知道你们发现没有，目前为止，咱们最大的依赖就是MySQL！

以前给你们解释过，在当时的背景下，咱们要对涌入的亿级海量数据，实时的运行数百个复杂度为几百行到上千行的大SQL，几秒钟就要出分析结果。

这个是没有任何一个开源系统能够作到的，Storm不行，Spark Streaming也不行，所以必须得基于MySQL纯自研一套数据平台架构出来，支撑这个需求场景。

因此，只有MySQL是能够支撑如此复杂的SQL语句完美运行的，所以咱们在早期必须严重依赖于MySQL做为数据的存储和计算，将源源不断涌入的数据放在MySQL中进行存储，接着基于数据分片计算的架构来高性能的运行复杂大SQL基于MySQL来进行计算。

因此你们就知道了，MySQL目前为止是这套系统的命脉。在当时的场景下，每台数据库服务器都要抗住每秒2000左右的并发请求，高峰期的CPU负载、IO负载其实都很是高，并且主库和从库的延迟在高峰期已经有点严重，会达到秒级了。

在咱们的生产系统的实际线上运行状况下，单台MySQL数据库服务器，咱们通常是不会让他的高峰期并发请求超过2000/s的，由于一旦达到每秒几千的请求，根据当时线上的资源负载状况来看，极可能MySQL服务器负载太高会宕机。

因此此时就有一个很尴尬的问题了，假如说天天亿级流量的场景下，须要用8主8从这么多高配置的数据库服务器来抗，那若是是几十亿流量呢？甚至若是是百亿流量呢？难道不停的增长更多的高配置机器吗？

要知道，这种高配置的数据库服务器，若是是物理机的话，是很是昂贵的！

以前给你们简单介绍过项目背景，这整套大型系统组成的商业级平台，涉及到N多个系统，这个数据产品只是一个子产品而已，不可能为了这么一个产品，投入大量的预算经过不停的砸高配置的机器来撑住更高的并发写入。

咱们必须用技术的手段来重构系统架构，尽可能用有限的机器资源，经过最优秀的架构来抗住超高的并发写入压力！

3、计算与存储分离的架构

这个架构里的致命问题之一，就是数据的存储和计算混在了一个地方，都在同一个MySQL库里！

你们想一想，在一个单表里放上千万数据，而后你每次运行一个复杂SQL的时候，SQL里都是经过索引定位到表中他要计算的那个数据分片。这样搞合适吗？

答案显然是否认的！由于表里的数据量很大，可是你每次实际SQL运算只要对其中很小很小的一部分数据计算就能够了，实际上咱们在生产环境中实践事后发现，若是你在一个大表运行一个复杂SQL，哪怕经过各类索引保证定位到的数据量不多，由于表数据量过大，也是会致使性能直线降低的。

所以第一件事情，先将数据的存储和计算这两件事情拆开。

咱们当时的思路以下：

• 数据直接写入一个存储，仅仅只是简单的写入便可
• 而后在计算的时候从数据存储中提取你须要的那个数据分片里的可能就一两千条数据，写入另一个专用于计算的临时表中，那个临时表内就这一两千条数据
• 而后运行你的各类复杂SQL便可。

bingo！一旦将数据存储和计算两个事情拆开，架构里能够发挥的空间就大多了。

首先你的数据存储只要支撑高并发的写入，日百亿流量的话，高峰每秒并发会达到几十万，撑住这就能够了。而后支持计算引擎经过简单的操做从数据存储里提取少许数据就OK。

太好了，这个数据存储就能够PASS掉MySQL了，就这点儿需求，你还用MySQL干什么？兄弟！

当时咱们通过充分的技术调研和选型以后，选择了公司自研的分布式KV存储系统，这套KV存储系统是彻底分布式的，高可用，高性能，轻量级，支持海量数据，并且以前经历过公司线上流量的百亿级请求量的考验，绝对没问题。主要支持高并发的写入数据以及简单的查询操做，彻底符合咱们的需求。

这里给你们提一句，其实业内不少相似场景会选择hbase，因此你们若是没有公司自研的优秀kv存储的话，能够用选用hbase也是没问题的，只不过hbase有可能生产环境会有点坑，须要你们对hbase很是精通，合理避坑和优化。

轻量级的分布式kv系统，通常设计理念都是支持一些简单的kv操做，大量的依托于内存缓存热数据来支持高并发的写入和读取，由于不须要支持MySQL里的那些事务啊、复杂SQL啊之类的重量级的机制。

所以在同等的机器资源条件下，kv存储对高并发的支撑能力至少是MySQL的数倍甚至数十倍。

就比如说，你们应该都用过Redis，Redis普通配置的单机器撑个每秒几万并发都是ok的，其实就是这个道理，他很是的轻量级，转为高并发而生。

而后，咱们仍是能够基于MySQL中的一些临时表来存放kv存储中提取出来的数据分片，利用MySQL对复杂SQL语法的支持来进行计算就能够了。也就是说，咱们在这个架构里，把kv系统做为存储，把MySQL用作少许数据的计算。

此时咱们在系统架构中引入了分布式kv系统来做为咱们的数据存储，天天的海量数据都存放在这里就能够了，而后咱们的Slave计算引擎每次计算，都是根据那个数据分片从kv存储中提取对应的数据出来放入MySQL内的一个临时表，接着就是对那个临时表内的一两千条数据分片运行各类复杂SQL进行计算便可。

你们看上面的图，此时经过这一步计算与存储架构的分离，咱们选用了适合支撑高并发的kv集群来抗住天天百亿级的流量写入。而后基于MySQL做为临时表放入少许数据来进行运算。这一个步骤就直接把高并发请求能够妥妥的抗住了。

并且分布式kv存储原本就能够按需扩容，若是并发愈来愈高，只要扩容增长机器就能够了。此时，就完成了架构的一个关键的重构步骤。

4、自研纯内存SQL计算引擎

下一步，咱们就要对架构追求极致！由于此时咱们面临的一个痛点就在于说，其实仅仅只是将MySQL做为一个临时表来计算了，主要就是用他的复杂SQL语法的支持。

可是问题是，对MySQL的并发量虽然大幅度下降了，但是还并不算过低。由于大量的数据分片要计算，仍是须要频繁的读写MySQL。

此外，每次从kv存储里提取出来了数据，还得放到MySQL的临时表里，还得发送SQL去MySQL里运算，这仍是多了几个步骤的时间开销。

由于当时面临的另一个问题是，天天请求量大，意味着数据量大，数据量大意味着时间分片的计算任务负载仍是较重。

老是这么依赖MySQL，还要额外维护一大堆的各类临时表，可能多达几百个临时表，你要维护，要注意他的表结构的修改，还有分库分表的一些运维操做，这一切都让依赖MySQL这个事儿显得那么的多余和麻烦。

所以，咱们作出决定，为了让架构的维护性更高，并且将性能优化到极致，咱们要本身研发纯内存的SQL计算引擎。

其实若是你要自研一个能够支持MySQL那么复杂SQL语法的内存SQL计算引擎，仍是有点难度和麻烦的。可是在咱们仔细研究了业务须要的那几百个SQL以后，发现其实问题没那么的复杂。

由于其实通常的数据分析类的SQL，主要就是一些常见的功能，没有那么多的怪、难、偏的SQL语法。

所以咱们将线上的SQL都分析过一遍以后，就针对性的研发出了仅仅支持特定少数语法的SQL引擎，包括了嵌套查询组件、多表关联组件、分组聚合组件、多字段排序组件、少数几个经常使用函数，等等。

接着就将系统完全重构为再也不依赖MySQL，每次从kv存储中提取一个数据分片以后，直接放入内存中，而后用咱们自研的SQL计算引擎来在纯内存里针对一个数据分片执行各类复杂的SQL。

这个纯内存操做的性能，那就不用多说了，你们应该都能想象到了，基本上纯内存的SQL执行，都是毫秒级的，基本上一个时间分片的运算所有下降到毫秒级了。性能进一步获得了大幅度的提高，并且今后再也不依赖MySQL了，不须要维护复杂的分库分表等等东西。

这套架构上线以后，完全消除了对MySQL的依赖，理论上，不管多大的流量过来，均可以经过立马扩容kv集群以及扩容Slave计算集群来解决，不须要依赖MySQL的分库分表、几百张临时表等比较耗费人力、麻烦并且坑爹的方案了。并且这种纯内存的计算架构直接把计算性能提高到了毫秒级。

并且消除对MySQL的依赖有另一个好处，数据库的机器老是要高配置的，可是Slave机器主要4核8G的普通虚拟机就够了，分布式系统的本质就是尽可能利用大量的廉价普通机器就能够完成高效的存储和计算。

所以在百亿流量的负载之下，咱们Slave机器部署了几十台机器就足够了，那总比你部署几十台昂贵的高配置MySQL物理机来的划算多了！

5、MQ削峰以及流量控制

其实若是对高并发架构稍微了解点的同窗都会发现，这个系统的架构中，针对高并发的写入这块，还有一个比较关键的组件要加入，就是MQ。

由于咱们若是应对的是高并发的非实时响应的写入请求的话，彻底可使用MQ中间件先抗住海量的请求，接着作一个中间的流量分发系统，将流量异步转发到kv存储中去，同时这个流量分发系统能够对高并发流量进行控制。

好比说若是瞬时高并发的写入真的致使后台系统压力过大，那么就能够由流量分发系统自动根据咱们设定的阈值进行流量控制，避免高并发的压力打垮后台系统。

并且在这个流控系统中，咱们其实还作了不少的细节性的优化，好比说数据校验、过滤无效数据、切分数据分片、数据同步的幂等机制、100%保证数据落地到kv集群的机制保障，等等。

公司的MQ集群自然都支撑过大流量写入以及高并发请求，所以MQ集群那个层面抗住高并发并非什么问题，再高的并发按需扩容就能够了，而后咱们本身的流控系统也是集群部署的，线上采用的是4核8G的虚拟机，由于这个机器不须要过高的配置。

流控系统，基本线上咱们通常保持在每台机器承载每秒小三千左右的并发请求，百亿流量场景下，高峰每秒并发在每秒小几十万的级别，所以这个流控集群部署到几十台机器就足够了。

而公司的kv集群也是自然支撑过大流量高并发写入的，所以kv集群按需扩容，抗住高并发带流量的写入也不是什么问题，并且这里其实咱们由于在自身架构层面作了大量的优化（存储与计算分离的关键点），所以kv集群的定位基本就是online storage，一个在线存储罢了。

经过合理、巧妙的设计key以及value的数据类型，使得咱们对kv集群的读写请求都是优化成最最简单的key-value的读写操做，自然保证高并发读写是没问题的。

另外稍微给你们一点点的剧透，后面讲到全链路99.99%高可用架构的时候，这个流控集群会发挥巨大的做用，他是承上启下的一个效果，前置的MQ集群故障的高可用保障，以及后置的KV集群故障的高可用保障，都是依靠流控集群来实现的。

6、数据的动静分离架构

在完成上述重构以后，咱们又对核心的自研内存SQL计算引擎作了进一步的优化。由于实际生产环境运行过程当中，咱们发现了一个问题：就是每次若是Slave节点都是对一个数据分片提取相关联的各类数据出来而后进行计算，实际上是不必的！

给你们举个例子，若是你的SQL要对一些表进行关联计算，里面涉及到了一些大部分时候静态不变的数据，那些表的数据通常不多改变，所以不必每次都走网络请求从kv存储里提取那部分数据。

咱们其实彻底能够在Slave节点对这种静态数据作个轻量级的cache，而后只有数据分片里对应的动态改变的数据才从kv存储来提取数据。

经过这个数据的动静分离架构，咱们基本上把Slave节点对kv集群的网络请求下降到了最少，性能提高到了最高。你们看下面的图。

7、阶段性总结

这套架构到此为止，基本上就演进的比较不错了，由于超高并发写入、极速高性能计算、按需任意扩容，等各类特性均可以支持到了，基本上从写入到计算，这两个步骤，是没什么太大的瓶颈了。

并且经过自研内存SQL计算引擎的方案，将咱们的实时计算性能提高到了毫秒级的标准，基本已经达到极致。

8、下一步展望

下一步，咱们就要看看这个架构中的左侧，还有一个MySQL呢！

首先是实时计算链路和离线计算链路，都会导入大量的计算结果到那个MySQL中。

其次面向数十万甚至上百万的B端商家时，若是是实时展现数据分析结果的话，通常页面上会有定时的JS脚本，每隔几秒钟就会发送请求过来加载最新的数据计算结果。

所以实际上那个专门面向终端用户的MySQL也会承受极大的数据量的压力，高并发写入的压力以及高并发查询的压力。

下一篇文章，咱们就聊聊《大型系统架构演进之如何设计每秒数十万查询的高并发架构》，将左侧最后剩下的那个MySQL给完全重构掉。

END

亿级流量架构专栏：

• 亿级流量系统架构之如何支撑百亿级数据的存储与计算
• 亿级流量系统架构之如何设计高容错分布式计算系统
• 亿级流量系统架构之如何设计承载百亿流量的高性能架构【敬请期待】
• 亿级流量系统架构之如何设计每秒数十万查询的高并发架构【敬请期待】
• 亿级流量系统架构之如何设计全链路99.99%高可用架构【敬请期待】

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

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

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

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

推荐阅读：

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

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

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

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

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

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

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

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

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

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

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

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

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