使用 Nginx + Apache For Discuz 7.0(PHP) 均衡负载环境分享。

范堡 发布于 2009/04/02 13:22
阅读 3K+
收藏 2

近日把原来网站运行的 Discuz 论坛由 4.1 连跳 5 级 ( 5.0, 5.5, 6.0, 6.1, 7.0)。

Discuz 7.0 的功能很强大, 但后续的问题比较多, 原来的软硬件环境运行 4.1 是绰绰有余的,但升级到7.0  的时候,随着改版,用户的活跃度,以及搜索引擎的优化都带来了流量激增。

原本单台服务器平均 CPU 6~10 增高到 30~40 晚上高峰期明显感到点击的反应的延迟。

是需要用到集群的时候了。

在脑中设计该集群的思路, 使用 Nginx 用于流量分发以及静态文件处理,多Apache 负责处理PHP程序。

这是一种很简单的均衡负载方式,在Nginx中配置好 upteam,Localhost 与APP0 服务器的文件同步采用NFS,再公用一个单独的Mysql_server主机。

脑子中的这个设计蓝图,一下子就能配置出来。但我所要分享的,是一些细微但作用确相当重要的技巧。

首先说一下文件同步,NFS。

Discuz 7.0 的程序根目录下有个 attachments 目录,用于写入存放上传的附件,除此之外为了优化反应速度以及减少传输量,我把除此以外根目录下的所有程序文件都复制到 APP0 的本地硬盘上。

好了,一开始就是这么一架构,开始试验。

发生的第一个问题是当论坛站长(管理员) 登陆后台的时候, 由于均衡负载在不停的 2 个 apache 上跳,所以导致输入密码之后怎样都进不了后台。(后台的 cookies 在一关闭浏览器之后就会自动清除)

怎么办? 你可以使用另一个二级域名域名,指到同一个目录,但不绑到 Nginx 的 upteam,proxy 的时候直接写的是 但一台主机apache 的地址.  例如:proxy_pass http://127.0.0.1:8080;

但还有一个方法是我现在所用的,直接把后台的php程序过滤出来,绑定在localhost 的Apache上,不参与均衡负载。

        location ~ admincp.php$ {
            proxy_pass   http://127.0.0.1:8080;
            include proxy.conf;
        }

 把以上这配置加插在Nginx php的过滤语法之上, 其实原理跟过滤PHP是一样的。
凡是 admincp.php  的文件,都proxy 送至 http://127.0.0.1:8080
下边这段是 Nginx 用于过滤处理 php  的语法。

        location ~ \.php$ {
            proxy_pass   http://server_gznow;
            include proxy.conf;
        }

这么一来,Nginx 负责出来所有除 php 以外的请求,而php 就交由后方 apache 处理。并配置了 upteam 均衡负载,因此会分配到各个apache 处理达到流量分摊。而  admincp.php 在Nginx 过滤所有php进行均衡负载之前已绑定在单一个apache 上,就是说该程序并没设置到均衡复制,所以刚才无法登陆后台的问题解决。

好了,这么做下一个继续测试,上传文件,出问题了。

Discuz 7.0 的上传文件为了标明版权或者防盗链,可以在后台中设置为图片打上水印。

在均衡负载的情况下,使用批量上传功能upload的图片会发生一部分有水印,一部分没有的情况。这就肯定跟配置了均衡负载的原因有关。

水印功能需要用到 GD 的JPEG函数,经检测,2台用于均衡负载的服务器 GD支持 JPEG 的环境是没问题的。不使用均衡负载的情况下所有图片都能打上水印,这是为什么呢? 这跟 Discuz 7.0 的批量上传构造有关。也不大好说明,但通过以下方法能解决。

从web日志观察所得,用户发帖,会用到 post.php 这个程序文件,而上传,即会用到 misc.php

于是我们就跟之前解决后台登陆的方法一样,先把 misc.php 绑定在localhost上,经测试。不成功,图片上传依旧一部分图片没有水印。看来 misc.php 只负责上传,而打水印的函数应用恐怕就是 post.php 负责的。

所以我就干脆把 misc.php 跟 post.php 都绑定在单独的一台 localhost 上。

这么有个好处,更加省了 APP0  NFS 同步的流量。原来上传图片,用户都需要兜圈 Nginx --> APP0 --> NFS --> local --> Nginx

现在直接就能  Nginx <--> local

坏处就是,post.php 跟 misc.php 都不能参与均衡复制了,如果用户发帖上传得厉害,这就要以后再想别的办法了....

但就又悟出了一个道理,如果日后Mysql 撑不住了,想进行读写分离的时候!可以用同样的方法。

例子:先把Mysql 配置为主从复制

把帖子浏览或板块浏览的程序  viewthread.php  forumdisplay.php 等紧紧读数据的程序 绑在 APP0 ,然后 conf.inc.php 配置文件中 mysql 的地址指定为mysql 从服务器的地址。

因为帖子浏览紧紧需要在 mysql 进行读的操作,而写的操作,例如 post.php 以及一些版主管理的页面都帮到 localhost 然后在conf.inc.php 配置中配置 mysql 主 的服务器地址。这么读写就能分开了!

 

然后还有一个问题,是后台设置后,Discuz 是有缓存的,往往需要更新缓冲设置才能在前台中显示出来。

但由于设置的admincp.php被绑在单独一台服务器上,所以就算更新缓存,也只更新了一台服务器的缓存。

你可以有2个方法。

1,修改 Nginx  的配置把 admincp.php 指向到另外一台服务器,更新完之后再换回来。

2,用 Rsync ! 配置好同步的参数,写成 shell 程序,一执行即刻往主机上同步,这样就什么 cache 也跟主机上一样了。

############################

4.3 更新

############################

经过数天的观察,发现有个比较奇怪的现象。

Localhost服务器(即Nginx的本地服务器)硬件配置为Intel奔腾D2.8G 双核。

里边运行的服务也不算多,会占些资源的应用,Awstats,Cacti,Nginx,Apache,也就这么几个。

而APP0 机其实是个 VMware 的虚拟机安装的系统,主机的配置是双路的 Xeon 2.8G 1M 。

先撇开双路对性能的强化,就Vmware来说,虚拟出来的从系统性能上已经是有一定的折扣。

PHP 所测得的CPU整数运算能力以及浮点运算成绩都跟真实的机器相差甚远。

但当我把Nginx upteam 的负载量更多地调配到 APP0 上的时候,虽然Discuz 页尾显示的PHP执行的耗时比Localhost多,但的页面反应速度确高于前者。

现在暂时还在研究成因,但既然是这样,我就尝试在Vmware上再模拟多一个应用服务器,APP1。现在+上Localhost就总共有3个Apache 的后端。

速度再有明显的提高!我的看法,是多线程的处理大大有利于Web的应用,这跟多核心CPU有利于WEB服务器性能的道理一样。因为现在算上Xeon2.8 的HT超线程技术3个Apache后端就总共有 6 个CPU在处理应用。

而且经过实际的测试,发觉NFS的缓存是足够能减少APP跟Localhost之间的数据传输,而且缓存还能提高读写性能!比直接在 Vmware 虚拟机的虚拟硬盘上读写的速度快得多。二来也方便得多,不用好像之前那样有更新Discuz 缓存的同步麻烦。于是就直接使用 NFS 把Localhost的web_server 目录直接 mount 到2个 APP上。 

加载中
0
JavaGG
JavaGG

帮顶........

0
xzg
xzg

订 顶 盯

0
xujiajay
xujiajay

好东西 顶死你啊

返回顶部
顶部