亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？【石杉的架构笔记】

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

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

1、写在前面

以前更新过一个“亿级流量系统架构”系列，主要讲述了一个大规模商家数据平台的以下几个方面：

• 如何承载百亿级数据存储
• 如何设计高容错的分布式架构
• 如何设计承载百亿流量的高性能架构
• 如何设计每秒数十万并发查询的高并发架构
• 如何设计全链路99.99%高可用架构。

接下来，咱们将会继续经过几篇文章，对这套系统的可扩展架构、数据一致性保障等方面进行探讨。

若是没看过本系列文章的同窗能够先回过头看看以前写的几篇文章：

亿级流量系统架构

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

2、背景回顾

若是你们看过以前的一系列文章，应该依稀还记得上一篇文章最后，整个系统架构大体演进到了以下图的一个状态。

若是没看过以前的系列文章，上来猛一看下面这个图，绝对一脸懵逼，就看到一片“花花绿绿”。这个也没办法，复杂的系统架构都是特别的庞杂的。

3、实时计算平台与数据查询平台之间的耦合

好，我们正式开始！这篇文章我们来聊聊这套系统里的不一样子系统之间通讯过程的一个可扩展性的架构处理。

这里面蕴含了线上复杂系统之间交互的真实场景和痛点，相信对你们可以有所启发。

咱们就关注一下上面的架构图里左侧的部分，处于中间位置的那个实时计算平台在完成了每个数据分片的计算事后，都会将计算结果写入到最左侧的数据查询平台中。

出于种种考量，由于计算结果的数据量相比于原始数据的数据量，实际上已经少了一个数量级了。

因此，咱们选择的是实时计算平台直接将数据写入到数据查询平台的MySQL数据库集群中，而后数据查询平台基于MySQL数据库集群来对外提供查询请求。

此外，为了保证当天的实时计算结果可以高并发的被用户查询，所以当时采起的是实时计算平台的计算结果同时双写缓存集群和数据库集群。

这样，数据查询平台能够优先走缓存集群，若是找不到缓存才会从数据库集群里回查数据。

因此上述就是实时计算平台与数据查询平台之间在某一个时期的一个典型的系统耦合架构。

两个不一样的系统之间，经过同一套数据存储（数据库集群+缓存集群）进行了耦合。

你们看看下面的图，再来清晰的感觉一下系统之间耦合的感受。

系统耦合痛点1：被动承担的高并发写入压力

你们若是仔细看过以前的系列文章，大概就该知道，在早期主要是集中精力对实时计算平台的架构作了大量的演进，以便于让他能够支撑超高并发写入、海量数据的超高性能计算，最后就能够抗住每秒数万甚至数十万的数据涌入的存储和计算。

可是由于早期采用了上图的这种最简单、最高效、最实用的耦合交互方式，实时计算平台直接把每一个数据分片计算完的结果写入共享存储中，就致使了一个很大的问题。

实时计算平台能抗住超高并发写入没问题了，并且还能快速的高性能计算也没问题。

可是，他同时会随着数据量的增加，愈来愈高并发的将计算结果写入到一个数据库集群中。而这个数据库集群在团队划分的时候，其实是交给数据查询平台团队来负责维护的。

也就是说，对实时计算平台团队来讲，他们是不care那个数据库集群是什么状态的，而就是不停的把数据写入到那个集群里去。

可是，对于数据查询平台团队来讲，他们就会被动的承担实时计算平台愈来愈高并发压力写入的数据。

这个时候数据查询平台团队的同窗极可能处于这样的一种焦躁中：原本本身这块系统也有不少架构上的改进点要作，好比说以前提到的冷数据查询引擎的自研。

可是呢，他们却要不停的被线上数据库服务器的报警搞的焦头烂额，疲于奔命。

由于数据库服务器单机写入压力可能随着业务增加，迅速变成每秒5000~6000的写入压力，天天到了高峰期，线上服务器的CPU、磁盘、IO、网络等压力巨大，报警频繁。

此时数据查询平台团队的架构演进节奏就会被打乱，由于必须被动的去根据实时计算平台的写入压力来进行调整，必须立马停下手中的工做，而后去考虑如何对数据库集群作分库分表的方案，如何对表进行扩容，如何对库进行扩容。

同时结合分库分表的方案，数据查询平台自身的查询机制又要跟着一块儿改变，大量的改造工做，调研工做，数据迁移工做，上线部署工做，代码改造工做。

实际上，上面说的这种状况，绝对是不合理的。

由于整个这套数据平台是一个大互联网公司里核心业务部门的一个核心系统，他是数十个Java工程师与大数据工程师通力合做一块儿开发，并且里面划分为了多个team。

好比说数据接入系统是一个团队负责，实时计算平台是一个团队负责，数据查询平台是一个团队负责，离线数据仓库是一个团队负责，等等。

因此只要分工合做了之后，那么就不该该让一个团队被动的去承担另一个团队猛然增加的写入压力，这样会打破每一个团队本身的工做节奏。

致使这个问题的根本缘由，就是由于两个系统间，没有作任何解耦的处理。

这就致使数据查询平台团队根本没法对实时计算平台涌入过来的数据作任何有效的控制和管理，这也致使了“被动承担高并发写入压力”问题的发生。

这种系统耦合致使的被动高并发写入压力还不仅是上面那么简单，实际在上述场景中，线上生产环境还发生过各类奇葩的事情：

