亿级流量系统架构之如何设计承载百亿流量的高性能架构

一、往期回顾

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

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

 

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

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

给大家先说下当时的系统部署情况，数据库那块一共部署了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多个系统，这个