一、写在前面
上篇文章《别光看NB的Github开源项目,你得参考他们去设计自己的架构!》,聊了一下商家数据平台第一个阶段的架构演进。通过离线与实时计算链路的拆分,离线计算的增量计算优化,实时计算的滑动时间窗口计算引擎,分库分表 + 读写分离,等各种技术手段,支撑住了百亿量级的数据量的存储与计算。
我们先来回看一下当时的那个架构图,然后继续聊聊这套架构在面对高并发、高可用、高性能等各种技术挑战下,应该如何继续演进。
二、active-standby高可用架构
大家看看上面的那个架构图,有没有发现里面有一个比较致命的问题?就是如何避免系统单点故障!
在最初的部署架构下,因为数据平台系统对CPU、内存、磁盘的要求很高,所以我们是单机部署在一台较高配置的虚拟机上的,16核CPU、64G内存、SSD固态硬盘。这个机器的配置是可以保证数据平台系统在高负载之下正常运行的。
但是如果仅仅是单机部署数据平台系统的话,会导致致命的单点故障问题,也就是如果单台机器上部署的数据平台系统宕机的话,就会立马导致整套系统崩溃。
因此在初期的阶段,我们对数据平台实现了active-standby的高可用架构,也就是一共部署在两台机器上,但是同一时间只有一台机器是会运行的,但是另外一台机器是备用的。处于active状态的系统会将滑动窗口计算引擎的计算状态和结果写入zookeeper中,作为元数据存储起来。
关于元数据基于zookeeper来存储,我们是充分参考了开源的Storm流式计算引擎的架构实现,因为Storm作为一个非常优秀的分布式流式计算系统,同样需要高并发的读写大量的计算中间状态和数据,他就是基于zookeeper来进行存储的。
本身zookeeper的读写性能非常的高,而且zookeeper集群自身就可以做到非常高的可用性