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上。

ERROR 1062 (23000) at line 1234: Duplicate entry ‘xxxxx’ for key ‘username’

( xxxxx 是举例，每一个论坛每一个数据库都会不同，因为是用户名)

这错误一般会发生在你使用论坛后台的数据库mysql dump，分卷备份，或者Windows/linux 的mysqdump 导出/导入，Navicat Lite for MySQL的导入…等..

导出是很正常的，但当你论坛数据库发生了错误，需要修复，把备份的.sql 重新导入到数据库的时候，问题就来了！

数据导入刚开始不久，就弹出以上那条错误！。如果刚搞碰上你数据库崩溃，正急着修复的时候就更加惨！(因为Google上没多少个解决方法能帮到你)

所以我已经是万幸了！我在做试验的时候发现了这个问题，当我想把正在正式运行的数据库的日备份文件 .sql 导入到一个测试库里头做试验的时候。导到一半，停了！。

在Google上搜索到解决方法是使用 –force 参数，即：

mysql  -h 192.168.10.4 -uroot -p –force test_gznow_bbs <   ./test_gznow_bbs.sql

这么做的确剩下的数据都能够导进去！但是！你会发现该表中剩下的数据都被一一跳过！

就那 Discuz 7.0 为例！ 由于的 username 键值位于 cdb_menbers 里头 ，所以你导入以后，会发现用户列表少了N页！

很多在论坛发过帖的用户都显示被删除或者屏蔽。

这样的话！！数据就有相当严重的问题！换句话来说！就是这个 .sql 的备份文件根本无法用！！！！

其实ERROR 1062 (23000) at line 1234: Duplicate entry ‘xxxxx’ for key ‘username’ 这错误的意思是告诉你在不允许在索引存在重复。

再说明白一点，就是你论坛上有2个用户名一模一样的用户！可能是出错造成的，可能是注册机制不完善造成的，可能是你升级论坛时候造成的….不管是什么原因。

现在你要做的，就是要把这2个重复的用户删掉其中一个！或者干脆2个都删掉（为安全起见）

如果你的数据库还好好地，这么建议你先未雨绸缪…启动 Navicat Lite for MySQL  打开 Discuz 7.0 论坛对应的库 (UCenter的先不用管)

然后执行查询，输入并 运行 查询语句 select username,count(*)  from cdb_members group by username order by 2 limit 10 (查找重复的数据)

如下图：

如果差得结果入上图所示，一个或多个用户的结果显示 2 或者是高于2 ，就代表数据库中存在有2条以上的记录！
这是 cdb_members 表中的索引机制所不允许的。

上图username 项中所对应名称就告诉你哪个用户名重复了。然后你可以复制该用户名！

然后进入 论坛系统设置，

输入刚才你所复制的用户名，然后搜索！

怎么，看到了吧？！ 真的是有2个完全相同用户名的会员！

都删除其中一个，（建议2个都删了）然后在 UCenter 也同样，搜索这个会员名，通通删掉…. 即可恢复正常导入导出了。

但如果你的论坛数据库已经崩溃，只剩下 .sql 文件，这么就麻烦了…要么你就手动在 几百 M 的 .sql 文件中找..要么你就损失一下用户.用 –force 强行导入了.