最新项目中发现，大量游戏玩家访问登录服务器时出现延迟，导致玩家无法登录，愿意可能是登录服务器性能达到极限。 所以目前想通过proxy的方式访问登录服务器集群，避免登录延迟。 1.下载haproxy最新版本 http://www.haproxy.org/download/1.5/src/haproxy-1.5.12.tar.gz 2.安装haproxy软件 tar zxvf haproxy-1.5.12.tar.gz cd haproxy-1.5.12 uname -a //查看linux内核版本, TARGET是内核版本，2.6就写作26 make TARGET=linux26 PREFIX=/usr/local/haproxy make install PREFIX=/usr/local/haproxy 3.配置haproxy mkdir /etc/haproxy/conf vim /etc/haproxy/conf/haproxy.cfg ###########全局配置######### global chroot /usr/local/haproxy daemon nbproc 1 group nobody user nobody pidfile /opt/haproxy/logs/haproxy.pid ulimit-n 65536 #spread-checks 5m #stats timeout 5m #stats maxconn 100 ########默认配置############ defaults mode tcp #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK retries 3 #两次连接失败就认为是服务器不可用，也可以通过后面设置 option redispatch #当serverId对应的服务器挂掉后，强制定向到其他健康的服务器 option abortonclose #当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接 maxconn 32000 #默认的最大连接数 timeout connect 5000ms #连接超时 timeout client 30000ms #客户端超时 timeout server 30000ms #服务器超时 #timeout check 2000 #心跳检测超时 log 127.0.0.1 local0 err #[err warning info debug] ########test1配置################# listen test1 bind 0.0.0.0:8008 mode tcp balance roundrobin server s1 127.0.0.1:8010 weight 1 maxconn 10000 check inter 10s server s2 127.0.0.1:8011 weight 1 maxconn 10000 check inter 10s server s3 127.0.0.1:8012 weight 1 maxconn 10000 check inter 10s ########test2配置################# listen test2 bind 0.0.0.0:8007 mode tcp balance roundrobin server s1 192.168.1.88:8010 weight 1 maxconn 10000 check inter 10s server s2 192.168.1.88:8011 weight 1 maxconn 10000 check inter 10s ########统计页面配置######## listen admin_stats bind 0.0.0.0:8099 #监听端口 mode http #http的7层模式 option httplog #采用http日志格式 #log 127.0.0.1 local0 err maxconn 10 stats refresh 30s #统计页面自动刷新时间 stats uri /stats #统计页面url:port/stats stats realm XingCloud\ Haproxy #统计页面密码框上提示文本 stats auth admin:admin #统计页面用户名和密码设置stats hide-version #隐藏统计页面上HAProxy的版本信息 4.配置启动脚本 vim /usr/local/haproxy/sbin/haproxy.sh #!/bin/sh cd /usr/local/haproxy/sbin /usr/local/haproxy/sbin/haproxy -f /etc/haproxy/conf/haproxy.cfg & 5.查看启动进程 ps -ef |grep haproxy 或者netstat -ntpl |grep haproxy 来检查haproxy是否启动成功！ ############################################################### 配置详解1 ####################全局配置信息######################## #######参数是进程级的,通常和操作系统（OS）相关######### global maxconn 20480 #默认最大连接数 log 127.0.0.1 local3 #[err warning info debug] chroot /var/haproxy #chroot运行的路径 uid 99 #所属运行的用户uid gid 99 #所属运行的用户组 daemon #以后台形式运行haproxy nbproc 1 #进程数量(可以设置多个进程提高性能) pidfile /var/run/haproxy.pid #haproxy的pid存放路径,启动进程的用户必须有权限访问此文件 ulimit-n 65535 #ulimit的数量限制 #####################默认的全局设置###################### ##这些参数可以被利用配置到frontend,backend,listen组件## defaults log global mode http #所处理的类别 (#7层 http;4层tcp ) maxconn 20480 #最大连接数 option httplog #日志类别http日志格式 option httpclose #每次请求完毕后主动关闭http通道 option dontlognull #不记录健康检查的日志信息 option forwardfor #如果后端服务器需要获得客户端真实ip需要配置的参数,可以从Http Header中获得客户端ip option redispatch #serverId对应的服务器挂掉后,强制定向到其他健康的服务器 option abortonclose #当服务器负载很高的时候,自动结束掉当前队列处理比较久的连接 stats refresh 30 #统计页面刷新间隔 retries 3 #3次连接失败就认为服务不可用,也可以通过后面设置 balance roundrobin #默认的负载均衡的方式,轮询方式 #balance source #默认的负载均衡的方式,类似nginx的ip_hash #balance leastconn #默认的负载均衡的方式,最小连接 contimeout 5000 #连接超时 clitimeout 50000 #客户端超时 srvtimeout 50000 #服务器超时 timeout check 2000 #心跳检测超时 ####################监控页面的设置####################### listen admin_status #Frontend和Backend的组合体,监控组的名称,按需自定义名称 bind 0.0.0.0:65532 #监听端口 mode http #http的7层模式 log 127.0.0.1 local3 err #错误日志记录 stats refresh 5s #每隔5秒自动刷新监控页面 stats uri /admin?stats #监控页面的url stats realm itnihao\ itnihao #监控页面的提示信息 stats auth admin:admin #监控页面的用户和密码admin,可以设置多个用户名 stats auth admin1:admin1 #监控页面的用户和密码admin1 stats hide-version #隐藏统计页面上的HAproxy版本信息 stats admin if TRUE #手工启用/禁用,后端服务器(haproxy-1.4.9以后版本) errorfile 403 /etc/haproxy/errorfiles/403.http errorfile 500 /etc/haproxy/errorfiles/500.http errorfile 502 /etc/haproxy/errorfiles/502.http errorfile 503 /etc/haproxy/errorfiles/503.http errorfile 504 /etc/haproxy/errorfiles/504.http #################HAProxy的日志记录内容设置################### capture request header Host len 40 capture request header Content-Length len 10 capture request header Referer len 200 capture response header Server len 40 capture response header Content-Length len 10 capture response header Cache-Control len 8 #######################网站监测listen配置##################### ###########此用法主要是监控haproxy后端服务器的监控状态############ listen site_status bind 0.0.0.0:1081 #监听端口 mode http #http的7层模式 log 127.0.0.1 local3 err #[err warning info debug] monitor-uri /site_status #网站健康检测URL,用来检测HAProxy管理的网站是否可以用,正常返回200,不正常返回503 acl site_dead nbsrv(server_web) lt 2 #定义网站down时的策略当挂在负载均衡上的指定backend的中有效机器数小于1台时返回true acl site_dead nbsrv(server_blog) lt 2 acl site_dead nbsrv(server_bbs) lt 2 monitor fail if site_dead #当满足策略的时候返回503,网上文档说的是500,实际测试为503 monitor-net 192.168.16.2/32 #来自192.168.16.2的日志信息不会被记录和转发 monitor-net 192.168.16.3/32 ########frontend配置############ #####注意,frontend配置里面可以定义多个acl进行匹配操作######## frontend http_80_in bind 0.0.0.0:80 #监听端口,即haproxy提供web服务的端口,和lvs的vip端口类似 mode http #http的7层模式 log global #应用全局的日志配置 option httplog #启用http的log option httpclose #每次请求完毕后主动关闭http通道,HA-Proxy不支持keep-alive模式 option forwardfor #如果后端服务器需要获得客户端的真实IP需要配置次参数,将可以从Http Header中获得客户端IP ########acl策略配置############# acl itnihao_web hdr_reg(host) -i ^(www.itnihao.cn|ww1.itnihao.cn)$ #如果请求的域名满足正则表达式中的2个域名返回true -i是忽略大小写 acl itnihao_blog hdr_dom(host) -i blog.itnihao.cn #如果请求的域名满足www.itnihao.cn返回true -i是忽略大小写 #acl itnihao hdr(host) -i itnihao.cn #如果请求的域名满足itnihao.cn返回true -i是忽略大小写 #acl file_req url_sub -i killall= #在请求url中包含killall=,则此控制策略返回true,否则为false #acl dir_req url_dir -i allow #在请求url中存在allow作为部分地址路径,则此控制策略返回true,否则返回false #acl missing_cl hdr_cnt(Content-length) eq 0 #当请求的header中Content-length等于0时返回true ########acl策略匹配相应############# #block if missing_cl #当请求中header中Content-length等于0阻止请求返回403 #block if !file_req || dir_req #block表示阻止请求,返回403错误,当前表示如果不满足策略file_req,或者满足策略dir_req,则阻止请求 use_backend server_web if itnihao_web #当满足itnihao_web的策略时使用server_web的backend use_backend server_blog if itnihao_blog #当满足itnihao_blog的策略时使用server_blog的backend #redirect prefix http://blog.itniaho.cn code 301 if itnihao #当访问itnihao.cn的时候,用http的301挑转到http://192.168.16.3 default_backend server_bbs #以上都不满足的时候使用默认server_bbs的backend ##########backend的设置############## #下面我将设置三组服务器 server_web,server_blog,server_bbs ###########################backend server_web############################# backend server_web mode http #http的7层模式 balance roundrobin #负载均衡的方式,roundrobin平均方式 cookie SERVERID #允许插入serverid到cookie中,serverid后面可以定义 option httpchk GET /index.html #心跳检测的文件 server web1 192.168.16.2:80 cookie web1 check inter 1500 rise 3 fall 3 weight 1 #服务器定义,cookie 1表示serverid为web1,check inter 1500是检测心跳频率rise 3是3次正确认为服务器可用, #fall 3是3次失败认为服务器不可用,weight代表权重 server web2 192.168.16.3:80 cookie web2 check inter 1500 rise 3 fall 3 weight 2 #服务器定义,cookie 1表示serverid为web2,check inter 1500是检测心跳频率rise 3是3次正确认为服务器可用, #fall 3是3次失败认为服务器不可用,weight代表权重 ###################################backend server_blog############################################### backend server_blog mode http #http的7层模式 balance roundrobin #负载均衡的方式,roundrobin平均方式 cookie SERVERID #允许插入serverid到cookie中,serverid后面可以定义 option httpchk GET /index.html #心跳检测的文件 #服务器定义: #cookie 1表示serverid为web1, #check inter 1500是检测心跳频率 #rise 3是3次正确认为服务器可用, #fall 3是3次失败认为服务器不可用, #weight代表权重 server blog1 192.168.16.2:80 cookie blog1 check inter 1500 rise 3 fall 3 weight 1 server blog2 192.168.16.3:80 cookie blog2 check inter 1500 rise 3 fall 3 weight 2 ###################################backend server_bbs############################################### backend server_bbs mode http #http的7层模式 balance roundrobin #负载均衡的方式,roundrobin平均方式 cookie SERVERID #允许插入serverid到cookie中,serverid后面可以定义 option httpchk GET /index.html #心跳检测的文件 #服务器定义, #cookie 1表示serverid为web1, #check inter 1500是检测心跳频率 #rise 3是3次正确认为服务器可用, #fall 3是3次失败认为服务器不可用, #weight代表权重 server bbs1 192.168.16.2:80 cookie bbs1 check inter 1500 rise 3 fall 3 weight 1 server bbs2 192.168.16.3:80 cookie bbs2 check inter 1500 rise 3 fall 3 weight 2 配置例子2 ###########全局配置######### global daemon nbproc 1 pidfile /var/run/haproxy.pid ########默认配置############ defaults mode http #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK retries 2 #两次连接失败就认为是服务器不可用，也可以通过后面设置 option redispatch #当serverId对应的服务器挂掉后，强制定向到其他健康的服务器 option abortonclose #当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接 maxconn 4096 #默认的最大连接数 timeout connect 5000ms #连接超时 timeout client 30000ms #客户端超时 timeout server 30000ms #服务器超时 #timeout check 2000 #=心跳检测超时 log 127.0.0.1 local0 err #[err warning info debug] ########统计页面配置######## listen admin_stats bind 0.0.0.0:1080 #监听端口 mode http #http的7层模式 option httplog #采用http日志格式 #log 127.0.0.1 local0 err maxconn 10 stats refresh 30s #统计页面自动刷新时间 stats uri /stats #统计页面url stats realm XingCloud\ Haproxy #统计页面密码框上提示文本 stats auth admin:admin #统计页面用户名和密码设置 stats hide-version #隐藏统计页面上HAProxy的版本信息 ########test1配置################# listen test1 bind 0.0.0.0:90 mode tcp #maxconn 4086 #log 127.0.0.1 local0 debug server s1 10.18.138.201:80 server s2 10.18.102.190:80 server s3 10.18.102.189:80 server s4 10.18.102.188:80 server s5 10.18.102.187:80 ########frontend配置############## ########test2配置################# listen test2 bind 0.0.0.0:91 mode tcp #maxconn 4086 #log 127.0.0.1 local0 debug server s1 10.18.138.130:80 weight 1 server s2 10.18.138.201:8080 weight 6 ########frontend配置############## 配置例子3 global maxconn 51200 #限制单个进程的最大连接数 chroot /usr/local/haproxy uid 99 #所属运行用户，默认99为nobody gid 99 #所属运行用户组，默认99为nobody daemon #让进程作为守护进程在后台运行 quiet nbproc 2 #指定作为守护进程运行时的进程数，推荐设置为与CPU核心数相同 pidfile //usr/local/haproxy/haproxy.pid defaults mode http #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK #retries 2 #两次连接失败就认为是服务器不可用，也可以通过后面设置 option redispatch #当serverId对应的服务器挂掉后，强制定向到其他健康的服务器 option abortonclose #当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接 timeout connect 5000ms #连接超时 timeout client 30000ms #客户端超时 timeout server 30000ms #服务器超时 #timeout check 2000 #=心跳检测超时 log 127.0.0.1 local0 err #[err warning info debug] balance roundrobin #负载均衡算法 #option httplog #日志类别,采用httplog #option httpclose #每次请求完毕后主动关闭http通道,ha-proxy不支持keep-alive,只能模拟这种模式的实现 #option dontlognull #option forwardfor #如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip listen www.123p6.cn 0.0.0.0:80 #运行的端口及主机名 mode http #使用http的7层模式 balance roundrobin #设置服务器负载分配算法 option httpclose option forwardfor option httpchk GET /keepalive.html #健康检测页面 server webapp1 192.168.1.101:80 weight 1 check inter 2000 rise 2 fall 3 server webapp2 192.168.1.102:80 weight 1 check inter 2000 rise 2 fall 3 # weight - 调节服务器的负重 # check - 允许对该服务器进行健康检查 # inter - 设置连续的两次健康检查之间的时间，单位为毫秒(ms)，默认值 2000(ms) # rise - 指定多少次连续成功的健康检查后，即可认定该服务器处于可操作状态，默认值 2 # fall - 指定多少次不成功的健康检查后，认为服务器为当掉状态，默认值 3 # maxconn - 指定可被发送到该服务器的最大并发连接数 listen localhost 0.0.0.0:8888 #监控页面的端口 mode http transparent stats refresh 30s #统计页面自动刷新时间 stats uri /haproxy-stats #监控页面的访问地址 stats realm Haproxy \ statistic #统计页面密码框上提示文本 stats auth haproxyadmin:haproxypass #统计页面用户名和密码设置 stats hide-version #隐藏统计页面上HAProxy的版本信息 参考： http://lanlian.blog.51cto.com/6790106/1305228 http://itnihao.blog.51cto.com/1741976/915537
在调试新的网站系统的时候遇到一个问题。就是在调用curl_exec()后出现502。然后马上编写了一个测试脚本： <?php $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'https://www.baidu.com'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_TIMEOUT, 10); $res = curl_exec($ch); print_r($res); exit; 发现，只要链接是https的，必然出现段错误，这也是导致502的原因。而http链接可以正常访问。 是从这里找到解决问题的方法的： https://bugs.php.net/bug.php?id=76416 也有人出现了相同的问题，官方提示说是系统curl使用的ssl库和php编译时使用的ssl库（opsnssl）不一至导致的。然后我查找了phpinfo信息，发现php使用的curl版本以及它使用的ssl库（openssl）版本： 然后查看PHP编译时的openssl版本: 这两个软件的openssl版本明显不一致，所以，下一步就是要么从新编译PHP，使用系统的openssl版本1.1.0g，要么重新编译安装curl，使用openssl版本1.0.2o。
前言 导入的数据,发现有些数据前面出现了?字符,这里使用mysql的replace函数来清除,当然你也可以使用trim函数。 步骤 语法 replace(object,search,replace) object 需要修改的字段 search 需要替换的字段 replace 替换后的字段 示例 #将tb_user表中的nickname字段里面的?替换成无 update `tb_user` set `nickname`=replace(`nickname`,'?','');
Haproxy概述 ha-proxy是一款高性能的负载均衡软件。因为其专注于负载均衡这一些事情，因此与nginx比起来在负载均衡这件事情上做更好，更专业。 Haproxy的特点 haproxy 作为目前流行的负载均衡软件，必须有其出色的一面。下面介绍一下ha-proxy相对LVS，Nginx等负载均衡软件的优点。 支持tcp / http 两种协议层的负载均衡，使得其负载均衡功能非常丰富。 支持8种左右的负载均衡算法，尤其是在http模式时，有许多非常实在的负载均衡算法，适用各种需求。 性能非常优秀，基于单进程处理模式（和Nginx类似）让其性能卓越。 拥有一个功能出色的监控页面，实时了解系统的当前状况。 功能强大的ACL支持，给用户极大的方便。 Haproxy算法 1.roundrobin 基于权重进行轮询,在服务器的处理时间保持均匀分布时,这是最平衡,最公平的算法.此算法是动态的,这表示其权重可以在运行时进行调整. 2.static-rr 基于权重进行轮询,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效.不过,其在后端服务器连接数上没有限制 3.leastconn 新的连接请求被派发至具有最少连接数目的后端服务器. Haproxy Nginx环境介绍（基于Centos7.x） Server1 192.168.179.101 Haproxy Server2 192.168.179.102 Web Server Nginx1 Server3 192.168.179.104 Web Server Nginx2 Haproxy的安装 #Centos7环境下安装你的haproxy软件 [root@master ~]# yum install epel* haproxy -y #我这里不演示keepalived,后面博客演示，这里只有一台haproxy,没有backup haproxy [root@localhost ~]# hostnamectl set-hostname master 192.168.179.101 haproxy Nginx安装部署 #192.168.179.103 104上部署Nginx systemctl stop firewalld && setenforce 0 wget -c http://nginx.org/download/nginx-1.16.1.tar.gz mv nginx-1.16.1.tar.gz /usr/src/ cd /usr/src/ tar xf nginx-1.16.1.tar.gz cd nginx-1.16.1 yum install -y gcc pcre pcre-devel openssl openssl-devel gd gd-devel ./configure --prefix=/usr/local/nginx make && make install /usr/local/nginx/sbin/nginx #修改主机名 [root@localhost ~]# hostnamectl set-hostname real-server1 192.168.179.103 nginx [root@localhost ~]# hostnamectl set-hostname real-server2 192.168.179.104 nginx #为了负载均衡结果更加清晰展示，修改html页面内容 [root@real-server1 ~]# /usr/local/nginx/sbin/nginx -s reload [root@real-server1 ~]# echo "this is http server nginx 192.168.179.103" > /usr/local/nginx/html/index.html [root@real-server1 ~]# vim /usr/local/nginx/conf/nginx.conf keepalive_timeout 0; [root@real-server2 ~]# vim /usr/local/nginx/conf/nginx.conf keepalive_timeout 0; [root@real-server2 ~]# echo "this is http server nginx 192.168.179.104" > /usr/local/nginx/html/index.html [root@real-server2 ~]# /usr/local/nginx/sbin/nginx -s reload Haproxy配置配置文件 [root@master ~]# cat /etc/haproxy/haproxy.cfg global log 127.0.0.1 local2 info pidfile /var/run/haproxy.pid maxconn 4096 user haproxy group haproxy daemon nbproc 1 defaults mode http log global retries 3 option redispatch timeout connect 60000 timeout client 60000 timeout server 60000 listen stats bind *:81 stats enable stats uri /haproxy stats auth lulei:123 log 127.0.0.1 local2 err stats admin if TRUE stats hide-version stats refresh 30s frontend web mode http bind *:80 option httplog log global option forwardfor option httpclose acl html url_reg -i \.html$ use_backend httpservers if html default_backend httpservers backend httpservers option redispatch option abortonclose cookie SERVERID SERVERID insert indirect nocache server http1 192.168.179.103:80 maxconn 2000 cookie server1 weight 1 check inter 1s rise 2 fall 2 server http2 192.168.179.104:80 maxconn 2000 cookie server2 weight 1 check inter 1s rise 2 fall 2 Haproxy配置详解 global部分： global log 127.0.0.1 local2 info pidfile /var/run/haproxy.pid maxconn 4096 user haproxy group haproxy daemon nbproc 1 □ log:全局的日志配置，local0是日志设备，info 表示日志级别。其中日志级别有err、warning、info、debug四种可选。这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备，记录日志等级为 info log指定收集哪个机器的log，log的收集是通过系统工具来实现的，在centos6版本之前以syslog来收集日志，6版本变为了rsysylog。这些都是用于收集系统的日志，local 0指定设备，info表示输出日志的级别，error级别是在报错的时候才会输出。info只要有正常信息都会进行输出 口 maxconn:设定每个haproxy进程可接受的最大并发连接数，此选项等同于Linux命令行选项"ulimit -n" maxconn：可接受的最大并发连接数（不是最大连接数），注意是针对haproxy进程来说的，相当于操作系统的ulimit -n，如果设置了maxconn 4096，那么linux ulimit -n 也要设置为大于等于4096 口 user/group:设置运行haproxy进程的用户和组，也可使用用户和组的uid和gid值来替代 口 nbproc:设置HAProxy启动时可创建的进程数,此参数要求将 HAProy运行模式设 置为"daemon"，默认只启动一个进程。根据使用经验,该值的设置应该小于服务器的CPU核数。创建多个进程能够减少每个进程的任务队列，但是过多的进程可能会导致进程的崩溃。 nbproc 1 #工作进程数量 cpu内核是几就写几 这个参数重要，设置haproxy启动的进程数。默认值是1，默认启动一个进程，如果访问量比较大需要将该值增加，这个值大小一般建议设置小于服务器cpu的核数，这个核数是物理核不是逻辑核，如两个4核cpu那就是8个核，也就是这个值最多设置为8，而不是通过超线程来实现。 创建过多的进程并不一定会有好的效果，进程数不能太大，也不能太小，最大不要超过cpu核数 创建过多的进程并不一定会有好的效果，进程数不能太大，也不能太小，最大不要超过cpu核数 口 pidfle:指定haproxy进程的pid文件,启动进程的用户必须有访问此文件的权限 default部分： 口 mode∶设置HAPoy实例默认的运行模式，有tcp、http、heath三个可选值。 口 tcp模式∶在此模式下，客户端和服务器端之间将建立一个全双工的连接，不 会对七层报文做任何类型的检查，默认为tcp模式，经常用于sSL、SSH、SMTP 等应用。 口 http模式∶在此模式下，客户端请求在转发至后端服务器之前将会被深度分析， 所有不与 RFC格式兼容的请求都会被拒绝。 口 health模式∶目前此模式基本已经废弃，不在多说。 口 retres∶设置连接后端服务器的失败重试次数。连接失败的次数如果超过这里设置 的值，HAProy 会将对应的后端服务器标记为不可用。此参数也可在后面backend部分进行设置. #健康检查。3次连接失败就认为服务器不可用，主要通过后面的check检查 口 timeout connect∶haproxy与后端服务器连接超时时间，如果在同一个局域网可设置较小的时间 口 timeout client∶与客户端的最长空闲时间,定义客户端与haproxy连接后，数据传输完毕，不再有数据传输，即非活动连接的超时时间 口 timeout server∶定义haproxy与上游服务器非活动连接的超时时间 口 timeout http-keep-alive:使用keepAlive连接 contimeout 5000：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，新版本的haproxy使用timeout connect替代，该参数向后兼容。 clitimeout 3000：设置连接客户端发送数据时的成功连接最长等待时间，默认单位是毫秒，新版本haproxy使用timeout client替代。该参数向后兼容。 srvtimeout 3000：设置服务器端回应客户度数据发送的最长等待时间，默认单位是毫秒，新版本haproxy使用timeout server替代。该参数向后兼容。 fronted部分 ： 这是HAProxy 配置文件的第三部分—fronted部分的配置 这部分通过 frortend 关键字定义了一个名为"web"的前端虚拟节点，下面介绍每个选项的含义。 口 bind *:81 监听端口，即haproxy提供web服务的端口，和lvs的vip端口类似 口 option httplog∶option httplog默认情况下haproxy不会记录http请求的，这不便于haproxy出现问题时候的排查与监控，这个就是记录http请求的日志，这个参数比较重要建议打开。 口 option forwardfor：HAProxy工作于反向代理模式，其发往服务器的请求中的客户端IP均为HAProxy主机的地址而非真正客户端的地址，这会使得服务器端的日志信息记录不了真正的请求来源，“X-Forwarded-For”首部则可用于解决此问题。HAProxy可以向每个发往服务器的请求上添加此首部，并以客户端IP为其value。（记录客户端IP在X-Forwarded-For头域中）如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip 口 option httpclose #每次请求完毕后主动关闭http通道，HA-Proxy不支持keep-alive模式 口 log global∶表示使用全局的日志配置，这里的"global"表示引用在HAPoxy配置文件global部分中定义的log选项配置格式 口defaut backend∶指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在backend段进行定义 口 acl html url_reg -i \.html$:acl策略配置 口 use_backend httpservers if html acl策略匹配相应 backend部分：backend用于定义一个名称为htmpool的后端服务器组，根据需要可以定义多个 backend httpservers option redispatch option abortonclose balance roundrobin cookie SERVERID SERVERID insert indirect nocache option httpchk GET /index.html server http1 192.168.179.103:80 maxconn 2000 cookie server1 weight 1 check inter 1s rise 2 fall 2 server http2 192.168.179.104:80 maxconn 2000 cookie server2 weight 1 check inter 1s rise 2 fall 2 option redispatch 此参数用于cookie保持的环境中。在默认情况下，HAProxy会将其请求的后端服务器的serverID插入cookie中，以保证会话的session持久性。而如果后端服务器出现故障，客户端的cookie是不会刷新的，这就会造成无法访问。此时，如果设置了此参数，就会将客户的请求强制定向到另外一台健康的后端服务器上，以保证服务正常 option abortonclose 此参数可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接 HAProxy支持的负载均衡算法： roundrobin 基于权重进行轮叫调度的算法 static-rr 基于权重进行轮叫调度的算法，不过此算法为静态算法，在运行时调整其服务器权重不会生效 source 基于请求源IP的算法。此算法先对请求的源IP进行HASH运算，然后将结果与后端服务器的权重总数相除后转发至某台匹配的后端服务器。这种方式可以使同一个客户端IP的请求始终转发到某特定的后端服务器 leastconn 此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法 ，例如数据库负载均衡 uri 此算法会对部分或整个URI进行HASH运算，再经过与服务器的总权重相除，最后转发到某台匹配的后端服务器上 uri_param 此算法会根据URL路径中的参数进行转发，这样可保证在后端真实服务器数据不变时，同一个用户的请求始终分发到同一台机器上 hdr 此算法根据HTTP头进行转发，如果指定的HTTP头名称不存在，则使用roundrobin算法 进行策略转发 cookie SERVERID 表示允许向cookie插入SERVERID，每台服务器的SERVERID可在下面的server关键字中使用cookie关键字定义 option httpchk GET /index.html 心跳检测的文件 server http1 192.168.179.103:80 maxconn 2000 cookie server1 weight 1 check inter 1s rise 2 fall 2 服务器定义，cookie 1表示serverid为server1，check inter 1s是检测心跳频率，rise 3是3次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重 server http2 192.168.179.104:80 maxconn 2000 cookie server2 weight 1 check inter 1s rise 2 fall 2 服务器定义，cookie 1表示serverid为server2，check inter 1s是检测心跳频率，rise 3是3次正确认为服务器可用，fall 3是3次失败认为服务器不可用，weight代表权重 Haproxy 日志的配置 两台机器都配置haproxy的日志:需要打开注释并添加 （如果有backup，backup上面也需要配置） [root@master ~]# vim /etc/rsyslog.conf # Provides UDP syslog reception #由于haproxy的日志是用udp传输的，所以要启用rsyslog的udp监听 $ModLoad imudp $UDPServerRun 514 找到 #### RULES #### 下面添加 local2.* /var/log/haproxy.log [root@master ~]# systemctl restart rsyslog [root@master ~]# systemctl restart haproxy [root@master ~]# tail -f /var/log/haproxy.log #实时查看日志 Jul 15 05:00:13 master systemd: Stopping HAProxy Load Balancer... Jul 15 05:00:13 master haproxy-systemd-wrapper: haproxy-systemd-wrapper: exit, haproxy RC=0 Jul 15 05:00:13 master systemd: Started HAProxy Load Balancer. Jul 15 05:00:13 master systemd: Starting HAProxy Load Balancer... Jul 15 05:00:13 localhost haproxy[16683]: Proxy stats started. Jul 15 05:00:13 localhost haproxy[16683]: Proxy web started. Jul 15 05:00:13 localhost haproxy[16683]: Proxy web started. Jul 15 05:00:13 localhost haproxy[16683]: Proxy httpservers started. Jul 15 05:00:15 localhost haproxy[16684]: Connect from 192.168.179.4:57940 to 192.168.179.101:81 (stats/HTTP) 测试是否配置成功查看结果
随着这个blog 放到网路上开始，SEO 也变得重要起来，而在SEO 里头，最重要的第一项重点就是meta 标签，这也是要告诉搜寻引擎和社群网站，你的blog 或是网站主旨是什么，作者是谁，分享的缩图是什么...等这些我们认为理所当然的资讯，毕竟这些搜寻引擎的蜘蛛和社群网站的人工智慧，现在还无法分辨你我网站内容的重点，因此我们必须靠这些meta 或结构化资料itemprop，来告诉它们。 本篇主要在介绍，如何正确设定分享文章到google plus 以及facebook 的标题、缩图与内文概要，因为有了这些正确的设定，分享到社群网站就不会跳出莫名其妙的缩图，同时在google 的搜寻，也会呈现作者的大头照与姓名，这些都是会吸引更多使用者浏览的好方法。 这是在我的网站header 里头，所加入的meta 标签： 其中以下这三行，是写给搜寻引擎看的(特别是google )，当中最重要的，就是rel="author"这一句，有写这一段，接下来我们就可以去去google plus进行互相认证的作业(也就是要让google plus确认这个网页的作者是你) 而认证的过程，可以点选google结构化资料测试工具连结，进行相关的认证作业，认证的过程其实也很简单，就是进入google plus的个人页面，点选「帐户」，点选「编辑个人资料」，接着将「连结」里头的「作品刊载于」，新增目前的网站，接着google plus就会去查询你的网站是否有放上rel="author"，如果有，就完成啰！ 而这三行是写给google plus 看的，分享到google plus 上头，就会正确显示 而这四行是写给facebook看的，分享到facebook上头，就会正确显示，如果发现都已经照着设定了，分享时仍有问题，可以点选Facebook Debugger进行查询和重新设定，完成后再次分享应该就不会有问题啰！ 当然meta 标签绝对不止这一些，因为除了facebook 和google plus，还有一个世界前三大的社群平台twitter，以下列出在这些平台上完整的meta 标签语法，如果有需要也可以都加进自己的网站喔！ Page Title. Maximum length 60-70 characters 更多的资讯也可以参考这个网站，会更有帮助和收获喔！ 文章转自 ： 墨少离 https://www.msl.la/archives/231/
通过nginx目录跳转实现：将旧分类URL跳转到新分类URL
调整了下栏目分类，具体调整如下： 合并 WINDOWS和LINUX分类 举例说明下： 比如我的Windows分类，分类目录是category/WindowsAndLinux，实际访问地址是：https://www.moyann.com/category/Windows/ 做了调整后，分类目录变为/category/WindowsAndLinux/,实际访问地址是：https://www.moyann.com/category/WindowsAndLinux/ 鉴于旧栏目地址已被百度等搜索引擎收录，直接放弃原有URL是不行的。 那么，我们就需要对新旧地址做下跳转。 这个跳转可以直接在nginx后台使用rewrite规则来实现。 具体代码如下： rewrite ^/category/Windows/$ /category/WindowsAndLinux/ permanent; rewrite ^/category/linux/$ /category/WindowsAndLinux/ permanent; 以上代码实现的是目录跳转，具体到某一个特定的URL的时候，“/category/Windows/”更换为具体的URL地址即可
cdn设置错误导致的重定向次数过多的问题
今天，我百度云加速接入后，发现访问www.94qy.net 会显示重定向次数过多的问题，但我并没有修改ngnix的相关配置。 关于公司站点的ngnix重定向设置了两个地方，分别是http->https 和 非www开头->www开头，两个地方的配置分别如下： # http->https 重定向 if ($server_port !~ 443){ rewrite ^(/.*)$ https://$host$1 permanent; } # 非www开头->www开头 if ($host ~ '^94qy.net'){ return 302 http://www.94qy.net$request_uri; } 这两个配置肯定是没问题的，之前一直在用。 最后检查的原因是，百度云加速的https设置为了半程加密导致的问题。 使用cdn这类工具，其实即使服务器上不部署ssl证书都可以实现ssl访问，如果是半程加密以我的博客为例，访问过程如下： https://www.94qy.net （浏览器） -> 阿里云cdn（进行校验证书是否有效）---回源--> 服务器（80端口） 可以看到这里回源的服务器的80端口，而非443端口，这就是半程加密。 所以为什么导致重定向次数过多的原因就知道了。 https://www.94qy.net -> 服务器80端口-> 触发rewrite规则 -> https://www.94qy.net 导致循环。 同样的不加密、全程加密、严格加密的意义就很容易理解了。 如果选择不加密，访问https://www.94qy.net 浏览器会直接显示不支持https，不安全的链接之类的错误。 如果选择全程加密，这服务器上也必须要部署自签名的证书（cdn 回源的时候不校验服务器证书的合法性），如果服务器上面没有部署自签名的证书，浏览器就会显示不支持的证书之类的错误） 如果选择严格加密，则服务器需要部署受信任的 CA 证书，否则浏览器就会显示不支持的证书之类的错误
Nginx(读音engine x)服务器由于性能优秀稳定、配置简单以及跨平台，被越来越多的公司和个人所采用，现已成为市场份额继Apache之后的第二大Web服务器。各大小网站论坛博客也介绍说明了Nginx从安装到优化的各种配置。不过看了很多这些相关Nginx的文档之后，发现一个比较大的问题，就是这些文档基本也就从两个方面着手，一是修改Nginx的配置文件，二是调整操作系统的相关内核参数；而且文档说明也不够明了，缺乏比较系统级别的优化。本文将从Nginx源码编译安装开始，到修改配置文件，调整系统内核参数以及架构四个方面着手分别介绍如何优化。 一. 安装 (1) 精简模块 Nginx由于不断添加新的功能，附带的模块也越来越多。很多操作系统厂商为了用户方便安装管理，都增加了rpm、deb或者其他自有格式软件包，可以本地甚至在线安装。不过我不太建议使用这种安装方式。这虽然简化了安装，在线安装甚至可以自动解决软件依赖关系，但是安装后软件的文件布局过于分散，不便管理维护；同时也正是由于存在软件包之间的依赖关系，导致当有安全漏洞、或者其它问题，想要通过更新升级Nginx新版本时却发现yum、deb源还未发布新版本(一般都落后于官网发布的软件版本)。最重要的是采用非源码编译安装的方式，默认会添加入许多模块，比如邮件相关、uwsgi、memcache等等，很多网站运行时这些模块根本未用到，虽然平时占用的资源很小，但是仍然可能是压弯骆驼的一根稻草。各种非必需模块默认安装运行的同时，也给Web系统带来了安全隐患。尽量保持软件的轻装上阵，是每个运维应当尽力做到的，所以我建议一般常用的服务器软件使用源码编译安装管理。。我一般使用的编译参数如下，PHP相关模块fastcgi被保留用作后文优化说明，： ./configure \ "--prefix=/App/nginx" \ "--with-http_stub_status_module" \ "--without-http_auth_basic_module" \ "--without-http_autoindex_module" \ "--without-http_browser_module" \ "--without-http_empty_gif_module" \ "--without-http_geo_module" \ "--without-http_limit_conn_module" \ "--without-http_limit_req_module" \ "--without-http_map_module" \ "--without-http_memcached_module" \ "--without-http_proxy_module" \ "--without-http_referer_module" \ "--without-http_scgi_module" \ "--without-http_split_clients_module" \ "--without-http_ssi_module" \ "--without-http_upstream_ip_hash_module" \ "--without-http_upstream_keepalive_module" \ "--without-http_upstream_least_conn_module" \ "--without-http_userid_module" \ "--without-http_uwsgi_module" \ "--without-mail_imap_module" \ "--without-mail_pop3_module" \ "--without-mail_smtp_module" \ "--without-poll_module" \ "--without-select_module" \ "--with-cc-opt='-O2'" 编译参数根据网站是否真正用到的原则增添或者减少，比如我们公司如果需要用到ssi模块,从而能够实现访问shtml页面，可以将第17行删除，那么Nginx将默认安装。大家可以通过运行 "./configure --help" 查看编译帮助，决定是否需要安装哪些模块。 (2) GCC编译参数优化 [可选项】 GCC总共提供了5级编译优化级别： -O0: 无优化。 -O和-O1: 使用能减少目标代码尺寸以及执行时间并且不会使编译时间明显增加的优化。在编译大型程序的时候会显著增加编译时内存的使用。 -O2: 包含-O1的优化并增加了不需要在目标文件大小和执行速度上进行折衷的优化。编译器不执行循环展开以及函数内联。此选项将增加编译时间和目标文件的执行性能。 -Os: 可以看成 -O2.5，专门优化目标文件大小，执行所有的不增加目标文件大小的-O2优化选项，并且执行专门减小目标文件大小的优化选项。适用于磁盘空间紧张时使用。但有可能有未知的问题发生，况且目前硬盘容量很大，常用程序无必要使用。 -O3: 打开所有 -O2 的优化选项外增加 -finline-functions、-funswitch-loops、-fgcse-after-reload 优化选项。相对于 -O2 性能并未有较多提高，编译时间也最长，生成的目标文件也更大更占内存，有时性能不增反而降低，甚至产生不可预知的问题(包括错误)，所以并不被大多数软件安装推荐，除非有绝对把握方可使用此优化级别。 修改GCC编译参数，提高编译优化级别，此方法适用于所有通过GCC编译安装的程序，不止Nginx。稳妥起见用 -O2，这也是大多数软件编译推荐的优化级别。查看Nginx源码文件 auto/cc/gcc，搜索NGX_GCC_OPT，默认GCC编译参数为-O，可以直接修改内容为NGX_GCC_OPT="-O2"或者在 ./configure配置时添加--with-cc-opt='-O2'选项。 二.配置 应用服务器的性能优化主要在合理使用CPU、内存、磁盘IO和网络IO四个方面，现在我们从Nginx配置文件 nginx.conf 入手进行优化： (1) 工作进程数的选择 指令：worker_processes 定义了Nginx对外提供web服务时的工作进程数。最优值取决于许多因素，包括（但不限于）CPU核心的数量、存储数据的硬盘数量及负载模式。不能确定的时候，将其设置为可用的CPU内核数将是一个好的开始（设置为“auto”将尝试自动检测它）。Shell执行命令 ps ax | grep "nginx: worker process" | grep -v "grep" 可以看到运行中的Nginx工作进程数，一般建议设置成服务器逻辑核心数，Shell执行命令 cat /proc/cpuinfo | grep processor | wc -l 可以检测出服务器逻辑核心总数，偷懒可以直接写auto，Nginx自适应。 (2) 是否绑定CPU 指令：worker_cpu_affinity 绑定工作进程到对应CPU核心，Nginx默认未开启CPU绑定。目前的服务器一般为多核CPU，当并发很大时，服务器各个CPU的使用率可能出现严重不均衡的局面，这时候可以考虑使用CPU绑定，以达到CPU使用率相对均匀的状态，充分发挥多核CPU的优势。top、htop等程序可以查看所有CPU核心的使用率状况。绑定样例： worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; (3) 打开文件数限制 指令：worker_rlimit_nofile 设定了每个Nginx工作进程打开的最大文件数，受限于系统的用户进程打开文件数限制，未设置则使用系统默认值。理论上应该设置为当前Shell启动进程的最大打开文件数除以Nginx的工作进程数。由于Nginx的工作进程打开文件数并不一完全均匀，所以可以将其设置成Shell启动进程的最大打开文件数。Shell执行命令 ulimit -n 可以查看当前登录Shell会话最大打开文件数数限制。Linux系统用户进程默认同时打开文件最大数为1024，这个值太小，访问量稍大就报“too many open files"。Shell执行命令先修改用户打开文件数限制： echo "* - nofile 65536" >> /etc/security/limits.conf 然后添加入/etc/profile如下两行内容，修改所有Shell和通过Shell启动的进程打开文件数限制： echo "ulimit -n 65536" >> /etc/profile Shell执行命令使当前Shell临时会话立即生效： ulimit -n 65536 (4) 惊群问题 指令：accept_mutex 如果 accept_mutex 指令值为 on 启用，那么将轮流唤醒一个工作进程接收处理新的连接，其余工作进程继续保持睡眠；如果值为 off 关闭，那么将唤醒所有工作进程，由系统通过use指令指定的网络IO模型调度决定由哪个工作进程处理，未接收到连接请求的工作进程继续保持睡眠，这就是所谓的“惊群问题”。Web服务器Apache的进程数很多，成百上千也是时有的事，“惊群问题”也尤为明显。Nginx为了稳定，参数值保守的设置为 on 开启状态。可以将其设置成Off 提高性能和吞吐量，但这样也会带来上下文切换增多或者负载升高等等其它资源更多消耗的后果。 (5) 网络IO模型 指令：use 定义了Nginx设置用于复用客户端线程的轮询方法(也可称多路复用网络IO模型)。这自然是选择效率更高的优先，Linux 2.6+内核推荐使用epoll，FreeBSD推荐使用kqueue，安装时Nginx会自动选择。 (6) 连接数 指令：worker_connections 定义了Nginx一个工作进程的最大同时连接数，不仅限于客户端连接，包括了和后端被代理服务器等其他的连接。官网文档还指出了该参数值不能超过 worker_rlimit_nofile 值，所以建议设置成和 worker_rlimit_nofile 值相等。 (7) 打开文件缓存 指令：open_file_cache 开启关闭打开文件缓存，默认值 off 关闭，强烈建议开启，可以避免重新打开同一文件带来的系统开销，节省响应时间。如需开启必须后接参数 max=数字，设置缓存元素的最大数量。当缓存溢出时，使用LRU(最近最少使用)算法删除缓存中的元素；可选参数 inactive=时间 设置超时，在这段时间内缓存元素如果没有被访问，将从缓存中删除。示例：open_file_cache max=65536 inactive=60s。 指令：open_file_cache_valid 设置检查open_file_cache缓存的元素的时间间隔。 指令：open_file_cache_min_uses 设置在由open_file_cache指令的inactive参数配置的超时时间内， 文件应该被访问的最小次数。如果访问次数大于等于此值，文件描述符会保留在缓存中，否则从缓存中删除。 (8) 日志相关 指令：access_log 和 error_log 当并发很大时，Nginx的访问日志和错误日志的保存肯定会造成对磁盘的大量读写，也将影响Nginx的性能。并发量越大，IO越高。这时候可以考虑关闭访问日志和错误日志，或者将日志保存到tmpfs文件系统里，或者减少保存的访问日志条目和错误日志的级别，从而避免磁盘IO的影响。关闭日志使用 access_log off。如必须保存日志，可以按每日或者每时或者其它时间段对日志做切割，这也可以减小IO，虽然可能效果不是特别大，不过因为日志文件尺寸变小了很多，也方便查阅或归档分析日志。一般线上环境建议错误日志设置为 error 或者 crit。自定义访问日志的条目和错误日志的级别，详细信息可以参阅官网或者网上其它文档，按需修改。 (9) 隐藏Nginx版本号 指令：server_tokens 开启或关闭“Server”响应头中输出的Nginx版本号。推介设置为 off，关闭显示响应头的版本号，对性能的提高有小小的裨益，主要还是为了安全起见，不被骇客找到版本号对应的漏洞，从而被攻击。 (10) 压缩相关 指令：gzip Nginx默认开启了gzip压缩功能。有可能很多人认为，开启gzip压缩会增加CPU的处理时间和负载。但是经过我们网站的测试发现，关闭了gzip压缩功能的Nginx虽然减少了CPU计算，节省了服务器的响应时间，但网站页面总体响应时间反而加长了，原因在于js和css、xml、json、html等等这些静态文件的数据传输时间的增长大大超过了服务器节省出来的响应时间，得不偿失。gzip on 开启压缩后，大约可以减少75%的文件尺寸，不但节省了比较多的带宽流量，也提高了页面的整体响应时间。所有建议还是开启。当然也不是所有的静态文件都需要压缩，比如静态图片和PDF、视频，文件本身就应当做压缩处理后保存到服务器。这些文件再次使用gzip压缩，压缩的比例并不高，甚至适得其反，压缩后文件尺寸增大了。CPU压缩处理这些静态文件增加占用的服务器响应时间绝大部分时候会超过了被压缩减小的文件尺寸减少的数据传输时间，不划算。是否需要对Web网站开启压缩，以及对哪些文件过滤压缩，大家可以通过使用HttpWatch、Firebug等等网络分析工具对比测试。 指令：gzip_comp_level 指定压缩等级，其值从1到9，数字越大，压缩率越高，越消耗CPU，负载也越高。9等级无疑压缩率最高，压缩后的文件尺寸也最小，但也是最耗CPU资源，负载最高，速度最慢的，这对于用户访问有时是无法忍受的。一般推荐使用1-4等级，比较折衷的方案。我们公司网站使用等级2。 指令：gzip_min_length 指定压缩的文件最小尺寸，单位 bytes 字节，低于该值的不压缩，超过该值的将被压缩。我们网站设置为1k，太小的文件没必要压缩，压缩过小尺寸文件带来增加的CPU消耗时间和压缩减少的文件尺寸降低的数据下载时间互相抵消，并有可能增加总体的响应时间。 指令：gzip_types 指定允许压缩的文件类型，Nginx配置目录 conf 下的 mime.types 文件存放了Nginx支持的文件类型，text/html类型文件，文件后缀为html htm shtml默认压缩。推荐配置：gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript。 (11) 浏览器缓存 指令：expires 设置HTTP应答中的“Expires”和“Cache-Control”头标。"Expires"一般结合"Last-Modified"使用。当设置了合理的expires配置时，浏览器第一次访问Web页面元素，会下载页面中的的静态文件到本机临时缓存目录下。第二次及之后再次访问相同URL时将发送带头标识"If-Modified-Since"和本地缓存文件时间属性值的请求给服务器，服务器比对服务器本地文件时间属性值，如果未修改，服务器直接返回http 304状态码，浏览器直接调用本地已缓存的文件；如果时间属性值修改了，重新发送新文件。这样就避免了从服务器再次传送文件内容，减小了服务器压力，节省了带宽，同时也提高了用户访问速度，一举三得。指令后接数字加时间单位，即为缓存过期时间；-1 表示永远过期，不缓存。强烈建议添加expires配置，过期时间的选择具体分析。我们公司的部分Nginx配置如下： location ~ .+\.(gif|jpg|jpeg|png|bmp|swf)$ { expires 30d; } location ~ .+\.(js|css|xml|javascript|txt|csv)$ { expires 30d; } 或者统一将静态文件放在固定目录下再对目录做location和expires，示例： location /static/ { expires 30d; } (12) 持久连接 指令：keepalive_timeout 启用Http的持久连接Keepalive属性，复用之前已建立的TCP连接接收请求、发送回应，减少重新建立TCP连接的资源时间开销。在此的建议是当网站页面内容以静态为主时，开启持久连接；若主要是动态网页，且不能被转化为静态页面，则关闭持久连接。后接数字和时间单位符号。正数为开启持久连接，0关闭。 (13) 减少HTTP请求次数 网站页面中存在大量的图片、脚本、样式表、Flash等静态元素，减少访问请求次数最大的优点就是减少用户首次访问页面的加载时间。可以采用合并相同类型文件为一个文件的办法减少请求次数。这其实属于Web前端优化范畴，应当由Web前段工程师做好相关静态文件的规划管理，而不是由运维来做。不过Nginx也可以通过安装阿里巴巴提供的Concat或者Google的PageSpeed模块实现这个合并文件的功能。我们公司并未使用合并功能，具体安装配置信息请查询网上相关文档，这里不再累述。Concat源代码网址：https://github.com/alibaba/nginx-http-concat/，PageSpeed源代码网址：https://github.com/pagespeed/ngx_pagespeed。 (14) PHP相关 Nginx不能直接解析PHP代码文件，需要调用FastCGI接口转给PHP解释器执行，然后将结果返回给Nginx。PHP优化本文暂不介绍。Nginx可以开启FastCGI的缓存功能，从而提高性能。 指令：fastcgi_temp_path 定义FastCGI缓存文件保存临时路径。 指令：fastcgi_cache_path 定义FastCGI缓存文件保存路径和缓存的其它参数。缓存数据以二进制数据文件形式存储，缓存文件名和key都是通过对访问URL使用MD5计算获得的结果。缓存文件先保存至fastcgi_temp_path指定的临时目录下，然后通过重命名操作移至fastcgi_cache_path指定的缓存目录。levels指定了目录结构,子目录数以16为基数；keys_zone指定了共享内存区名和大小，用于保存缓存key和数据信息；inactive指定了缓存数据保存的时间，当这段时间内未被访问，将被移出；max_size指定了缓存使用的最大磁盘空间，超过容量时将最近最少使用数据删除。建议fastcgi_temp_path和fastcgi_cache_path设为同一分区，同分区移动操作效率更高。示例： fastcgi_temp_path /tmp/fastcgi_temp; fastcgi_cache_path /tmp/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:16m inactive=30m max_size=1g; 示例中使用/tmp/fastcgi_temp作为FastCGI缓存的临时目录；/tmp/fastcgi_cache作为FastCGI缓存保存的最终目录；一级子目录为16的一次方16个，二级子目录为16的2次方256个；共享内存区名为cache_fastcgi，占用内存128MB；缓存过期时间为30分钟；缓存数据保存于磁盘的最大空间大小为1GB。 指令：fastcgi_cache_key 定义FastCGI缓存关键字。启用FastCGI缓存必须加上这个配置，不然访问所有PHP的请求都为访问第一个PHP文件URL的结果。 指令：fastcgi_cache_valid 为指定的Http状态码指定缓存时间。 指令：fastcgi_cache_min_uses 指定经过多少次请求相同的URL将被缓存。 指令：fastcgi_cache_use_stale 指定当连接FastCGI服务器发生错误时，哪些情况使用过期数据回应。 指令：fastcgi_cache 缓存使用哪个共享内存区。 我常用nginx.conf模板，大家根据情况做适当修改： user nginx nginx; worker_processes auto; error_log logs/error.log error; pid logs/nginx.pid; worker_rlimit_nofile 65536; events { use epoll; accept_mutex off; worker_connections 65536; } http { include mime.types; default_type text/html; charset UTF-8; server_names_hash_bucket_size 128; client_header_buffer_size 4k; large_client_header_buffers 4 32k; client_max_body_size 8m; open_file_cache max=65536 inactive=60s; open_file_cache_valid 80s; open_file_cache_min_uses 1; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log logs/access.log main; sendfile on; server_tokens off; fastcgi_temp_path /tmp/fastcgi_temp; fastcgi_cache_path /tmp/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128m inactive=30m max_size=1g; fastcgi_cache_key $request_method://$host$request_uri; fastcgi_cache_valid 200 302 1h; fastcgi_cache_valid 301 1d; fastcgi_cache_valid any 1m; fastcgi_cache_min_uses 1; fastcgi_cache_use_stale error timeout http_500 http_503 invalid_header; keepalive_timeout 60; gzip on; gzip_min_length 1k; gzip_buffers 4 64k; gzip_http_version 1.1; gzip_comp_level 2; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; server { listen 80; server_name localhost; index index.html; root /App/web; location ~ .+\.(php|php5)$ { fastcgi_pass unix:/tmp/php.sock; fastcgi_index index.php; include fastcgi.conf; fastcgi_cache cache_fastcgi; } location ~ .+\.(gif|jpg|jpeg|png|bmp|swf|txt|csv|doc|docx|xls|xlsx|ppt|pptx|flv)$ { expires 30d; } location ~ .+\.(js|css|html|xml)$ { expires 30d; } location /nginx-status { stub_status on; allow 192.168.1.0/24; allow 127.0.0.1; deny all; } } } 三.内核 Linux内核参数部分默认值不适合高并发，一般临时方法可以通过调整/Proc文件系统，或者直接修改/etc/sysctl.conf配置文件永久保存。调整/Proc文件系统，系统重启后还原至默认值，所以不推荐。Linux内核调优，主要涉及到网络和文件系统、内存等的优化，下面是我常用的内核调优配置： grep -q "net.ipv4.tcp_max_tw_buckets" /etc/sysctl.conf || cat >> /etc/sysctl.conf << EOF ######################################## net.core.rmem_default = 262144 net.core.rmem_max = 16777216 net.core.wmem_default = 262144 net.core.wmem_max = 16777216 net.core.somaxconn = 262144 net.core.netdev_max_backlog = 262144 net.ipv4.tcp_max_orphans = 262144 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_max_tw_buckets = 10000 net.ipv4.ip_local_port_range = 1024 65500 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 600 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_mem = 786432 1048576 1572864 fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.sem = 250 32000 100 128 vm.swappiness = 10 EOF sysctl -p 详细说明大家可以查看我的Linux内核优化文章：https://www.moyann.com/archives/130/ 四.架构 Nginx的最大优势在于处理静态文件和代理转发功能，支持7层负载均衡和故障隔离。 动静分离是每个网站发展到一定规模之后必然的结果。静态请求则应当最好将其拆分，并启用独立的域名，既便于管理的需要，也便于今后能够快速支持CDN。如果一台Nginx性能无法满足，则可以考虑在Nginx前端添加LVS负载均衡，或者F5等硬件负载均衡（费用昂贵，适合土豪公司单位），由多台Nginx共同分担网站请求。还可以考虑结合Varnish或者Squid缓存静态文件实现类似CDN功能。新版Nginx目前已经支持直接读写Memcache，可以编译安装时候选择添加此类模块，从而节省了转交给PHP或者JPS等动态程序服务器处理时间，提高效率的同时，减小了动态服务器的负载。
网页点线粒子插件-网站背景鼠标点线窝巢特效-canvas-nest.js
color=”255,0,0” 背景粒子线的颜色值 opacity=”0.5” 背景粒子线的透明度，一般设置成0.5-1之间 count=”99” 背景粒子线的密度，建议不要太大，否则页面容易卡死 zIndex="-1" 背景的z-index属性，css属性用于控制所在层的位置