通过清心醉
首先一张图，来看看常规的WEB请求：
以上规则，为每一个用户的请求，包括建立HTTP协议连接;
何为并发？并发其实就是短暂时间内进行访问，比如1-3秒内同时2000个用户执行以上操作，就是2000个实际并发；
何为访问量？访问量为非同一短暂时间内进行服务器的访问，比如有100个用户是17:00访问，又有100个用户是17:01分访问，实际2分钟内就有200个访问量，但实际并发量只有100；
注：高并发如果为真实用户访问即会消耗系统、带宽等资源；如果非法访问，就是所谓的DDOS攻击，即1秒内发起10000+的伪用户进行网站访问，消耗服务器所有资源，导致其他用户打不开，包括服务器宏机！
附：
针对高并发，吞吐量来说，大家都知道使用NGINX，因为占用内存资源少，如果是APACHE，会浪费过多的内存资源，基于带宽来说，消费的基本都是同等的！
通过清心醉
刚在配置盼盈信息港的时候，出现了404，这页面不陌生。
首先看看NGINX的配置吧：
server {
listen 80;
server_name ipanying.cn *.ipanying.cn;
location / {
root /var/webs/ipanying/public_html/;
index index.php index.html index.htm;
location ~ .*\.(js|css)$ {
access_log off;
expires 1d;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
access_log off;
expires 3d;
}
location ~ .*\.(php?|cgi|pl|py)$ {
proxy_pass http://127.0.0.1:9999;
proxy_set_header Host $host;
}
}
}
很清楚的看到location ~ .*\.(php?|cgi|pl|py)$反向请求给APACHE的9999端口
因为APACHE端口默认是80，而我修改成127.0.0.1:9999
自认没错啊，因为9999端口只允许内网访问（即外网无法非法获取，甚至我可以在NGINX进行更多的负载均衡的反向请求）；
在根目录内放个文件打印phpinfo()却没问题；这让我联想到反向请求的根本，问题自然就清晰了！
location ~ .*\.(php?|cgi|pl|py)$居然都把请求发向转发给APACHE了，而伪静态是.html做结尾，自然而然该页面是由NGINX进行动作！可是NGINX对伪静态之后的.html文件进行数据解析，却是不存在的。
所以，以下的这段
location ~ .*\.(php?|cgi|pl|py)$ {
proxy_pass http://127.0.0.1:9999;
proxy_set_header Host $host;
}
明显就有问题。如果是针对DEDE这种国产高I/O开销的纯静态页面是可以进行的，因为静态.html文件是实实在在存在的。所以针对动态伪静态，应该修改为：
#location ~ .*\.(php?|cgi|pl|py)$ {
proxy_pass http://127.0.0.1:9999;
proxy_set_header Host $host;
#}
没错，注释掉就解决问题！
如果你有更多的服务器配置问题，欢迎咨询，LANMP任意组合任意版本！
通过清心醉
负载均衡器扩展
可以通过将DNS指向多个IP以及使用DNS轮循查找IP地址的方式来实现负载均衡器的横向扩展。或者可以使用多级负载均衡，使上一级负载均衡器来分发至下一级负载均衡器，但使用多个负载均衡器的情况比较少，主要是由于Web容器一般可以处理几千并发请求，而使用nginx或者HAProxy的单个负载均衡器可以处理超过20000的并发请求，因此单个负载均衡器完全可以代理多个web应用。
数据库功能扩展
数据库功能扩展是非常常用的方式，但是扩展数据库功能（比如创建存储过程或自定义函数）都会给数据层带来额外开销以及增加数据层的复杂性。
关系型数据库
关系型数据库可以通过主从同步的模式实现扩展，主库以写入数据为主，从库只做读操作。但是，如果业务量比较大时主从同步模式所提供的扩展能力非常有限，此外，开发人员还需要通过数据库拆分技术来进一步满足业务需求。
NoSQL
CAP定理（译者注：不熟悉的读者可通过谷歌查阅）告诉我们一个应用不可能同时满足一致性、可用性、分区容错性三个要求。而NoSQL一般则是通过牺牲一定的一致性来获得更高可用性以及更好的分区容错性。
数据库拆分
数据库拆分可以垂直拆分和水平拆分：
垂直拆分（Partitioning）：根据领域模型概念的基础可以将数据库拆分为几个松耦合的子库。例如，拆分为消费者数据库、产品数据库。另一种垂直拆分数据库的方式是将一个实体的一部分字段拆分出来作为一个新数据库，另一部分字段作为另一个数据库。例如，将消费者数据拆分为消费者联系信息和订单数据两部分。
水平拆分（Sharding）：可以根据数据的离散属性将数据进行水平分割。例如，消费者可以根据地域不同拆分为美国消费者数据库和欧洲消费者数据库。
将数据库从单个数据库使用分区或者sharding拆分为多个数据库是一项非常有挑战性的任务。
架构瓶颈
可扩展系统出现性能瓶颈的原因主要在于以下两方面：
中心化组件 应用中一个不可扩展的组件直接影响整个系统或者请求处理通道所能处理请求数的上限。
高延迟组件 一个高延迟的组件会影响整个系统响应时间的下限，使整个系统响应时间更长。通常解决这个问题的办法是使高延迟的组件作为后台任务线程或者使用异步队列来解决。
CPU消耗型应用
如果一个应用的吞吐量受CPU的限制，那么该应用就是CPU消耗型应用。此类引用通过增加CPU计算速度即可减少响应时间。
以下这些应用场景可能属于CPU消耗性：
需要计算或者处理数据而不需要做IO操作的应用（财务或者交易类系统）
非常依赖缓存而且不做任何IO操作的应用
异步（非阻塞）模型而且不需要等待外部资源的应用（被动应用或者使用NoJs的应用）
在以上使用场景中已经正常运行的应用，如果在一些应用场景中写了糟糕的或者效率低下的代码来对每次请求做大量额外的计算或者循环，那么这些应用的CPU占用率将非常高。但是通过分析应用可以很容易发现并修改效率低的问题。
IO消耗型应用
如果一个应用的吞吐量受IO或者网络操作影响而且提升CPU计算速度并不能减少响应时间，那么该应用即为IO消耗型应用。大多数应用是IO消耗型应用主要是由于要做增、删、改、查操作。而性能调优和对iO消耗型应用进行扩展也由于这些系统依赖于其他系统的下行流量变得非常困难。
以下这些应用场景可能是IO消耗性：
依赖数据库并进行增、删、改、查操作的应用
需要下行流量来完成本身操作的应用
让我们先来了解一些术语。稍后我将对Web应用扩展过程中所遇到的不同问题进行讲解，例如：
1:架构瓶颈
2:数据库扩展
3:CPU消耗型应用
4:IO消耗型应用
性能
Web系统的性能受多方面因素的影响，但大多数开发人员主要关心的是响应时间和可扩展性这两方面。
响应时间
响应时间是指Web应用从收到请求到返回响应结果所花费的时间。而应用系统应该在可接受的时间范围内返回响应结果，否则就不能算是一个性能良好的应用系统。
可扩展性
如果Web应用通过增加更多硬件可以使处理的请求数呈线性增长，那么该应用是可扩展的。
扩展的方式可以分为以下两种：
1) 纵向扩展（垂直扩展）：为单台机器增加CPU或者提高单台机器CPU性能。
2) 横向扩展（水平扩展）：增加服务器数量
垂直扩展 VS 水平扩展
一般情况下水平扩展比垂直扩展更重要，主要是因为普通硬件商品远比需要特殊配置的硬件便宜（比如大型机）；但是增强单个应用在一个硬件商品上处理的请求数同样也是比较重要的。同时，一个应用系统在不降低响应时间的前提下，如果通过添加更多的资源能够处理更多的请求，那么这个系统表现良好。
响应时间 VS 可扩展性
在同一个应用中，响应时间和可扩展性并不总是能够同时达到最好的效果。要么应用程序有可接受的响应时间但是不能处理超过一定数量的请求；要么应用程序可以处理大量请求，但是响应时间却不尽如人意，甚至非常糟糕。因此，通常情况下我们需要在这两个要素中寻求平衡点使我们的应用系统性能达到最佳状态。
容量规划
容量规划需要我们根据产品期望的负载量来预估所需要的硬件数量。除了整体的预估外，这通常还包括使用更少硬件时系统的性能表现情况以及单台机器下的性能的测试及评估。
架构扩展
如果Web应用的每一层在多层架构体系中都是可扩展的，那么该应用也具有可扩展性（横向扩展）。例如，如下图所示，我们就可以通过增加额外的资源来实现应用层和数据库层的线性扩展。
通过清心醉
接上文，上文作者写了实战LANMP负载均衡部署1-实现NGINX反向APACHE服务器集群，居然NGINX反向给了APACHE服务器的集群之后，我们就要考虑SESSION丢失的问题了
实战LANMP负载均衡部署2-NGINX结合MEMCACHE提供SESSION会话保留
首先我们需要给210的NGINX服务器添加MEMCACHE服务，用于存储缓存信息，
而220/230的服务器只需要添加PHP的MEMCACHE扩展，调用210服务器上的MEMCACHE
由于yum源要找过PHP5.3.3的memcache
所以作者编译过环境为PHP7
可以参考
php7添加memcache扩展
在这要特别说下：
memcache是一个服务
memcached是PHP的扩展支持
pecl-memcache-php7 安装在APACHE集群的220/230的服务器的PHP上
重启HTTPD，打印phpinfo查看是否已经启用了memcachee
然后切换会210的NGINX服务器
安装memcached-1.4.25 （记得yum install -y libevent-devel）
安装完成后启用：
/usr/local/bin/memcached -d -m 256 -l 192.168.0.210 -p 7788 -u root
IP必须为内网IP 127.0.0.1的话就只允许本机了
修改220/230的php.ini
session.save_handler = memcache;
session.save_path = “tcp://192.168.0.210:7788”;
不过建议在执行的PHP上动态修改：
ini_set(‘session.save_handler’, ‘memcache’);
ini_set(‘session.save_path’, ‘ tcp://192.168.0.210:7788’);
先来做个测试，看看SESSION是否可以共享：
修改220/230服务器的index.php内容为：
<?php
header(“Content-Type: text/html; charset=UTF-8”);
echo “当前反向请求的服务器IP为：”.$_SERVER[“SERVER_ADDR”].”<br>”;
ini_set(‘session.save_handler’, ‘memcache’); #修改SESSION的保存方式
ini_set(‘session.save_path’, ‘ tcp://192.168.0.210:7788’); #SESSION保存路径
session_start();
#unset($_SESSION[‘time’]); die();
#如果设置错误先把数据删除
$time=time(); #获取当前时间
if(!isset($_SESSION[‘time’])){ #如果不存在SESSION的时间
$_SESSION[‘time’]=$time; #赋值
}
echo “共享的SESSION[‘time’]的值=”.$_SESSION[‘time’].”<br>”;
#输出共享的SESSION[‘time’]
echo “现在的时间=”.time();
#输出当前的时间
?>
可以看到结果：
到现在为止，负载均衡的SESSION共享就算完成了，当然也包括数据缓存共享；
为了您的服务器敏感信息不泄漏，建议MEMCACHE只开启内网ＩＰ段
即/usr/local/bin/memcached -d -m 256 -l 192.168.0.210 -p 7788 -u root
如果是实际服务器，切记别使用：
/usr/local/bin/memcached -d -m 256 -l 外网IP -p 7788 -u root
因为缓存的数据很容易就被黑客抓取，所以如果不是使用服务器集群的话，建议别开启MEMCACHE
作者在说说，MEMCACHE是如何减轻数据库的瓶颈的，代码就不写了，思路写了自己琢磨下就懂了：
对SQL的操作，莫过“增删改查”
首先，每次SELECT的时候，先判断MEMCACHE里是否存在对应的KEY，存在提取值，这些值是怎么来的呢？
假设MEMCACHE内没有所需的值
数据库中提取，可以为数组也可以为字符串，然后Memcached::set(‘key’,’value’)写入KEY名称和对应的值，值可以为数组
那么下次再访问的时候，就先不直接读取数据库了
而是if(Memcached::get(‘key’,’value’))就可以判断是否存在，存在直接return即可。
比如说有留言什么的，就进行更新，更新之后同样更新下key的value即可
更多可以参考Memcached类
通过清心醉
本文只讲解进行负载均衡的反向代理及memcache的使用，至于MYSQL服务器的话，因为是直接使用PHP进行连接的，所以作者就不怎么讲解了
实战LANMP负载均衡部署1-实现NGINX反向APACHE服务器集群
本机：Windows 7
VM虚拟机： CentOS 64 * 3
修改本机的hosts文件，添加
192.168.0.210 www.ipanying.com
192.168.0.210 ipanying.com
负载均衡使用循环反向代理模式
因为实际项目部署的话，肯定不能使用IP，而且作者详细开发部署的时候，也是会对IP进行限定的
服务器的部署为yum源
服务器部署为：
192.168.0.210 NGINX实现负载均衡及memcache ＃只编译NGINX+memcache
#由于电脑只有8GB的内存，不能再开启更多的VM了
192.168.0.220 APACHE处理PHP程序 #只编译APACHE+PHP
192.168.0.230 APACHE处理PHP程序 #只编译APACHE+PHP
服务器：192.168.0.210
如果不会编译请参考yum安装nginx
service nginx restart
服务器：192.168.0.220/230
yum install -y httpd php php-mysql php-gd php-xml php-mbstring
service httpd restart
接着在两台APACHE服务器上的/var/www/html/添加index.php
vi /var/www/html/index.php
220的IP写入：
192.168.0.220 <br>
<?php echo phpinfo();?>
230的IP写入：
192.168.0.230 <br>
<?php echo phpinfo();?>
service iptables stop
关闭防火墙来访问： 你也可以设置220、230的IP服务器只允许210访问，具体细节自行GOOGLE
如果可以看到该数据，说明访问成功
看看NGINX是否运行正常： #记得关闭防火墙
访问：192.168.0.210
由于只对单一的站点测试，所以不需要修改太多的NGINX配置
本机访问：www.ipanying.com 因为hosts的关系，会跳转到192.168.0.210的服务器，然后根据反向条件反向请求给220/230服务器。
而且220/230的服务器的端口默认就为80
NGINX(210服务器上)
添加/var/www/html/index.php 空文件，因为PHP文件会进行反向给APACHE服务器集群
接着修改/etc/nginx/nginx.conf
在httpd{}节点内添加：
upstream ipanying{
server 192.168.0.220:80;
server 192.168.0.230:80;
}
修改/etc/nginx/conf.d/defautl.conf文件
server{}节点内添加：
location ~ .*\.(php?|cgi|pl|py)$ {
proxy_pass http://ipanying;
}
这时候，访问www.ipanying.com
输出的IP就不同了：
192.168.0.220 或 192.168.0.230
因为这两台服务器上的index.php文件最上面都有写入，看的出文字的变化
这样，NGINX反向PHP给APACHE集群的负载均衡就算完成了
注：APACHE集群内有的PHP文件在NGINX必须也存在，否则访问NGINX文件不存在就会403错误，除非URL直接添加才会反向给APACHE；
而且NGINX有PHP的代码文件存在，实际上是不响应任何请求动作的，只是作为一个反响跳转的一个需求而已
至于APACHE进行域名验证作者也不去写了，配置下vhost就是了，因为只是后端交互，所以没多大的关系，直接修改端口或者防火墙限制IP
通过清心醉
该方法主要涉及较多其实为NGINX的反向代理+负载均衡再加上APACHE的后端数据处理。
以下只为思路，更多细节的问题未能写出，作者以VM虚拟机进行多站点测试进行大数据网站服务器站群编写。
这作者假设我有4台服务器
服务器1：NGINX，作为反向代理+负载均衡+静态文件（比如IMG/JS/CSS等）； IP:192.168.1.200
服务器2：MYSQL数据集群；IP:192.168.1.220
服务器3：APACHE+PHP核心代码程序运行库 IP:192.168.1.231
服务器4：APACHE+PHP核心代码程序运行库 IP:192.168.1.232
首先，WEB的程序技术你得过关，能完整的划分开动、静态的文件
先来说说思路：
NGINX做为网站的主引导入口，用户访问的时候，NGINX反向代理请求给服务器3、4；
服务器响应过后，把数据返回给NGINX。
#注：在这里可以设置服务器3、4只允许服务器1的IP进行内网访问，服务器2因为是数据库服务器，所以只允许服务器3、4进行访问。而对外访问接口只提供NGINX一个对外接口。
居然NGINX请求给了3、4的APACHE＋PHP服务器，那么服务器3、4就必须连接MYSQL。（在这一点上如果你不知道PHP如何连接其他主机的MYSQL，那么我可以知道你没有程序的读写能力，劝你好好去学习学习吧）。
好了，服务器3、4请求服务器2的MYSQL毫无压力，服务器2的配置可以用最高配，因为数据库瓶颈一直也是个问题（当然也可以使用更多的服务器做MYSQL，进行MYSQL数据库的同步工作，瓶颈基本就可以得到很好的解决，因为作者没去了解过MYSQL数据同步，所以暂时以一台服务器做讲解）。
好吧，作者说说最大的问题点吧。
1：NGINX的负载均衡，把访问的请求均衡转发给服务器3、4；
方法1：循环反向代理模式
nginx.conf的http节点内添加：
upstream ipanying{
server 192.168.1.231:88;
server 192.168.1.232:88;
}
然后在server节点内
直接使用：
proxy_pass http://ipanying;
反向代理给IP=192.168.1.231和192.168.1.232的服务器
以上upstream使用的是循环制，即第一次访问的是231的IP，第二次访问的是232的IP，然后又回到231，以此类推。
方法2：根据访问IP的方式（推荐）
继续修改upstream模式：
upstream ipanying{
ip_hash;
server 192.168.1.231:88;
server 192.168.1.232:88;
}
作者为什么会推荐该模式，因为用户访问，可能会根据IP、COOKIE等做信息处理。
还有最主要的是如果有涉及登录模式的话，用户登录的SESSION所在的服务器集不一，这样一来的话，下次分发到另外的服务器的时候，可能会导致IP统计不准确或者SESSION丢失等问题。
更多的方法可以GOOGLE “upstream ”；
方法3：权重反向代理模式
修改上文中的：
upstream ipanying{
server 192.168.1.231:88 weight=2;
server 192.168.1.232:88 weight=10;
}
权重反向有什么好处呢？
比如231的IP的服务器只有4G内存，CPU只有2核，就不能进行太多的请求，如果使用循环制，怕跑太辛苦，
可是第二台权重=10又是什么意思
因为我第二台服务器有64G内存，24核CPU，我想更多的用户都主要以该服务器为主，偶尔转发几个给IP231的服务器，权重反向模式绝对是最佳模式；当然该方法仅适于展示的网站，不存在SESSION等信息的时候。
2：NGIXN的静态文件及服务器3、4动态文件的处理；
在这特别说下，服务器3、4只存在PHP和视图文件。不参与一切img\js\css等静态文件的存放，这些文件只能放在NGINX下
NGINX在进行均衡反向的时候，自身同时也把静态文件发送给用户。
比如登录PHP网站后台，生成的图片，上传的媒体文件等，通过方法放在NGINX的ROOT指定目录，这点就PHP的技术上来说，实现不难。
顺便贴下作者B2B的服务器群组部署：
/admin 管理员后台
/data 网站前台
/shangjia 商家后台
以上3目录只包含PHP和tpl和phtml文件，因为文件相同，分别部署服务器3、4
然后是NGINX
/img
/cssjs
实现的方法就是商家上传的图片，放在NGINX服务器的img内，这样就可以进行数据相应了。
作者上文写了Linux+Apache+Nginx+Mysql+Php真的适合所有的单一服务器网站吗？
利用NGINX的反向优势来进行评测，现在这篇文章是让更多的人知道，LANMP，适合的不是单一服务体，更多的是大群体服务器。
通过清心醉
NGINX由于占用资源少，并且吞吐/并发量是HTTP SERVER的老大。
一般的站点都会使用NGINX做前端，APACHE做后端。
但如果是一台服务器上做，有点白费心机。
比如WDCP等Linux+Apache+Nginx+Mysql+Php集成扩展。
为什么说白费心机，作者晚点会写个实战B2B模式使用Nginx+Apache站群进行网络群体覆盖的数据来详细说明。
NGINX居然做为反向代理，那么其最大的优势就是可以反向给APACHE、IIS（WINDOWS下作者没写过）等其他后端集，好吧，NGINX可以承载很大的吞吐并发量，特别针对静态数据。
问题来了，现在的站点9成以上使用的是伪静态数据，如果用户不进行缓存，每次的请求存在动态数据，一样会反向给APACHE等后端，APACHE后端同样进行动态操作，然后返回给NGINX，NGINX呈现给用户，这样，NGINX和APACHE等后端同样要占用资源来进行相应的操作，那么如此做，是不是有点多次一举？如果要说GZIP等压缩技术，APACHE完全都是可以胜任的。所以，单一服务器其实根本没必要使用LANMP组合，完全浪费系统资源，虽然APACHE来进行的话，占用资源高，释放慢，但基本都是可以保证相应需求的，而且NGINX反向给APACHE，APACHE释放资源慢的问题一样不会及时解决，那么，单一服务器/VSP有什么必要使用LANMP呢？
如果要说必须使用LANMP的必须条件，作者感觉只有DEDECMS这款程序了，使用的是生成完全的静态文件，就生成的时候数据库瓶颈有点大，生成之后是纯静态文件，这样，NGINX的性能优势就能完全的发挥出来，APACHE只是用户在进行动态操作及后端生成文件的时候占用会资源，但不久后就被释放。
提供给还在为系统架构烦恼的系统架构师们！
通过清心醉
作者的服务器为双核配置，内存就不说了：
以下数据以NGINX做反向代理所做优化
贴贴NGINX核心配置应该修改的参数：
worker_processes 2;
worker_cpu_affinity 01 10;
worker_processes 为开启的进程数；一般为CPU的核数。
worker_cpu_affinity 01 10为开启的CPU进行
当然，如果观察CPU的资源使用不是很大，可以开启4进程：
worker_processes 4;
worker_cpu_affinity 01 10 01 10;
请根据自身CPU的使用率来进行调节
2核是 01，四核是0001，8核是00000001，有多少个核，就有几位数，1表示该内核开启，0表示该内核关闭。 worker_processes最多开启8个，8个以上性能提升不会再提升了，而且稳定性变得更低，所以8个进程够用了。 配置完毕后，重启nginx 。
worker_processes: 官方英文版wiki配置说明中的描述如下，个人理解为worker角色的进程个数（nginx启动后有多少个worker处理http请求。master不处理请求，而是根据相应配置文件信息管理worker进程. master进程主要负责对外揽活（即接收客户端的请求），并将活儿合理的分配给多个worker，每个worker进程主要负责干活（处理请求））。 syntax:worker_processes number | auto; default: worker_processes 1; context:main Defines the number of worker processes.
接下来是worker_connections
控制每个进程打开的文件的数量，默认使用系统的配置1024为最大值。
测试最大的吞吐量的时候
max clients的公式=worker_processes*worker_connections/4
一般1024的值基本足够，不建议修改过大，作者修改为4096。
不过由于系统限制是1024，所以我们需要修改下LINUX的配置
否则重启NGINX就会报错：
[warn]: 3660#0: 4096 worker_connections are more than open file resource limit: 1024 !!
修改/etc/security/limits.conf文件，
在文件中添加如下行：
* soft noproc 4096
* hard noproc 4096
* soft nofile 4096
* hard nofile 4096
就是限制了任意用户的最大线程数和文件数为65535。 其中*（注意有个空格）为所有用户的打开文件数限制，可用’*’号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；10240则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后wq;
修改/etc/pam.d/login文件，在文件中添加如下行：
session required /lib/security/pam_limits.so
这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后wq。
修改/etc/rc.local脚本，在脚本中添加如下行：
echo “4096”> /proc/sys/fs/file-max
这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为4096
好了重启下
重新修改nginx.conf
events前面添加：
worker_rlimit_nofile 4096;
限制最大的文件数量
以下为作者完整的nginx.conf
worker_processes 2;
worker_cpu_affinity 01 10;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
worker_rlimit_nofile 4096;
events {
worker_connections 4096;
}
http {
server_tokens off;
include /usr/local/nginx/mime.types;
include /usr/local/nginx/proxy.conf;
include /usr/local/nginx/gzip.conf;
default_type application/octet-stream;
server_names_hash_bucket_size 128;
client_header_buffer_size 2k;
large_client_header_buffers 4 4k;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
sendfile on;
keepalive_timeout 65;
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 /var/log/nginx/access.log main;
#gzip on;
server {
listen 80 default_server;
server_name _;
return 404;
}
include /usr/local/nginx/conf.d/*.conf;
}
通过清心醉
作品前几篇文章写了：
针对作者开发的盼盈网，由于是B2B的模式，需要对泛域名的解析
而且作者刚重构了WEB架构。APACHE的泛解析作者在进行共享：
首先我们要知道，Nginx把动态数据反向请求给apache
<VirtualHost 127.0.0.1:88>
DocumentRoot /var/www/ipanying
ServerName ipanying.com
ServerAlias *.ipanying.com
</VirtualHost>
<Directory “/var/www/ipanying”>
Options Indexes FollowSymLinks ExecCGI Includes
AllowOverride All
Require all granted
</Directory>
如此一来，apache就可以无限解析ipanying.com的二级域名了。
通过清心醉
其实很简单，针对server_name进行标注下：
详细的NGINX泛解析请参考下述代码：
server {
listen 80;
server_name qingxinzui.com *.qingxinzui.com;
root /home/qingxinzui_blog;
index index.html index.php index.htm;
error_page 400 /errpage/400.html;
error_page 403 /errpage/403.html;
error_page 404 /errpage/404.html;
error_page 405 /errpage/405.html;
location ~ \.php$ {
proxy_pass http://127.0.0.1:88;
include naproxy.conf;
}
location / {
try_files $uri @apache;
}
location @apache {
proxy_pass http://127.0.0.1:88;
include naproxy.conf;
}
}
通过清心醉
为什么一定要使用Nginx,还有搭配的教程作者在NGINX+APACHE+PHP+MYSQL整合已经说过了.
可是配置ecshop真的好麻烦,主要麻烦在PHP不能使用超过5.3的版本,否则就是修改所有的核心代码,那工程量会要人命的.
首先根据作者链接中所说,安装nginx+apache
确保nginx是可以正常访问的,并且apache启动是无错误的
注:在这假设目录使用apache的默认目录/var/www/html
然后我们来安装mysql,由于centos自带的mysql可能有点老,所以如果可以的话update下
yum install mysql mysql-server
记得顺便修改下mysql的root密码
mysql -u root;
mysql> use mysql;
mysql> UPDATE user SET password= PASSWORD(‘新密码’) WHERE user = ‘root’;
mysql> FLUSH PRIVILEGES;
然后:service mysqld restart;
重新进入MYSQL创建个UTF的ECSHOP数据库
create database if not exists ecshop default charset utf8 collate utf8_general_ci;
至于安装PHP,其实ecshop对PHP的最大限制是php 5.3.3
直接yum 也可以.
编译准备工作 yum groupinstall “Development tools”
然后是编译安装 PHP 需要用到的 devel 包：
yum install libxml2-devel gd-devel libmcrypt-devel libcurl-devel openssl-devel
接下来下载对应的PHP
编译安装 php的参数：
进入PHP目录
./configure –with-apxs2=/usr/local/apache2/bin/apxs –disable-cli –enable-shared –with-libxml-dir –with-gd –with-openssl –enable-mbstring –with-mcrypt –with-mysqli –with-mysql –enable-opcache –enable-mysqlnd –enable-zip –with-zlib-dir –with-pdo-mysql –with-jpeg-dir –with-freetype-dir –with-curl –without-pdo-sqlite –without-sqlite3
make
make install
cp php.ini-production /usr/local/lib/php.ini
是时候让 apache 知道有 php 的存在了，在 apache 配置文件 httpd.conf 中添加：
LoadModule php5_module modules/libphp5.so
#上面那行可能在编译安装 php 的过程中已经由系统自动添加了
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
OK！重启 apache，人品好的人是不会出现问题的。
因为Nginx接收到的动态请求会转发给apache，所以不需要使用php-fpm，除非使用nginx+mysql+php的搭配。
好了，到此ecshop的Nginx+Apache+Mysql+Php环境配置完成。
通过清心醉
前言:我们都知道,如果要写代码开发,肯定是在WINDOWS下比较好,当然,就LINUX下来说,ZEND STUDIO也是很完善了的.
由于基本上使用的都是XAMPP快速部署环境,这样,在WINDOWS系统下,就会非常的缓慢,所以写出本教程
系统:Windows 8.1(分配IP192.168.1.234) + 虚拟机CentOS 6.5(分陪IP192.168.1.240)
域名:www.qingxinzui.com
Windows 8.1安装VM11,附载CentOs6.5系统,WEB服务器为:Apache+Nginx+Php+Mysql(在这作者假设你已经会搭配WEB环境)
上个星期作者有个文章说过,利用hosts文件来进行请求的转发.
在Windows 8系统里,我们首先利用hosts文件里添加以下跳转参数:
192.168.1.240 qingxinzui.com
192.168.1.240 www.qingxinzui.com
这时候只要访问作者本地的网站,就会跳转到IP为240的节点
好了,这时候如果CentOS系统里有站点信息并启用了服务的话,就可以实现了.
但因为作者的要求是要包含有域名的信息,而且作者使用了NGINX的域名绑定.所以我们需要修改下CentOS的hosts文件,参数和W8系统下的类似,只不过请求的IP为127.0.0.1
大概流程是:
W8系统请求访问网站,W8的hosts文件中存在跳转参数,实现以域名的方式跳转到指定的IP服务器,指定的IP服务器(CentOS系统)里的NGINX接收了域名访问的请求,再通过本身的hosts文件进行跳转到127.0.0.1
至此,双系统域名式访问站点部属完成.
通过清心醉
今天把网站移到了NGINX服务器内进行测试,结果发现无法请求HTTPS的微信扫描支付
忙活了大半天,一直以为NGINX+APACHE的CGI有问题
因为安装的是ECSHOP,使用的PHP版本是5.2
实在无奈的情况下,开启了两台虚拟机,并且实现curl -i进行https请求,以下是返回的结果:
PHP5.3以上的版本: 返回了200
[root@qingxinzui ~]# curl -i https://www.baidu.com/
HTTP/1.1 200 OK
Server: bfe/1.0.8.5
Date: Fri, 26 Jun 2015 07:00:08 GMT
Content-Type: text/html
Content-Length: 227
Connection: keep-alive
Last-Modified: Thu, 09 Oct 2014 10:47:57 GMT
Set-Cookie: BD_NOT_HTTPS=1; path=/; Max-Age=300
Set-Cookie: BIDUPSID=F793F4C31DFC52C0060BBE10533263B7; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: PSTM=1435302008; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BDSVRTM=0; path=/
P3P: CP=” OTI DSP COR IVA OUR IND COM “
X-UA-Compatible: IE=Edge,chrome=1
Pragma: no-cache
Cache-control: no-cache
BDPAGETYPE: 1
BDQID: 0x855891be0001f8c6
BDUSERID: 0
Accept-Ranges: bytes
Set-Cookie: __bsi=2018999903383799926_00_200_N_N_80_0301_002F_N_N_N_0; expires=Fri, 26-Jun-15 07:00:13 GMT; domain=www.baidu.com; path=/
<html>
<head>
<script>
location.replace(location.href.replace(“https://”,”http://”));
</script>
</head>
<body>
<noscript><meta http-equiv=”refresh” content=”0;url=http://www.baidu.com/”></noscript>
</body>
</html>
再来看PHP5.2的版本:
[root@qingxinzui ~]# curl -i https://baidu.com
HTTP/1.1 302 Moved Temporarily
Server: bfe/1.0.8.5
Date: Fri, 26 Jun 2015 07:10:13 GMT
Content-Type: text/html
Content-Length: 160
Connection: keep-alive
Location: http://www.baidu.com/
<html>
<head><title>302 Found</title></head>
<body bgcolor=”white”>
<center><h1>302 Found</h1></center>
<hr><center>bfe/1.0.8.5</center>
</body>
</html>
[root@qingxinzui ~]#
直接给我返回302错误,害哥白辛苦了一个上午,居然就是版本太低估计不符合CURL的要求.使用的是CURL 7.19
看来想要完美的跑起ECSHOP,要么就是修改核心让ECSHOP支持5.3 要么就只能重置PHP环境,比如使用WAMP这种,或者重新安装过其他兼容版的CURL!
通过清心醉
注:如果您的Nginx里有多个站点,请针对单一vhost里的站点.conf写
if (!-e $request_filename)
{
rewrite “^/index\.html” /index.php last;
rewrite “^/category$” /index.php last;
rewrite “^/feed-c([0-9]+)\.xml$” /feed.php?cat=$1 last;
rewrite “^/feed-b([0-9]+)\.xml$” /feed.php?brand=$1 last;
rewrite “^/feed\.xml$” /feed.php last;
rewrite “^/category-([0-9]+)-b([0-9]+)-min([0-9]+)-max([0-9]+)-attr([^-]*)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$” /category.php?id=$1&brand=$2&price_min=$3&price_max=$4&filter_attr=$5&page=$6&sort=$7&order=$8 last;
rewrite “^/category-([0-9]+)-b([0-9]+)-min([0-9]+)-max([0-9]+)-attr([^-]*)(.*)\.html$” /category.php?id=$1&brand=$2&price_min=$3&price_max=$4&filter_attr=$5 last;
rewrite “^/category-([0-9]+)-b([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$” /category.php?id=$1&brand=$2&page=$3&sort=$4&order=$5 last;
rewrite “^/category-([0-9]+)-b([0-9]+)-([0-9]+)(.*)\.html$” /category.php?id=$1&brand=$2&page=$3 last;
rewrite “^/category-([0-9]+)-b([0-9]+)(.*)\.html$” /category.php?id=$1&brand=$2 last;
rewrite “^/category-([0-9]+)(.*)\.html$” /category.php?id=$1 last;
rewrite “^/goods-([0-9]+)(.*)\.html” /goods.php?id=$1 last;
rewrite “^/article_cat-([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$” /article_cat.php?id=$1&page=$2&sort=$3&order=$4 last;
rewrite “^/article_cat-([0-9]+)-([0-9]+)(.*)\.html$” /article_cat.php?id=$1&page=$2 last;
rewrite “^/article_cat-([0-9]+)(.*)\.html$” /article_cat.php?id=$1 last;
rewrite “^/article-([0-9]+)(.*)\.html$” /article.php?id=$1 last;
rewrite “^/brand-([0-9]+)-c([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)\.html” /brand.php?id=$1&cat=$2&page=$3&sort=$4&order=$5 last;
rewrite “^/brand-([0-9]+)-c([0-9]+)-([0-9]+)(.*)\.html” /brand.php?id=$1&cat=$2&page=$3 last;
rewrite “^/brand-([0-9]+)-c([0-9]+)(.*)\.html” /brand.php?id=$1&cat=$2 last;
rewrite “^/brand-([0-9]+)(.*)\.html” /brand.php?id=$1 last;
rewrite “^/tag-(.*)\.html” /search.php?keywords=$1 last;
rewrite “^/snatch-([0-9]+)\.html$” /snatch.php?id=$1 last;
rewrite “^/group_buy-([0-9]+)\.html$” /group_buy.php?act=view&id=$1 last;
rewrite “^/auction-([0-9]+)\.html$” /auction.php?act=view&id=$1 last;
rewrite “^/exchange-id([0-9]+)(.*)\.html$” /exchange.php?id=$1&act=view last;
rewrite “^/exchange-([0-9]+)-min([0-9]+)-max([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$” /exchange.php?cat_id=$1&integral_min=$2&integral_max=$3&page=$4&sort=$5&order=$6 last;
rewrite “^/exchange-([0-9]+)-([0-9]+)-(.+)-([a-zA-Z]+)(.*)\.html$” /exchange.php?cat_id=$1&page=$2&sort=$3&order=$4 last;
rewrite “^/exchange-([0-9]+)-([0-9]+)(.*)\.html$” /exchange.php?cat_id=$1&page=$2 last;
rewrite “^/exchange-([0-9]+)(.*)\.html$” /exchange.php?cat_id=$1 last;
}
通过清心醉
为什么说是缓解,因为会出现错误要么就是带宽不够要么就是资源不够,除非无止境的加强硬件的配置,否则只能缓解服务器的性能优化
注:改方法针对任意Nginx(包括WDCP这种LNAMP一键安装环境)
首先修改nginx/conf/nginx.conf文件 准确目录不提供了,因为yum安装和LNAMP不一样,但NGINX后面目录是相同的.
在http{ 这里面写上下面的红字内容
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
}
因为504的错误是根本没有请求到网关,这里我们设置下超时的时间等参数,可以缓解下
然后是502的,502错误的网上很多了.
修改nginx/conf/php-fpm.conf里的两个参数
max_children = 50
request_terminate_timeout = 1000
#注,如果你使用的是LNAMP环境,修改nginx_php/etc/里的就可以.
max_children为php-cgi进程的数量,我用Magento这个大家伙基本也就24MB,1G内存的话其实设置为40比较好,这样php-cgi进程多了,处理速度就会快很多.否则处理不过来就出现了502
request_terminate_timeout为时间限制,如果不设置参数,php-cgi就会一直执行下去,如果像magento这种大家伙,不设置个时间那么php-cgi就会一直执行下去直到死掉,一死掉就又出现了502的错误了.
通过清心醉
LNAMP的组合的配置规则,其实好比WAMP的多PHP版本选择
比如MYSQL,有个默认的MYSQL配置,可以使用的是MYSQL5.1,但如果有升级安装MYSQL5.5
目录就会存在有:MYSQL,MYSQL5.1,MYSQL5.5
而默认的MYSQL就是当前使用的
好了言归正转
解压后,直接执行sh php_up53.sh
sh mysql_up55.sh
sh nginx_up.sh 1.8.0 #针对这个,以后可以根据NGINX发行的版本进行无止境的升级! 资料来自于网上
升级估计要2个钟的时间,PHP和MYSQL比较大,具体看你的VPS配置了.
针对升级MYSQL无法使用的问题:
vi /www/wdlinux/init.d/mysqld
查找:basedir= datadir=
修改为:
basedir=/www/wdlinux/mysql
datadir=/www/wdlinux/mysql/var
即可
通过清心醉
最近安装Ecshop,因为对PHP的版本要求比较低,又懒的配置服务器,于是使用快速LNAMP的部署环境.
安装也简单,解压直接执行脚本就可以自动安装.
然后通过访问IP:8080端来进入后台
先来说说创建站点吧
有一个是创建整站(包括WEB,FTP,MYSQL),一般是用于个人租了VPS做空间使用的多点.设置不同的数据库和FTP及站点目录的访问用户/密码.
当然这不是作者要说的,不过创建新站点雷同,只是新站点不受FTP,MYSQL限制,直接使用ROOT权限.
创建站点,需要弄以下几个:
1 域名:
2 绑定域名(比如带www和不带www,如果你的网站不支持跳转后面可以设置302)
3 目录(必须在写的目录里面的public_html文件夹里放站点资料)
4 使用IP(针对VPS多IP的解决方法,在系统设置里填写IP即可.)
至于还有一个就是安全问题,设置后台访问域名和端口,简直就是做废.
人家知道你的网站是WDCP做的,只要猜解端口,直接后面加上/phpmyadmin或者用IP的方式直接就可以打开PHPMYADMIN的访问页,等于直接暴露MYSQL给人家暴力破解,更无奈的是,如果后台被入侵,WDCP后台有执行SSH的权限,人家可以直接把你VPS给拿下.
说到这里,很多人会想到拦截,什么办法最好呢?当然拉
linux特有的.htaccess
直接在.htaccess写上访问IP,需要登陆的时候时候SSH连接修改下确.htaccess里面的文件允许IP即可.
通过清心醉
server {
root /home/www; #目录
index index.php;
server_name magento.example.com;
location / {
index index.html index.php;
try_files $uri $uri/ @handler;
expires 30d;
}
location ^~ /(app|includes|lib|media/downloadable|pkginfo|report/config.xml|var)/ { internal; }
location /var/export/ { internal; }
location /. { return 404; }
location @handler { rewrite / /index.php; }
location ~* .php/ { rewrite ^(.*.php)/ $1 last; }
location ~* .php$ {
if (!-e $request_filename) { rewrite / /index.php last; }
expires off;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param MAGE_RUN_CODE default;
fastcgi_param MAGE_RUN_TYPE store;
include fastcgi_params;
}
}