浅谈系统的高可用性

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

对于高可用这个概念，个人认为至少满足下列几点：

1.程序异常处理，这个是基本功，仅能在正常情况下运行的程序不叫程序

2.机房容灾，即当个别机器损坏，或者个别机房网络割接时，仍可正常运作

3.系统容易扩展，即当遇到性能瓶颈时，可横向扩展解决，比如多部署几个程序即可解决，无需更改代码

4.无需过多的人工干预，7*24都能工作，遇错自动调整，不必投入人力时刻关注程序的状态

下面拿一个比较简单数据采集系统来分析一下问题，图是用Windows画图板画的，不够严谨，有时间再换过来

数据流程：producer(采集)->rabbitmq(转发)->consumer(消费入库)->DB

producer：采集器，消息生产者

rabbitmq：消息转发

consumer：数据消费者

DB：数据库

图1：最简单的模型



先来看看图1的架构达成了哪些高可用的要素，还有哪些致命的缺陷

1.producer可灵活增加，目的达成

2.rabbitmq为单机进程，一旦出现机器或者网络故障则不可用

3.consumer可灵活增加，目的达成

4.DB为单点，一旦出现机器或者网络故障则不可用，且容易出现性能瓶颈

仔细想一想，很容易就发现图1系统的缺陷，机器和网络故障都是很常见的，所以这个方案根本不靠谱。

图2：稍作优化的模型



先来看图2比图1多了哪些组件，

rabbitmq从单机版变成了2个独立集群，且部署在不同的机房，且是多线机房，满足电信联通移动等网络

DB根据业务特性，拆分成N独立DB，分摊了数据库的写压力，也将数据的可用性提高了。

再来详细讲解图2各个程序的设定，

producer：

1.根据同ISP原则配置了多个rabbitmq节点，首先避免跨ISP传输数据的情况，速度更快，可以进一步优化为就近访问线路

2.遇到rabbitmq节点死机或者网络故障时，自动切换rabbitmq节点，解决了传输故障的问题

rabbitmq:

1.分布在多个机房，且可为多个ISP服务，基本达到了高可用的目标

2.当集群性能出现瓶颈时，横向新增集群即可，这里缺陷就是当rabbitmq新增集群时，如何更新所有的producer配置，通过逐一更改程序的配置再重启这种方式显然很原始，后面再优化这一点

consumer：

1.每个消息队列至少应该对应2个consumer，并部署在不同的机器，这样就避免了单机单进程的问题

2.如果consumer的消费能力跟不上，则横向增加程序即可，瓶颈转移至DB的写压力上，基本达到目标

DB:

1.一个DB变为N个DB，分摊了写压力

2.在没有备份的情况下，数据同时不可读的概率就降低了

再来汇总一下图2的缺陷：

1.如何自动更新producer程序的配置

2.DB既然有写，肯定会有读，如果查询很频繁，或者单表数据很大，那么读写效率如何进一步进行优化

3.整套系统虽然容错性强了，依然处于无监控状态，比如producer全损坏了，无数据产生；

比如consumer损坏了，数据阻塞在rabbitmq；比如进程内存泄露等等；

4.如何做到系统自动提示需要扩容了？我们的终极目标就是尽量少的人工干预，解放大脑和眼睛

图3：进一步优化的模型



再来对比下图3比图2多了哪些组件：

1.引入zookeeper管理配置的更新

2.进一步优化了DB

3.引入了deal stat程序，分析系统的处理性能

4.引入了alarm程序监控系统

先来谈谈配置自动更新：

zookeeper可做到配置的自动分发至producer，也可以告知producer某个rabbitmq的节点坏掉了，可以摘掉，那么人工干预的成本就进一步降低了

再来谈谈DB的优化，这里对DB做了进一步的优化，采用SSD磁盘，主从化，读写分离，分表设计，优化索引，在这里只提一些很常规的优化手段。

deal stat程序有什么用，我们想一个问题，我们不可能经常去看系统的处理能力数据，那么瓶颈出现的时候我们怎么知道？这里引入deal stat主要是实时分析系统的处理能力，一旦达到我们设置的瓶颈，则通过邮件/短信/微信等各种手段通知程序维护者去处理，比如扩容。

最后再来谈alarm系统，可以说，一个没有告警机制的系统，本质上是个裸奔或者烂系统，不具备可维护性。

针对图3，我们可以想出很多种情况，假设我们的告警手段是邮件/短信/微信

1.内存/cpu占用异常，用crontab就可以做到定期检测，通知程序维护者并自动重启进程

2.DB磁盘空间达到阀值，通知程序维护者扩容

3.自动回滚压缩日志文件，磁盘空间总是有限的，不可能人工去rm，几千台机器怎么破，对吧

4.rabbitmq的队列过大，consumer处理能力不足，通知程序维护者

5.程序异常(僵死)，比如consumer定期输出running状态的日志，一旦alarm程序发现一段时间没收集到该日志，则认为consumer异常，通知程序维护者

6.不一一举例了

图3总结：

1.要避免重要的进程出现单机运行的情况

2系统应该是容易扩展的，而不是遇到性能问题就要修改代码.

3.系统要处理各种异常情况，包括软硬件的问题

4.系统要进行监控，里里外外监视起来，并自动通知管理员

5.尽力减少人力去维护系统，一切都自动化，只需要点点鼠标就能把系统运营好

6.关注系统的数据指标，这是系统优化的数据基础

图3的缺陷：

DB由于业务的特性，数据不需要做一致性处理，但是并没有做到容灾处理，一旦某个节点的DB出现故障，仍然会影响系统的可用性

DB部分参考这个文章：支付宝的高可用与容灾演进