Ⅰ php负载均衡 下面怎么得到真实ip
1、打开文件：/etc/httpd/conf/httd.conf。
2、在文件中查找：”CustomLog”，找到如下配置块: 查看到当前使用的LogFormat为”combined” (如果实际启用的为其他日志格式，替换相应的格式定义即可)。
#
# For a single logfile with access, agent, and referer information
# (Combined Logfile Format), use the following directive:
#
CustomLog logs/access_log combined
3、在文件中查找：”LogFormat”,找到如下配置块（combined格式定义）:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
将其修改为：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Forwarded-For}i\" " combined
4、保存并关闭文件/etc/httpd/conf/httd.conf。
5、重启Apache服务。
你试试吧，我也要努力在后盾人学习，一起加油吧@(*^ｪ^)@
Ⅱ nginx负载均衡 加速php，动静分离是怎么实现的
一个简单的负载均衡的示例，把www.domain.com均衡到本机不同的端口，也可以改为均衡到不同的地址上。http { : upstream myproject { : server 127.0.0.1:8000 weight=3; : server 127.0.0.1:8001; : server 127.0.0.1:8002; : server 127.0.0.1:8003; : } : server { : listen 80; : server_name www.domain.com; : location / { : proxy_pass http://myproject; : } : } }
Ⅲ Nginx运行原理和配置详解（个人总结笔记）
话不多说，撸起键盘就是干！正所谓知其然知其所以然，个人总结了下Nginx运行原理和配置详解，便于理解和后续复盘。
先来看这一张图。
nginx启动后会有 一个master进程和多个worker进程 。master进程用来管理worker进程， 一个worker进程处理一个请求 ，一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致 ，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 ，过多的worker数，只会导致进程来竞争cpu资源，从而带来不必要的上下文切换。
PHP WEB服务器目前最佳方式之一就是： Nginx + FastCGI（解决CGI并发重复fork问题） + PHP-FPM（管理PHP-CGI进程） 。nginx是怎么做到把请求抛给PHP解释来处理的呢？这个过程又是怎么实现的呢？稍后我们来看一下参数配置。
代理，反向代理，负载均衡是Nginx常用功能。
Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。如果你和小马之前一样还是分不清代理和反向代理的区别，下面这个图对理解会有所帮助。
它们的区别就是，前者知道我要找的人并知道地址在哪，代理服务器按这个地址代为请求一下然后把他说的话返回给我。后者就是，我知道我要找谁问话但不知袭冲道地址在哪，我也袜弊不想管，代理服务你自己去找，只要帮我返回他要说的话就可以了。
负载均衡：其实也是 反向代理 的一种。负载均衡，热备等等其实都属于高可用范畴，Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为 轮询，加权轮询，Ip hash 等等。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他做下实现。思考一个问题，IP hash真的能解决session共享的问题么？
我们来简单看下两个 配置示例 。
这个配置将请求转发转向mysvr 定义的服务器列表。 注意proxy_pass配置。其实这块也是负载均衡的配置 。如下：
在访问网站时，由于配置了proxy_pass地址，所有请求都会先通过nginx反向代理服务器，在服务器将请求转发给目的主机时，读取upstream为 tomcatsever1的地址，读取分发策略，配置tomcat1权重为3，所以nginx会告禅族将大部分请求发送给49服务器上的tomcat1，也就是8080端口；较少部分给tomcat2来实现有条件的负载均衡，当然这个条件就是服务器1、2的硬件指数处理请求能力。
负载均衡配置 还有其他的相关参数，这是只是打个样，不赘述。
可以认为fastcgi_pass这个配置非常关键，将Nginx + FastCGI + PHP-FPM串连 。这个配置将PHP请求都交给 fastcgi_pass配置的PHP-FPM处理。 location分别通过正则过滤和转发配置决定了各个请求URL将要转发交与的处理方式 ，location /表示默认请求，location ~\.php(.*)$ 表示PHP 脚本请求全部转发到 FastCGI处理。 使用FastCGI默认配置.。
以上配置指定了这些 静态文件要nginx自己处理 。
NGINX负载均衡可以用于很多服务负载均衡的实现，比如做Redis服务的负载均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要实现负载均衡除了NGINX，还有哪些呢？
根据7层OSI模型可将负载均衡分为 ：
1）二层负载均衡（一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）；
2）三层负载均衡（一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）；
3）四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器）；
4）七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。
这其中，最常见的是四层和七层负载均衡。思考一下，NGINX的负载均衡是属于哪一种？
关于负载均衡的架构
Ⅳ 负载均衡：F5，Haproxy，lvs, nginx
阅读本文前，需熟悉OSI七层参考模型。
常见的负载均衡设备，有F5，Haproxy，lvs, nginx等。
F5是商用硬件负载均衡，性能很好，但是价格昂贵，除了负载均衡，还有应用交换、会话交换、状态监控等众多功能。
F5一般做四层负载均衡，但也支持七层负载均衡。
Haproxy(以下简称ha)是软哗唯岁件负载均衡，开源，一般做七层负载均衡，但也支持四层负载均衡。
linux Virtual Server(以下简称lvs)是软件负载均衡，开源，二层或四层负载均衡，已集成到linux内核，自身有完备的热备方案（keepalived+lvs），稳定性极强。
nginx也是软件负载均衡，开源，通过反向代理实现负载均衡，是七层负载均衡，性能不如上面的几个。
tips1
有些公司，测试环境用ha/lvs/nginx，生产环境用F5。
tips2
nginx做web服务器时，一般做静态资源服务器和php的web服务器，所以很多公司，会采用F5+nginx或者ha+nginx的架构
tips3
微服务中的ribbon属于客户端负载均衡，上面的几种都是服务端负载均衡
二层负载均衡
在数据链路层通过修改mac地址实现，如lvs的DR模式（直接路由模式）
三层负载均衡
在网络层通过DNAT协议修改目标地址实现
四层负载均衡
用ip+端口实现请求转发
备注：tcp报文里并没有ip，但是四层负载均衡可以用ip+端口，是因为server可以拿到ip
七层负载均衡
通过重新发起http请求实现，即client把请求发给lb，lb把请求代发给server，再把server的响应返回给client，因此七层负载均衡也经常被称为代理，七层负载均衡设备也被称为代理设备。
七层负载均衡常用于内网与外网的通信，比如内网无法直接访问外网，需要通过代理设备代发http请求，这种情况下，代理设备需要配置双网卡，以同时与内外网络通信。
由于山宽需要重发http请求，七层负载均衡性能较差，但是更智能和安全，因为应用层可以获取甚至修改请求的真实内容（即应用数据），比如cookie、url等，可以做一些智能的操作，比如根据cookie/url转发请求，也可以做一些安全操作，比如过滤特定报文、防止SYN Flood攻击等。
使用七层负载均衡时，服务的性能受限于代理设备的网卡带宽。
常见的负载均衡策略，有轮询、加权轮询、ip_hash、cookie、url_hash，根据服务器响应时间转发、根据最少连接转发等等。
备注：nginx可以安装第三方插件，使用第三方实现的策略
轮询：按服务器列表顺序转发请求，轮询是nginx默认的策略，本策略适合服务器配置相当、请求无状态（即不依赖session）的场景
加权轮询：如果不同服务器配置不同，可以为配乱睁置高的服务器增加权重
ip_hash：根据ip哈希结果转发，可以实现同一用户持续请求同一服务器（即会话保持），适合有状态（即依赖session）的场景，对png、jpg、js、css等静态资源的请求，不适合使用本策略
cookie：根据特定cookie转发请求，一般也是用于实现会话保持，比如为服务器A、B分别增加service-flag=a、service-flag=b的cookie，后续请求根据cookie转发
可以参考 haproxy实现会话保持
url_hash：根据url哈希结果转发，同一个接口始终请求同一台服务器，一般配合缓存使用，缓存接口返回结果
根据服务器响应时间转发：优先转发到响应时间较快的服务器
根据最少连接转发：优先转发到连接数较少的服务器
F5有一些特有的负载均衡策略：利用从应用程序和服务器收集到的各项性能指标，分析并转发
负载均衡有两个步骤：
1.根据什么算法选择真实服务端，即负载均衡策略，如轮询、加权轮询、ip_hash、cookie、url_hash等；
2.把请求转发到真实服务器，转发方式有二层到七层负载均衡
keepalived软件一开始是专为lvs设计的，后来加入了可以实现高可用的VRRP (Virtual Router Rendancy Protocol ,虚拟路由器冗余协议）功能，因此，keepalived还可以作为nginx、haproxy、mysql等服务的高可用解决方案。
以nginx为例，为了防止nginx本身由于宕机等原因导致网站不可用，一般会搭两套nginx反向代理，用keepalived提供一个VIP。
一般情况下，VIP只在nginx主节点上工作，如果nginx主节点不可用了，VIP会自动漂移到从节点，自动漂移的原理即VRRP协议。
VIP漂移到从节点后，如果主节点恢复正常了，VIP是否漂移回主节点，取决于当前模式是抢占模式还是非抢占模式。
下图是一张简单的架构图，解释如下：
以上观点纯属个人意见，如果错误，欢迎指出，有些地方写的很简单，是因为我也不懂~
Ⅳ 用nginx作为负载均衡服务器，PHP代码放在哪
lnmp架构 直接放nginx的web文件夹中，通过cgi解析php返回给nginx，如果是lnmpa架构，就是多了个apache,nginx负责分发请求，然后apache调用php_mod解析php,最后返回给nginx
如果是负载均衡，nginx分发请求，每个请求可能请求不同的服务器，但是每个服务器的网站程序应该是一致的，并且每个服务器上都部署了php环境和程序，然后返回给请求者nginx输出页面。
Ⅵ Nginx反向代理实现负载均衡配置图解
负载均衡配置是超大型机器需要考虑的一些问题 同时也是数据安全的一种做法 下面我来介绍在nginx中反向代理 负载均衡配置图解 大家可参考本文章来操作首先简单的介绍下修改默认的nginx conf 大概在 ~ 行 去掉前面的#号 重启nginx
#location ~ php$ {# proxy_pass ;#}改为 location ~ php$ { proxy_pass // : ;}
分别访问 出现如下图已经能够针对不同请求访问服务器了
这样当我们访问 l的时候 前端的nginx会自动进行响应 当访问 /test php的时候(这个时候nginx目录下根本就没有该文件) 但是通过上面的设置location ~ php$(表示
访问php页面test php : 的Apache进行响应
访问目录phpMyAdmin下的页面的话 : 的Apache进行响应
修改原始默认的nginx conf的server模块部分（大概在 ~ 行）
#location ~ php$ {# proxy_pass ;#}修改为 location ^~ /phpMyAdmin/ { proxy_pass : ;} location ~ php$ { proxy_pass : ;}
上面第一个部分location ^~ /phpMyAdmin/ 表示不使用; index index
2.在配置文件nginx.conf的模块中添加服务器集群server cluster的定义。Tw.WinGWit.
upstream myCluster { server 192.168.2.3:8080 ; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}
表示这个server cluster包含3台服务器
3.然后在server模块中定义负载均衡
location ~ .php$ { proxy_pass //myCluster ; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}
proxy_pass //myCluster ; 这里的名字和上面的cluster的名字相同
配置好后，当访问页面，nginx目录下根本没有该文件，但是它会自动将其pass到myCluster定义的服务器群，分别由上述的3台服务器中的一台来做处理。
上面在定义upstream的时候每个server之后没有定义权重，表示两者均衡；如果希望某个更多响应的话，可以加weight
upstream myCluster { server 192.168.2.3:8080 weight=5; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}
这样表示5/7的几率访问第一个server,1/7访问第二个、第三个。另外还可以定义max_fails和fail_timeout等参数。
所以我们使用nginx的反向代理服务器reverse proxy server的功能，将其布置到多台apache server的前端。
nginx仅仅用来处理静态页面响应和动态请求的代理pass，后台的apache服务器来对前台pass过来的动态页面进行处理并返回给nginx。
Ⅶ 同台电脑nginx负载均衡后,第二个网站的PHP扩展启动不起来
1、upstream 名称最好不要用localhost
2、server_name 一般不带端口号的。
3、location ~ .php$ {} 里配置有点复杂，完全可以简化一下。
location~.php${
roothtml2;
fastcgi_pass127.0.0.1:9000;
fastcgi_indexindex.php;
includefastcgi.conf;
}