亿级流量系统架构之如何设计高容错分布式计算系统【石杉的架构笔记】

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

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

亿级流量架构专栏：

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

1、写在前面

上篇文章《大型系统架构演进之如何支撑百亿级数据的存储与计算》，聊了一下商家数据平台第一个阶段的架构演进。经过离线与实时计算链路的拆分，离线计算的增量计算优化，实时计算的滑动时间窗口计算引擎，分库分表 + 读写分离，等各类技术手段，支撑住了百亿量级的数据量的存储与计算。

咱们先来回看一下当时的那个架构图，而后继续聊聊这套架构在面对高并发、高可用、高性能等各类技术挑战下，应该如何继续演进。

2、active-standby高可用架构

你们看看上面的那个架构图，有没有发现里面有一个比较致命的问题？就是如何避免系统单点故障！

在最初的部署架构下，由于数据平台系统对CPU、内存、磁盘的要求很高，因此咱们是单机部署在一台较高配置的虚拟机上的，16核CPU、64G内存、SSD固态硬盘。这个机器的配置是能够保证数据平台系统在高负载之下正常运行的。

可是若是仅仅是单机部署数据平台系统的话，会致使致命的单点故障问题，也就是若是单台机器上部署的数据平台系统宕机的话，就会立马致使整套系统崩溃。

所以在初期的阶段，咱们对数据平台实现了active-standby的高可用架构，也就是一共部署在两台机器上，可是同一时间只有一台机器是会运行的，可是另一台机器是备用的。处于active状态的系统会将滑动窗口计算引擎的计算状态和结果写入zookeeper中，做为元数据存储起来。

关于元数据基于zookeeper来存储，咱们是充分参考了开源的Storm流式计算引擎的架构实现，由于Storm做为一个很是优秀的分布式流式计算系统，一样须要高并发的读写大量的计算中间状态和数据，他就是基于zookeeper来进行存储的。

自己zookeeper的读写性能很是的高，并且zookeeper集群自身就能够作到很是高的可用性，同时还提供了大量的分布式系统须要的功能支持，包括分布式锁、分布式协调、master选举、主备切换等等。

所以基于zookeeper咱们实现了active-standby的主备自动切换，若是active节点宕机，那么standby节点感知到，会自动切花为active，同时自动读取他们共享的一个计算引擎的中间状态，而后继续恢复以前的计算。

你们看下面的图，一块儿感觉一下。

在完成上述的active-standby架构以后，确定是消除掉了系统的单点故障了，保证了基本的可用性。并且在实际的线上生产环境中表现还不错，一年系统总有个几回会出现故障，可是每次都能自动切换standby机器稳定运行。

这里随便给你们举几个生产环境机器故障的例子，由于部署在公司的云环境中，用的都是虚拟机，可能遇到的坑爹故障包括但不限于下面几种状况：

• 虚拟机所在的宿主机挂了
• 虚拟机的网络出现故障
• 负载太高致使磁盘坏了

因此在线上高负载环境中，永远别寄但愿于机器永远不宕机，你要随时作好准备，机器会挂！系统必须作好充分的故障预测、高可用架构以及故障演练，保证各类场景下均可以继续运行。

3、Master-Slave架构的分布式计算系统

可是此时另一个问题又来了，你们考虑一个问题，数据平台系统其实最核心的任务就是对一个一个的时间窗口中的数据进行计算，可是随着天天的日增数据量愈来愈多，每一个时间窗口内的数据量也会愈来愈大，同时会致使数据平台系统的计算负载愈来愈高。

在线上生产环境表现出来的状况就是，数据平台系统部署机器的CPU负载愈来愈高，高峰期很容易会100%，机器压力较大。新一轮的系统重构，势在必行。

首先咱们将数据平台系统完全重构和设计为一套分布式的计算系统，将任务调度与任务计算两个职责进行分离，有一个专门的Master节点负责读取切分好的数据分片（也就是所谓的时间窗口，一个窗口就是一个数据分片），而后将各个数据分片的计算任务分发给多个Slave节点。

Slave节点的任务就是专门接收一个一个的计算任务，每一个计算任务就是对一个数据分片执行一个几百行到上千行的复杂SQL语句来产出对应的数据分析结果。

同时对Master节点，咱们为了不其出现单点故障，因此仍是沿用了以前的Active-Standby架构，Master节点是在线上部署一主一备的，平时都是active节点运做，一旦宕机，standby节点会切换为active节点，而后自动调度运行各个计算任务。

这套架构部署上线以后，效果仍是很不错的，由于Master节点其实就是读取数据分片，而后为每一个数据分片构造计算任务，接着就是将计算任务分发给各个Slave节点进行计算。

Master节点几乎没有太多复杂的任务，部署一台高配置的机器就绝对没问题。

