1、守护进程相对稳定,重连机制做得好
2、跟php交互基本用module,在php上不用配置太多参数
3、相对nginx,重写(rewrite)支持更好
4、采用module,可拓展性更强,可以在任一阶段插入钩子增加灵活性。
1、由于使用module形式加载,导致整个项目比较重
2、同步阻塞模型,容易导致进程阻塞无法正常访问
3、新加入的模型event据传性能相当不错,但目前官方称仍属于调试阶段,并不建议在生产环境使用。
1、异步io处理模型,可以支持更高的并发
2、整体是个轻框架,反向代理一级棒(负载均衡)
3、采用php-fpm fastcgi模式连接php,负载量可以更大
1、守护进程由于给php-fpm做了,所以非常受限于php-fpm。一个输入参数可能会导致整个程序运行不下去
2、php-fpm要额外配置,排查问题多了一个环境需要排查
3、nginx可以执行rewrite,但性能没有apache那么好
3、apache的劣势
补充:I/O事件配置中 EPOLL:多路复用机制,进程协程+回调 实现了高并发能力
最大的连接数:4096 worker_connections 受到最大文件打开数 和 CPU 的制约
1、基于域名的虚拟主机
2、基于IP的虚拟主机
3、基于端口的虚拟主机
虚拟主机,适合在企业内网中,不使用在外网中
1、设置版本隐藏
2、虚拟主机:IP/端口/域名
3、日志分割
4、防盗链和盗链
5、缓存时间
6、网页压缩
7、修改用户和组
负载均衡:作用在自己身上
负载均衡的对象:Tomcat或PHP等
负载均衡服务器对外依然提供一个VIP(虚IP),
集群中不同的机器采用相同IP地址,但是机器的MAC地址不一样。
当负载均衡服务器接受到请求之后,
通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。
和二层负载均衡类似,负载均衡服务器对外依然提供一个VIP(虚IP),
但是集群中不同的机器采用不同的IP地址。
当负载均衡服务器接受到请求之后,根据不同的负载均衡算法,
通过IP将请求转发至不同的真实服务器。
四层负载均衡工作在OSI模型的传输层,
由于在传输层,只有TCP/UDP协议,这两种协议中除了包含源IP、
目标IP以外,还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后,
以后通过修改数据包的地址信息(IP+端口号)将流量转发到应用服务器。
七层负载均衡工作在OSI模型的应用层,应用层协议较多,
常用http、radius、dns等。七层负载就可以基于这些协议来负载。
这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡,
除了根据IP加端口进行负载外,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
NG代理前端 tomcat代理后端
global
http
server
location
来决定是否要进行负载均衡。
NG代理前端 tomcat代理后端
global
http
server
location
rewrite