1.写之前更新了一系列《亿级流量系统架构》，主要讲述了一个大规模商户数据平台的以下几个方面：如何承载百亿级数据存储，如何设计高容错的分布式架构，如何设计承载百亿级流量的高性能架构，如何设计一个每秒几十万并发查询的高并发架构，如何设计一个全局Link99.99%的高可用架构接下来我们将通过几篇文章继续探讨这个系统的可扩展架构和数据一致性保证.如果你还没有看过本系列文章，可以回去看看之前的几篇文章：亿级流量系统架构不要只看NB的Github开源项目，自己设计还得参考建筑学！为什么一些看起来很厉害的技术高手设计垃圾架构？为什么每个程序员都必须坚持写博客？这篇文章教你怎么写！同事们总是抱怨我的界面性能太差，那么真正的罪魁祸首就在这里！经历了2022年的裁员，总结出程序员必备的架构能力！2.背景回顾如果你看过前面的系列文章，你应该依稀记得在上一篇文章的最后，整个系统架构大致演化到了如下图所示的状态。如果你还没有看过之前的系列文章，上来快速浏览一下下图，你一定会惊呆了，你会看到一个“五光十色”。这个没办法，复杂的系统架构特别复杂。3、实时计算平台和数据查询平台耦合好，开始吧！在这篇文章中，我们将讨论本系统中不同子系统之间的通信过程的可扩展架构处理。包含了在线复杂系统交互的真实场景和痛点，相信能对大家有所启发。让我们关注上面架构图的左侧部分。中间的实时计算平台在完成每个数据切片的计算后，会将计算结果写入最左边的数据查询平台。由于各方面的考虑，计算结果的数据量实际上比原始数据的数据量少了一个数量级。因此，我们选择实时计算平台直接将数据写入数据查询平台的MySQL数据库集群，数据查询平台基于MySQL数据库集群提供查询请求。另外，为了保证当天的实时计算结果可以被高并发用户查询，实时计算平台的计算结果同时双写到缓存集群和数据库集群。这样数据查询平台就可以先到缓存集群上去，如果找不到缓存，只从数据库集群中查询数据。所以以上是一定时期内实时计算平台和数据查询平台之间典型的系统耦合架构。两个不同的系统通过同一套数据存储（数据库集群+缓存集群）耦合在一起。看看下图，就可以清楚地感受到系统之间的耦合。系统耦合痛点一：被动高并发写入压力。如果你仔细看过前面的系列文章，你应该知道，在早期，你主要专注于对实时计算平台的架构进行大量的演进，使他们能够进行超高性能计算可以支持超高并发写入和海量数据，最后是可以抵抗每秒几万甚至几十万数据涌入的存储和计算。但由于前期采用了上图最简单、最高效、最实用的耦合交互方式，实时计算平台直接将每个数据切片的计算结果写入共享存储，从而导致大问题。实时计算平台承受超高并发写入没问题，快速高性能计算也没问题。但与此同时，随着数据量的增长，越来越多的并发将计算结果写入数据库集群。这个数据库集群在分队的时候，其实是交给了数据查询平台团队负责维护。也就是说，对于实时计算平台团队来说，他们并不关心数据库集群的状态，只是不停地向那个集群写入数据。而对于数据查询平台团队来说，他们将被动承担实时计算平台写入的数据，并发压力越来越大。这时候数据查询平台组的同学很可能会处于这样一种焦虑状态：这个系统还有很多架构需要改进，比如前面提到的冷数据查询引擎的自研.然而，他们不得不被来自在线数据库服务器的警报压得喘不过气来。因为随着业务的增长，数据库服务器单机写压力可能会迅速变成每秒5000~6000次写压力。每天高峰期，在线服务器的CPU、磁盘、IO、网络等都承受着巨大的压力，告警频繁。这时候数据查询平台团队的架构演进节奏就会被打乱，因为要根据实时计算平台的写压力被动调整，手头的工作马上要停下来，然后考虑如何划分数据库集群。数据库分表的方案，表怎么扩，数据库怎么扩。同时，结合分库分表的方案，数据查询平台本身的查询机制也要一起改变，大量的改造工作，调研工作，数据迁移工作，上线部署工作，和代码转换工作。其实上面说的情况是绝对不合理的。因为整个数据平台是一个大型互联网公司核心业务部门的一个核心系统，是由几十个Java工程师和大数据工程师合作开发的，分成多个团队。比如一个团队负责数据接入系统，一个团队负责实时计算平台，一个团队负责数据查询平台，一个团队负责离线数仓等等。所以只要有分工合作，就不能让一个团队被动承担另一个团队突然增加的写作压力，这样会打乱各个团队的工作节奏。这个问题的根本原因是两个系统之间没有解耦。因此，数据查询平台团队无法对从实时计算平台涌入的数据做任何有效的控制和管理，也导致了“被动承受高并发写入压力”问题的出现。这种系统耦合造成的被动高并发写压力，并没有上面这么简单。事实上，在上述场景中，在线生产环境中发生了各种奇怪的事情：在线上突然产生了大量的热点数据，这些热点数据的数据计算结果涌入了数据查询平台。因为没有控制，某台数据库服务器的并发写入几乎是瞬间就达到了10000+。DBA焦急地担心数据库很快就会宕机，大家应接不暇。精神崩溃。系统耦合痛点二：数据库运维操作导致线上系统性能剧烈抖动。在这种系统耦合的场景下，实时计算平台组的同学们其实在心里呐喊：我们也是苦啊！因为另一方面，你可以考虑一下。线上数据库的表结构变化几乎是常态，尤其是对于高速迭代开发的业务。需求评审会上，不小心遇到了产品经理，今天改需求，明天再改需求。估计工程师会大发雷霆，想杀人。但是没有办法。到头来还是要为五斗??米折腰，该改的需求还是得改。该改的表结构还是要改，该改的索引还是要加。但是每个人都考虑一点。对于上述强耦合的系统架构，单张表基本有千万级别的数据量，同时单台数据库服务器有几千每秒的写入压力。这种场景，试一下在线运行一条MySQLDDL语句？奉劝大家不要胡乱尝试，因为之前数据查询组的年轻同学都这样做过。实际结果是，一旦执行DDL，在线表结构被修改，直接导致实时计算平台写入数据库的性能急剧下降10倍以上。..进而导致实时计算平台的数据分片计算任务出现大量延迟。随后，由于实时计算后的数据无法第一时间反馈到存储，用户无法查询，引发了大量网上投诉。而且DDL语句的执行速度极慢，需要几十分钟才能执行完毕，导致几十分钟内整个系统出现大规模的计算延迟和数据延迟。直到几十分钟后，DDL语句执行完毕，实时计算平台才通过自身的自动延时调度恢复机制慢慢恢复正常计算。orz...所以从现在开始，数据查询平台的攻城狮一定要在每天凌晨2点到3点之间认真进行相关的数据库运维操作，以免影响线上系统的性能稳定性。但是，这不是说年轻的工程师就没有女朋友吗？年长的工程师没有妻子和孩子吗？经常凌晨3点多看看窗外的风景，然后打车回家。我想没有人愿意。其实上面的问题，说白了就是因为两个系统通过存储直接耦合在一起，所以一个系统的任何变化都会直接影响到另一个系统。耦合！耦合！还是耦合的！系统耦合痛点N...其实以上只是为了说明其中两个系统的耦合痛点。文章篇幅有限，难以解释持续数月的耦合状态下的各种痛点。实际线上生产环境的痛点包括但不限于：实时计算平台自身写入机制BUG导致的数据丢失。因此要求数据查询平台的同学检查实时计算平台何时双写缓存集群和数据库集群。还是需要自己去实现，这直接导致自己的代码中混入了很多不属于自己的业务逻辑。有时数据查询平台会进行分库分表的运维操作，比如对数据库和表进行扩容。两个团队的同学共同修改代码配置，共同测试部署在线数据查询平台和实时计算平台。在上述大规模耦合场景中，两个团队的学生经常一起加班，每天凌晨加班到深夜。我们在一起，但实际情况是一帮老头子每天都在受着折磨，苦不堪言，因为系统耦合带来的各种问题，彼此看不上眼。两个团队都必须花费时间和精力来解决它们。自身系统架构演进进度，无法集中人力和时间去做真正有价值和有意义的事情