负载主要在Slave节点，而Slave节点由于部署了多台机器，每台机器就是执行部分计算任务，因此很大程度上下降了单台Slave节点的负载，并且只要有须要，随时能够对Slave集群进行扩容部署更多的机器，这样不管计算任务有多繁忙，均可以不断的扩容，保证单台Slave机器的负载不会太高。

4、弹性计算资源调度机制

在解决了单台机器计算负载压力太高的问题以后，咱们又遇到了下一个问题，就是在线上生产环境中偶尔会发现某个计算任务耗时过长，致使某台Slave机器积压了大量的计算任务一直迟迟得不处处理。

这个问题的产生，其实主要是因为系统的高峰和低谷的数据差别致使的。

你们能够想一想，在高峰期，瞬时涌入的数据量很大，极可能某个数据分片包含的数据量过大，达到普通数据分片的几倍甚至几十倍，这是缘由之一。

还有一个缘由，由于截止到目前为止的计算操做，其实仍是基于几百行到上千行的复杂SQL落地到MySQL从库中去执行计算的。

所以，在高峰期可能MySQL从库所在数据库服务器的CPU负载、IO负载都会很是的高，致使SQL执行性能降低数倍，这个时候数据分片里的数据量又大，执行的又慢，很容易就会致使某个计算任务执行时间过长。

最后一个形成负载不均衡的缘由，就是每一个计算任务对应一个数据分片和一个SQL，可是不一样的SQL执行效率不一样，有的SQL可能只要200毫秒就能够结束，有的SQL要1秒，因此不一样的SQL执行效率不一样，形成了不一样的计算任务的执行时间的不一样。

所以，咱们又专门在Master节点中加入了计算任务metrics上报、计算任务耗时预估、任务执行状态监控、机器资源管理、弹性资源调度等机制。

实现的一个效果大体就是：

• Master节点会实时感知到各个机器的计算任务执行状况、排队负载压力、资源使用等状况。
• 同时还会收集各个机器的计算任务的历史metrics
• 接着会根据计算任务的历史metrics、预估当前计算任务的耗时、综合考虑当前各Slave机器的负载，来将任务分发给负载较低的Slave机器。

经过这套机制，咱们充分保证了线上Slave集群资源的均衡利用，不会出现单台机器负载太高，计算任务排队时间过长的状况，通过生产环境的落地实践以及一些优化以后，该机制运行良好。

5、分布式系统高容错机制

其实一旦将系统重构为分布式系统架构以后，就可能会出现各类各样的问题，此时就须要开发一整套的容错机制。

大致提及来的话，这套系统目前在线上生产环境可能产生的问题包括但不限于：

• 某个Slave节点在执行过程当中忽然宕机
• 某个计算任务执行时间过长
• 某个计算任务执行失败

所以，Master节点内须要实现一套针对Slave节点计算任务调度的容错机制，大致思路以下：

1. Master节点会监控各个计算任务的执行状态，同时也会监控各个Slave节点的运行状态
2. 若是说某个Slave宕机了，那么此时Master就会将那个Slave没执行完的计算任务从新分配给其余的Slave节点
3. 若是说某个Slave的计算任务执行失败了，同时重试几回以后仍是失败，那么Master会将这个计算任务从新分配给其余的Slave节点来执行
4. 若是说某个计算任务在多个Slave中没法成功计算的话，此时会将这个计算任务储存在一个延时内存队列中，间隔一段时间事后，好比说等待高峰期故去，而后再从新尝试执行这个计算任务
5. 若是某个计算任务等待很长时间都没成功执行，多是hang死了，那么Master节点会更新这个计算任务的版本号，而后分配计算任务给其余的Slave节点来执行。
6. 之因此要更新版本号，是为了不说，新分配的Slave执行完毕写入结果以后，以前的那个Slave hang死了一段时间恢复了，接着将计算结果写入存储覆盖正确的结果。用版本号机制能够避免这种状况的发生。

6、阶段性总结

系统架构到这个程度为止，其实在当时而言是运行的至关不错的，每日亿级的请求以及数据场景下，这套系统架构都能承载的很好，若是写数据库并发更高能够随时加更多的主库，若是读并发太高能够随时加更多的从库，同时单表数据量过大了就分更多的表，Slave计算节点也能够随时按需扩容。

计算性能也是能够在这个请求量级和数据量级下保持很高的水准，由于数据分片计算引擎（滑动窗口）能够保证计算性能在秒级完成。同时各个Slave计算节点的负载均可以经过弹性资源调度机制保持的很是的均衡。

另外整套分布式系统还实现了高可用以及高容错的机制，Master节点是Active-Standby架构能够自动故障转移，Slave节点任何故障都会被Master节点感知到同时自动重试计算任务。

7、下一个阶段的展望

其实若是仅仅只是天天亿级的流量请求过来，这套架构是能够撑住了，可是问题是，随之接踵而来的，就是天天请求流量开始达到数十亿次甚至百亿级的请求量，此时上面那套架构又开始支撑不住了，须要继续重构和演进系统架构。

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倍以上？

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