php负载均衡，服务器上传图片

又看到你了。

你理解错了吧，访问B服务器不一定上传就得上传到B服务器，图片服务器应该有自己的域名（img.xxx.com）用户访问的是B服务器做好的网站，但是使用上传时提交到的是A的域名。

起因：在实际项目开发过程中，需要使用RabbitMQ来实现消息队列的功能，但仅仅实现功能之后并不能对自己满足，既然学一次，就要更深的了解她，吃一吃架构方面的相关内容，提升自己。

RabbitMQ在镜像集群中，机器其实是平行关系，所有的节点都是互相复制的

场景描述：

A是Master

B是Slave

A正常运行，B宕机了，只需要启动B即可，B就会自动加入集群

A和B都宕机了，只要A在B之前启动就可以了

A和B都宕机了，A启动不起来了，即便是B启动了，有可以B直接启动不了啦

B和C都加入了A为Master的集群，这个时候都需要将B和C从A的集群中forget，B和C启动不起来了

RabbitMQv3.2版本以后提供了一个离线清除集群节点的命令参数，也就是节点无法启动状态下

HAProxy是一款提供高可用的负载均衡器（之前大家都是使用的Nginx居多，upstream反向代理实现负载均衡非常容易），HAProxy可以基于TCP四层（Lvs也是TCP四层的），HTTP七层（Nginx是HTTP七层）的负载均衡应用代理软件，免费高速可靠的一种LBS解决方案

HAProxy的并发连接完全可以支持以万为单位的

Nginx

优点：

1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。

2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。

3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。

4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量。

5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。

6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。可作为静态网页和图片服务器，在高流量环境中稳定性也很好。

7、可作为中层反向代理使用。

缺点：

1、适应范围较小，仅能支持http、https、Email协议。

2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测

3、负载均衡策略比较少：轮询、权重、IP_hash、url_hash

HAProxy

优点：

1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段)

2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。

3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡。

5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种

缺点：

1、不支持POP/SMTP协议

2、不支持SPDY协议

3、不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。

4、重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。

5、多进程模式支持不够好

HAProxy+Keepalived（负载均衡节点的高可用）

将上面的配置文件内容放入 /etc/haproxy/haproxy.cfg中

启动HAProxy

启用成功后可以到控制台进行验证

通过federation的配置来进行数据通道搭建

这个时候你需要自己定义一个上游节点upstream(166节点)，一个下游节点downstream(167节点)，federation是单向发送的，相当于消息发送到upstream的一个exchange上，然后转发到downstream的queue上

1、 在下游节点创建一个exchage和一个queue和binding的routingkey，用来进行数据接收

2、 在下游节点建立federation upstream规则和上游节点进行数据同步

3、 进入下游节点的federation status没有任何数据，需要建立策略来保证通道连通

4、 进入下游节点的Policy菜单，Pattern是个正则表达式，这里表示以down开头的exchange和queue都匹配

5、 这个时候看exchange和queue，规则就应用上了

6、 这个时候去federation status看，发现上游连接已经连接上了

7、 这个时候我们先去看上游的overview

8、 再看上游的exchange和queue就已经根据下游配置的upstream和policy规则将exchange和queue创建好了

灰色的这个重定向exchange不能发送消息，如果要发送则在down-exchange上进行发送

9、 我们在上游的down-exchange发送一条消息，进行测试

可以在下游查看这条消息

10、 因为上游及节点只是一个中转，如果上游及诶单也要消息down-exchange里的消息怎么办？

只需要在本地建立一个binding关系就好

不要以为每天把功能完成了就行了，这种思想是要不得的，互勉~！

局域网内可以考虑 rsync + inotify-tools inotify可以监控文件系统的各种变化，当文件有任何变动时，就触发rsync同步，这样刚好解决了同步数据的实时性问题。 局域网内多台服务器时可以配置Nginx把上传等写操作固定到其中一台PHP-FPM服务器,然后用inotify+rsync同步到其它机器. 比如上传操作定向到服务器192.168.1.10进行处理: location ^~ /upload.php { include fastcgi_params fastcgi_pass 192.168.1.10:9000 fastcgi_param SCRIPT_FILENAME /srv/www$fastcgi_script_name}在服务器192.168.1.10上用inotify+rsync同步文件到其他服务器. 除上传外，删除、更改、移动等写操作也要定向到192.168.1.10这台服务器进行处理。

---