某一次线上忽然产生大量的热数据，热数据计算结果涌入数据查询平台，由于没作任何管控，几乎一瞬间致使某台数据库服务器写入并发达到1万+，DBA焦急的担忧数据库快宕机了，全部人也都被搞的焦头烂额，心理崩溃。

系统耦合痛点2：数据库运维操做致使的线上系统性能剧烈抖动

在这种系统耦合的场景下，反过来实时计算平台团队的同窗其实内心也会呐喊：咱们内心也苦啊！

由于反过来你们能够思考一下，线上数据库中的表结构改变，那几乎能够说是再正常不过了，尤为是高速迭代发展中的业务。

需求评审会上，要是不当心碰上某个产品经理，今天改需求，明天改需求。工程师估计会怒火冲天的想要砍人。可是没办法，最后仍是得为五斗米折腰，该改的需求仍是得改。该改的表结构也仍是要改，改加的索引也仍是要加。

可是你们考虑一个点，若是说对上述这种强耦合的系统架构，单表基本都是在千万级别的数据量，同时还有单台数据库服务器每秒几千的写入压力。

在这种场景下，在线上走一个MySQL的DDL语句试一试？奉劝你们千万别胡乱尝试，由于数据查询团队里的年轻同窗，干过这个事儿。

实际的结果就是，DDL咔嚓一执行，对线上表结构进行修改，直接致使实时计算平台的写入数据库的性能急剧降低10倍以上。。。

而后连带致使实时计算平台的数据分片计算任务大量的延迟。再而后，由于实时计算以后的数据没法尽快反馈到存储中，没法被用户查询到，致使了大量的线上投诉。

而且，DDL语句执行的还特别的慢，耗时数十分钟才执行完毕，这就致使数十分钟里，整套系统出现了大规模的计算延迟，数据延迟。

一直到数十分钟以后DDL语句执行完毕，实时计算平台才经过自身的自动延迟调度恢复机制慢慢恢复了正常的计算。

orz......因而今后以后，数据查询平台的攻城狮，必须得当心翼翼的在天天凌晨2点~3点之间进行相关的数据库运维操做，避免影响线上系统的性能稳定性。

可是，难道人家年轻工程师没有女友？难道年长工程师没有老婆孩子？常常在凌晨3点看看窗外的风景，而后打个滴滴回家，估计没任何人愿意。

其实上述问题，说白了，仍是由于两套系统直接经过存储耦合在了一块儿，致使了任何一个系统只要有点异动，直接就会影响另一个系统。耦合！耦合！仍是耦合！

系统耦合痛点N。。。

其实上面只不过是挑了其中两个系统耦合痛点来讲明而已，文章篇幅有限，很难把上述长达数月的耦合状态下的各类痛点一一说明，实际线上生产环境的痛点还包括不限于：

• 实时计算平台自身写入机制有bug致使的数据丢失，结果让数据查询平台的同窗去排查；

• 实时计算平台对缓存集群和数据库集群进行双写的时候，双写一致性的保证机制，竟然还须要本身来实现，直接致使本身的代码里混合了大量不属于本身的业务逻辑；

• 数据查询平台有时候作了分库分表运维操做以后，好比扩容库和表，竟然还得让实时计算平台的同窗配合着一块儿修改代码配置，一块儿测试和部署上线

• 数据查询平台和实时计算平台两个team的同窗在上述大量耦合场景下，常常每天一块儿加班到凌晨深夜，各自的女友都觉得他们打算在一块儿了，但实际状况是一堆大老爷儿们每天被搞的焦头烂额，苦不堪言，都不肯意多看对方一眼

• 由于系统耦合致使的各类问题，两个team都要抽时间精力来解决，影响了本身那套系统的架构演进进度，无法集中人力和时间作真正有价值和意义的事情

4、下集预告

下一篇文章，咱们就来聊一聊针对这些痛点，如何灵活的运用MQ消息中间件技术来进行复杂系统之间的解耦，同时解耦事后如何来自行对流量数据进行管控，解决各类系统耦合的问题。

敬请期待：

• 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？
• 亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？

END

若有收获，请帮忙转发，您的鼓励是做者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

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

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

推荐阅读：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1五、亿级流量系统架构之如何设计每秒十万查询的高并发架构

1六、亿级流量系统架构之如何设计全链路99.99%高可用架构

1七、七张图完全讲清楚ZooKeeper分布式锁的实现原理

1八、大白话聊聊Java并发面试问题之volatile究竟是什么？

1九、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？

20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？

2一、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？

2二、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化

2三、互联网公司的面试官是如何360°无死角考察候选人的？（上篇）

2四、互联网公司面试官是如何360°无死角考察候选人的？（下篇）

2五、Java进阶面试系列之一：哥们，大家的系统架构中为何要引入消息中间件？

2六、【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？

2七、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历

2八、【Java进阶面试系列之三】哥们，消息中间件在大家项目里是如何落地的？

2九、【Java进阶面试系列之四】扎心！线上服务宕机时，如何保证数据100%不丢失？

30、一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！

3一、【高并发优化实践】10倍请求压力来袭，你的系统会被击垮吗？

3二、【Java进阶面试系列之五】消息中间件集群崩溃，如何保证百万生产数据不丢失？

做者：石杉的架构笔记 连接：https://juejin.im/post/5c1e51fd6fb9a049a81f4f35 来源：掘金 著做权归做者全部，转载请联系做者得到受权