【简记】大规模Web开发技术（第十三章）

第13章 保证冗余性和系统的稳定化——实现100%在线率的原理

保证冗余性——应用程序服务器

一般解决方法：增加服务器

当服务器宕机时：用负载均衡器实现失败转移(failover) 和失败恢复( failback) ，让故障服务器自动下线，故障恢复之后再上线。失败转移(failover) 就是使其自动离线，失败恢复( failback)就是让恢复正常的服务器再次上线。负载均衡器对服务器定期进行健康检查，判断应用程序服务器、数据库服务器是否正常运行。这就是最基本的冗余性。

保证冗余性——数据库服务器

数据库服务器也同样需要增加数量，保证在一两台停机时也有充足的处理能力。此外， master 也要进行冗余化。第5章讲过，master 的冗余化比较困难。Hatena 采用了multi-master 的方式实现了冗余化。

Multi-master 具体来说，就是两台服务器互相replication、互相作为对方的slave ， 一方写入的数据传播至另一方，另一方写入的数据也要传播回来，实现双向replication 。

但是在MySQL 的实现中，实际流程为先在一方写入，再传播到另一方，因此会有微小的延迟。这样就会经常出现微秒级的数据不一致的情况。如果在这个瞬间某台服务器停机并进行切换，那么从写入数据的应用程序服务器来看，本应写入的内容实际上却没有写入，从而产生数据冲突。这种不同步的风险是永远存在的。现在是尽可能忽视这个风险，优先保证持续运行。

在企业中，该问题的对策是同步进行replication。这样，服务器可以先确认slave 己写入数据之后，再将结果返回给客户端。这样尽管能保证同步，但会造成巨大的性能损失，因此多数Web服务选择忽视不同步的风险，而重视性能。

Multi-master

各个服务器用VRRP 协议(Virtual Router Redundancy Protocol ，虚拟路由器冗余协议)互相监视。一旦通过VRRP 发现对方停机，就将自己提升为Active master

为了从外部判断哪台服务器是Active ，需要用到虚拟IP( VIP)，Active 服务器除了原有IP地址(真实IP 地址)之外，再分配一个服务用的虚拟IP地址。例如两台服务器地址分别为"0.1 "和"0.2 "，然后给Active 服务器分配一个新的"0.3 "虚拟IP地址。假设0.1 是Active，那么Active 可以通过0.1 和0.3两个地址访问。应用程序服务器用0.3 访问数据库，切断时再将0.3 分配给新的Active 服务器。这样， 应用程序服务器只须一直访问0.3 ，就可以访问到Active，从而实现master 的透明切换。
也就是说，该架构能保证0.3 这个虚拟服务器永远在线。

保证冗余性——存储服务器

MogileFS（不是很懂）

为了保存图像等媒体文件，Hatena采用MogileFS作为分布式存储服务器。

（http://maoqiu.blog.51cto.com/8570467/1409382/）

第34课 系统稳定化

系统应能承受一两台停机的情况，因此不应用尽资源，而是保持一定程度的余量，余量不足时应当采取增加服务器、改变结构以降低整体使用量等措施，保证稳定性。

系统的不稳定因素

典型的不稳定因素有以下几种。

应用程序/服务层次→负载增加

1.功能增加：

2.内存泄漏：

3.地雷：地雷这一项的意思是，某些URL 一旦读取(踩到)就无法返回应答，像地雷一样，也是系统的不稳定因素。原因有多种，如内存泄漏、死循环等。

4.用户访问模式：以前经常有所谓slashdot 效应、digg 效应等，就是链接被贴到著名网站上，被大量用户访问导致系统停机。

让系统架构吸收这种访问量的变化也很重要。典型的做法就是加上Squid 之类的缓存服务器，给未登录用户返回缓存内容。缓存几乎不用消耗任何资源就能处理请求，因此利用缓存处理未登录用户的大量访问，效果十分显著。

5.数据量增加：

6.外部关联程序的增加：增加外部关联程序，很容易导致系统由于外部系统的停止而停止，因此将系统设计成不受外界噪音影响很重要，比如外部系统停止或者负载变大时，相关服务不受影响，继续以正常速度运行:外部数据无法获取时，不会影响其他数据的显示等。

硬件→处理能力下降

内存、硬盘故障：

网卡故障：

第35课 系统稳定对策

前面讲述了维持稳定性的思路。实际的应对方法大致有两种，即维持适当余量和消灭不稳定因素。

首先，为了维持适当的余量，应当在极限的70%内运营。将系统容量的70%作为上限，超出上限后就要增加服务器、增加内存等改变阀值的操作。

消灭不稳定因素的方法有降低SQL 负载、减少内存泄漏、发生异常行为时的自律控制等。

首先是SQL 的负载。一执行错误的SQL 语句，数据库就会高负载导致停机。对于系统稳定来说，不执行高负载SQL 语句是十分重要的。应用程序工程师要尽可能掌握需要执行的SQL语句，如果要执行导致负载增加的SQL ，应该在隔离的数据库上执行。以Hatena 为例，每隔一个小时要执行一个SQL 语句，计算全体有多少个星星。以前这个语句是在用户使用的数据库上执行的，结果经常导致数据库负载过高。后来准备了一个批处理用数据库，专门执行这个批处理，这样将负载从用户平常使用的数据库中分离出来，效果很不错。

异常行为时的自律控制方面，我们目前采取了自动DoS判断、自动重启、自动终止耗时查询三项措施。

第一个自动DoS 判断(mod dosdetector) 。有种行为是不断刷新，通常称为自攻击。

Ugo Memo 的用户群中，小学生很多，经常为了增加播放次数，而恶作剧地连按时键，两个小时增加几十万播放次数。通过自动DoS 判断的措施， 一分钟之内同IP 地址发送的请求过多，就暂时返回403 ，自动切断其访问，这样就能应对这种异常状况。

我们还实现了自动重启(应用程序服务器、宿主操作系统）。本课程开头讲过，内存泄漏会导致交换频繁发生，增加系统负载，降低性能，这时可以判断为资源过度使用，对Web 服务器进行重启。另外，虚拟化的主机会对各个虚拟操作系统进行重启。Hatena Diary 的代码量很大，无法去除所有bug ，仍有内存泄漏，因此正确使用资源并维持稳定是很困难的。因此通过自动重启，实现了更加稳定的系统。
Hatena Diary 的面向爬虫的服务器被调整为用尽所有资源。因此，每隔两三天就要重启一次。

最后就是王牌一一自动终止耗时查询(KlLL 掉耗时太长的SQL) 。某些服务加入了自动查询处理，就是每隔10 秒钟查看一次数据库服务器上执行的查询，并强行KILL 掉执行时间超过某个标准的查询。执行消耗时间过长的SQL 语句，经常会导致数据库负载过大而停机，但要想修改代码，就要先明确是什么访问导致了这种查询，很难立即改善。因此，我们采用了自动去除SQL 的措施，也相当于临时对策。