分类: LINUX
2012-02-27 16:02:41
这个集群的架构如下图:
上面我们共部署了5个节点,每个节点上配有 Nginx + PHP。这个架构的重点就在于,Nginx 不只是与本机的 PHP 通信,整个集群应该把 Nginx 部分抽象到面向业务的第一层,而 PHP 则在第二层。每层都为多节点均衡架构。
其中 Nginx 层面使用 DNS 均衡实现,DNS 负载均衡是一个很传统的方案,在单个域名下绑定多个 IP 进行轮循,可有效的把业务请求分发到多个节点上,但某节点故障时则需要有相应的解析处理,把故障的节点从 DNS 记录中删除。目前推荐使用 DNSPOD 的解析服务,可支持 API 操作。这样我们就可以自己建立一个服务器状态管理的程序,自动切换 DNS 解析。(注意:域名解析的切换需要 5~10 分钟,当然这是由域名解析记录的 TTL 值决定,为避免大量的 DNS 解析影响请求打开速度,建议 10 分钟或以上为佳)
第二层 PHP 则由 Nginx 使用 upstream 实现均衡,Nginx 本身的 upstream 就已支持节点健康维护的功能,可以放心的交给 Nginx 来做。而如果 PHP 业务层带缓存功能,则要考虑使用一致性哈希模块来实现 upstream 的均衡策略,否则节点故障对整个 PHP 集群的缓存造成大幅度的震荡。根据我们测试的数据,在普通哈希策略下,一个节点故障会导致 90% 的缓存失效,而使用一致性哈希则可降低到 50% 。并且我们的 Nginx 一致性哈希模块,还可以把故障节点的请求分发到邻近的节点,可以再提高部分缓存命中率,使得整体提升到 70% 的样子。
这样一个架构方案给我们实现了一个“高”可用的 PHP 集群,并且没有单点故障的隐患存在。DNS 解析服务是多节点,Nginx 层是多节点,PHP 层更是多节点的模式。如使用 LVS 方案,LVS 服务本身也要做一套热备,才能避免单点问题,且增加了架构复杂性。
应该选择那套架构方案还由业务决定,这里我只是提供一个新思路罢了
Nginx 一致性哈希模块:ngx_consistent_hash-1.0.tar
ngx_consistent_hash-1.1.tar.gz (Fix nginx reload bug)
使用方法:
upstream backend {
server 192.168.1.101 weight=1;
server 192.168.1.102 weight=2;
server 192.168.1.103 weight=3;
server 192.168.1.104 weight=4;
server 192.168.1.105 weight=5;
consistent_hash $host$request_uri 2;
}
consistent_hash 支持2个参数,第一个参数为哈希字符串,第二个参数为备份节点数量。当某节点故障时,将把该节点的请求分发到2个备份节点上。当然你可以设置1或更高,建议2为佳
模块对 nginx 原 upstream 模块的 weight 节点权重功能进行了替换,weight 的功能是配置节点在集群中的位置顺序。(做一致性哈希,这是必须的)