上回说到了一种通过增加站点数量,人为的分散单站点的负载,同时增加总体带宽的方法,其实里面有很多疑问,我就在后面一一谈论自己的想法。
 
          首先,两个主站的互为备份属于物理层面上的,并且真正的活跃的主站只能有一个,也就是我们站点A记录对应的主机,在保证两点的数据一致的情况下,当一个节点出现问题,我们可以手工的修改A记录,将主站切换到另一个节点,但这需要时间,也就是域名解析同步的时间。这种结构对可预测的宕机是很有用的。但如果要实现智能负载均衡还需DNS服务器的参与,这点是虚机主机和域名服务商不好解决的。配过 Bind 的人都知道,可以针对来访客户端的IP地址判断,应答不同的解析,实现就近访问。我们要实现这种功能,也只能去自己手工搭建DNS服务器,或者租用能提供此种服务的DNS服务器。这是租用虚拟主机的弱点,毕竟少花钱了。
 
         其次,针对主站间的程序同步以及数据同步,需要在程序上做很大改动,分发或者订阅或者通过第三节点进行传输,这是个纯技术问题。对于程序文件我们可以在程序上传的时候进行同步上传,这点比较容易,而数据库这样做就太辛苦了。如果虚拟主机供应商提供了远程访问数据库的接口,我们可以在程序写数据库的时候,进行双库同时写入,对于ASP也就是两个Adodb.Connection连接到自己的节点和备份节点,也就是双写入。另外一种方法是专门写一个同步程序,对两个节点的数据进行一致性检查。其实做过Exchange2007/2010的高可用项目的同学都接触过异步日志传输的概念,我们也可以将对数据表执行过的非查询类语句进行记录,并通过写程序将其传输到另一个节点并应用。大家可能觉得这个太复杂,毕竟咱少花钱了……
 
        再次,对于静态内容我们将其分布到了多个站点上进行规则性的访问,虽然达到了负载的分配,但面对单点故障我们仍需要手工干预。那么能不能按照负载均衡集群的原理改善我们的站点呢?答案是肯定的。
 
        从网站总体结构上来讲,我们的主站相对于静态内容站就相当于一个负载均衡机,由主站动态生成的HTML代码来决定图片从哪几个站点来,css从哪几个站点来等等。如果要实现容灾,就必须实现节点间的互备同时必须在主站上记录这些分站点的实时健康状态。同样参考DAG,假如我们有4个节点ABCD,我们可以在A上保存B的内容,B上保存C的内容,这样当两个不相邻的节点出现异常时仍可以保证我们的整站资源是完整的。
 
        关于实时健康状态的上报,可以用一个简简单单的JS来搞定,在主站上可以在Application层建立一个负载计数器,根据负载情况进行智能负载分配,当遇到异常健康状态时暂停对该节点的负载分配。
 
        通过以上的调整,基本一个主站的手动容灾和分站的智能负载均衡已经完成了,当然细节上面还有问题,比如如何使用application变量,如何传输sql记录等等,以后有时间再继续详细阐述,欢迎大家拍砖,同时在http://www.guoerguo.com 站点上一定会将这个理论付诸于实践,欢迎大家关注。