亿流量大考（2）：开发一套高容错分布式系统

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

一、写在前面

上篇文章《亿流量大考（1）：日增上亿数据，把MySQL直接搞宕机了…》，聊了一下商家数据平台第一个阶段的架构演进。通过离线与实时计算链路的拆分，离线计算的增量计算优化，实时计算的滑动时间窗口计算引擎，分库分表 + 读写分离，等各种技术手段，支撑住了百亿量级的数据量的存储与计算。

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

二、active-standby高可用架构

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

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

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

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

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

本身zookeeper的读写性能非常的高，而且zookeeper集群自身就可以做到非常高的