nginx 之 proxy_pass详解

在nginx中配置proxy_pass代理转发时,如果在proxy_pass后面的url加/,表示绝对根路径;如果没有/,表示相对路径,把匹配的路径部分也给代理走。
假设下面四种情况分别用 http://192.168.1.1/proxy/test.html 进行访问。
说明:http://127.0.0.1也可以改成对应的域名或加端口号
第一种:
location /proxy/ {
    proxy_pass http://127.0.0.1/;
       #header头参数也保持
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

代理到URL:http://127.0.0.1/test.html
第二种(相对于第一种,最后少一个 / )
location /proxy/ {
    proxy_pass http://127.0.0.1;
}

代理到URL:http://127.0.0.1/proxy/test.html
第三种:
location /proxy/ {
    proxy_pass http://127.0.0.1/aaa/;
}

代理到URL:http://127.0.0.1/aaa/test.html
第四种(相对于第三种,最后少一个 / )
location /proxy/ {
    proxy_pass http://127.0.0.1/aaa;
}

代理到URL:http://127.0.0.1/aaatest.html

PHP集群session共享

集群的概念没有多复杂,其实就是多台电脑为了同一个目标在一起工作。在Web应用中,就是多个服务器提供一个站点的服务。

搭建PHP集群的第一步就是设置负载均衡。首先我们需要三台主机:

Nginx负载:192.166.5.111
PHP应用1:192.168.5.112
PHP应用2:192.168.5.113

1

先前,在PHP应用所在的主机,我们需要安装Nginx或者apache等这类web服务器,然后再在前面使用Nginx作为负载。Nginx 负载和php应用之间的通信是在应用层的,Nginx负载其实就相当于一个代理。但是,现在情况不同了。Fastcgi技术的应用允许在php应用层可以不用再安装web服务器。现在PHP5.5版本已经将fpm作为内部模块支持了。在这种情况下,Nginx 负载和php应用之间的通信是在传输层的,二者之间使用socket进行通信。当然了,这需要fpm服务的支持。

2

Nginx设置

首先对Nginx(192.168.5.111)进行设置,编辑nginx.conf配置文件

http{
         ……
         upstream onmpw_phpApps{
            server 192.168.18.88:9000;
            server 192.168.18.191:9000;
        }
        ……
       Server{
         listen        80;
         server_name   load.onmpw.com   ##这里是域名
         root           /www/onmpw         
         ……
         location ~ \.php$ {
                   root         /www/onmpw   ##这里是PHP应用所在目录
                   fastcgi_pass   onmpw_phpApps;
                   ……
         }
      }
}

以上是对Nginx进行的设置。其中只是包含了关键的部分,其余的和平常我们使用Nginx+PHP作为web服务的时候进行的设置相同。

PHP所在主机设置

这里的设置就比较简单了。

首先编辑php-fpm.conf文件,修改监听的ip和端口,然后启动fpm服务

主机192.168.5.112

Listen = 192.168.5.112:9000   //这里的端口可以自行设置。保存退出
# /usr/local/php/sbin/php-fpm   //开启服务

主机192.168.5.113

Listen = 192.168.5.113:9000
# /usr/local/php/sbin/php-fpm

到这里就对PHP的主机设置完成了。当然了,代码需要在两台主机上各上传一份儿。

好了,经过上面的设置,一个基本的PHP集群就已经搭建完成了。但是有一个问题,这种情况如果只是访问静态资源或者不进行交互的话是没有问题的。如果需要交互,那就涉及到一个session共享的问题。默认情况下PHP是将session存在本地磁盘上的。那这两台主机之间如何共享session呢,接下来我们就来解决这个问题。

PHP主机之间Session共享

之前在网上看到过一种解决方式。由于PHP是将session存储在文件中,那我们可以在Nginx负载主机上面搭建一个分布式文件系统(NFS),让两台PHP主机的session都存放在此文件系统中。以此来达到共享session的目的。

3

我个人比较倾向于将session存储到数据库中。因此这里我介绍的是将session存储到redis中。所以我们需要增加一台Redis服务器

Redis服务器:192.168.5.114

4

PHP默认情况下是不支持对Redis的操作的。所以这里我们需要自己手动安装第三方的扩展,使其支持对Redis的操作。关于如何使PHP支持Redis,我们可以参考《PHP操作Redis的两种方式》

在这里我就认为我们的PHP已经支持Redis了。接下来是将session存储到Redis中,有两种方式:一种是直接修改PHP的配置文件php.ini;另一种是重写session机制。

修改PHP配置文件php.ini将session存储到Redis

使用vim打开php.ini,需要修改的有这两项:session.save_handler和session.save_path。

session.save_handler = Redis

//不需要密码验证
session.save_path = “tcp://192.168.5.114:6379”

//Redis 需要密码验证
session.save_path = “tcp://192.168.5.114:6379?auth=password”

修改完成,保存退出。然后重启php-fpm服务

# kill -INT `cat /usr/local/php/var/run/php-fpm.pid`
# /usr/local/php/sbin/php-fpm

两台PHP主机都做按照以上步骤操作。经过以上步骤,对于session的所有信息都保存到了Redis中。从而实现了session的共享。

通过重写session机制将session存储到Redis

通常,在很多情况下我们是没有权限修改php.ini文件的。这时候我们可以通过重写session机制来修改session信息的存储。

对于重写session,php已经为我们提供了SessionHandlerInterface 接口。我们只要实现这个接口就可以了。关于如何重写session机制,大家可以参考《PHP重写session机制》这篇文章。该类的完整代码在github上,大家有兴趣的和可以点此查看

总结

PHP集群的架构方式有很多种,但是其原理都大同小异。关键是找出最适合自己项目的最佳方案。例如:对于session存储方式的选择,你也可以选择使用memcache或者mysql数据库等。总之最适合自己的就是最优的。希望本文对大家有所帮助。

如何架构高可用的Web站点

一、什么是高可用

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务,我们说系统的可用性是100%。

如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。

很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。

百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”,百度高可用的服务让人留下啦“网络通畅,百度就能访问”,“百度打不开,应该是网络连不上”的印象,这其实是对百度HA最高的褒奖。

 

二、如何保障系统的高可用

我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。方法论上,高可用保证的原则是“集群化”,或者叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

保证系统高可用,架构设计的核心准则是:冗余。

有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是通过“自动故障转移”来实现系统的高可用。

接下来我们看下典型互联网架构中,如何通过冗余+自动故障转移来保证系统的高可用特性。

 

三、常见的互联网分层架构

常见互联网分布式架构如上,分为:

(1)客户端层:典型调用方是浏览器browser或者手机应用APP

(2)反向代理层:系统入口,反向代理

(3)站点应用层:实现核心应用逻辑,返回html或者json

(4)服务层:如果实现了服务化,就有这一层

(5)数据-缓存层:缓存加速访问存储

(6)数据-数据库层:数据库固化数据存储

整个系统的高可用,又是通过每一层的冗余+自动故障转移来综合实现的。

四、分层高可用架构实践

【客户端层->反向代理层】的高可用

20170305211812759
【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余来实现的。以nginx为例:有两台nginx,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

20170305211812759
自动故障转移:当nginx挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-nginx,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

 

【反向代理层->站点层】的高可用

20170305211812759
【反向代理层】到【站点层】的高可用,是通过站点层的冗余来实现的。假设反向代理层是nginx,nginx.conf里能够配置多个web后端,并且nginx能够探测到多个后端的存活性。

20170305211812759
自动故障转移:当web-server挂了的时候,nginx能够探测到,会自动的进行故障转移,将流量自动迁移到其他的web-server,整个过程由nginx自动完成,对调用方是透明的。

 

【站点层->服务层】的高可用

20170305211812759
【站点层】到【服务层】的高可用,是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。

20170305211812759
自动故障转移:当service挂了的时候,service-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的service,整个过程由连接池自动完成,对调用方是透明的(所以说RPC-client中的服务连接池是很重要的基础组件)。

 

【服务层>缓存层】的高可用

20170305211812759
【服务层】到【缓存层】的高可用,是通过缓存数据的冗余来实现的。

缓存层的数据冗余又有几种方式:第一种是利用客户端的封装,service对cache进行双读或者双写。

 

20170305211812759
缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

以redis为例,redis天然支持主从同步,redis官方也有sentinel哨兵机制,来做redis的存活性检测。

20170305211812759
自动故障转移:当redis主挂了的时候,sentinel能够探测到,会通知调用方访问新的redis,整个过程由sentinel和redis集群配合完成,对调用方是透明的。

 

说完缓存的高可用,这里要多说一句,业务对缓存并不一定有“高可用”要求,更多的对缓存的使用场景,是用来“加速数据访问”:把一部分数据放到缓存里,如果缓存挂了或者缓存没有命中,是可以去后端的数据库中再取数据的。

这类允许“cache miss”的业务场景,缓存架构的建议是:

20170305211812759
将kv缓存封装成服务集群,上游设置一个代理(代理可以用集群冗余的方式保证高可用),代理的后端根据缓存访问的key水平切分成若干个实例,每个实例的访问并不做高可用。

20170305211812759
缓存实例挂了屏蔽:当有水平切分的实例挂掉时,代理层直接返回cache miss,此时缓存挂掉对调用方也是透明的。key水平切分实例减少,不建议做re-hash,这样容易引发缓存数据的不一致。

 

【服务层>数据库层】的高可用

大部分互联网技术,数据库层都用了“主从同步,读写分离”架构,所以数据库层的高可用,又分为“读库高可用”与“写库高可用”两类。

 

【服务层>数据库层“读”】的高可用

20170305211812759
【服务层】到【数据库读】的高可用,是通过读库的冗余来实现的。

既然冗余了读库,一般来说就至少有2个从库,“数据库连接池”会建立与读库多个连接,每次请求会路由到这些读库。

20170305211812759
自动故障转移:当读库挂了的时候,db-connection-pool能够探测到,会自动的进行故障转移,将流量自动迁移到其他的读库,整个过程由连接池自动完成,对调用方是透明的(所以说DAO中的数据库连接池是很重要的基础组件)。

 

【服务层>数据库层“写”】的高可用

20170305211812759
【服务层】到【数据库写】的高可用,是通过写库的冗余来实现的。

以mysql为例,可以设置两个mysql双主同步,一台对线上提供服务,另一台冗余以保证高可用,常见的实践是keepalived存活探测,相同virtual IP提供服务。

20170305211812759
自动故障转移:当写库挂了的时候,keepalived能够探测到,会自动的进行故障转移,将流量自动迁移到shadow-db-master,由于使用的是相同的virtual IP,这个切换过程对调用方是透明的。

 

五、总结

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

方法论上,高可用是通过冗余+自动故障转移来实现的。

整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动故障转移来综合实现的,具体的:

(1)【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

(2)【反向代理层】到【站点层】的高可用,是通过站点层的冗余实现的,常见实践是nginx与web-server之间的存活性探测与自动故障转移

(3)【站点层】到【服务层】的高可用,是通过服务层的冗余实现的,常见实践是通过service-connection-pool来保证自动故障转移

(4)【服务层】到【缓存层】的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性

(5)【服务层】到【数据库“读”】的高可用,是通过读库的冗余实现的,常见实践是通过db-connection-pool来保证自动故障转移

(6)【服务层】到【数据库“写”】的高可用,是通过写库的冗余实现的,常见实践是keepalived + virtual IP自动故障转移

原文:http://lib.csdn.net/article/architecture/65600

 

Linux下如何查看版本信息

Linux下如何查看版本信息, 包括位数、版本信息以及CPU内核信息、CPU具体型号等等,整个CPU信息一目了然。

  1、# uname -a   (Linux查看版本当前操作系统内核信息)
   Linux localhost.localdomain 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 athlon i386 GNU/Linux
  2、# cat /proc/version (Linux查看当前操作系统版本信息)
      Linux version 2.4.20-8 (bhcompile@porky.devel.redhat.com)
      (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003
  3、cat /etc/redhat-release(Linux查看版本当前操作系统发行版信息CentOS还是Ubuntu之类的)
 
  Red Hat Linux release 9 (Shrike)

  4、# cat /proc/cpuinfo (Linux查看cpu相关信息,包括型号、主频、内核信息等)
 

  processor        : 0
     vendor_id         : AuthenticAMD
  cpu family        : 15
  model             : 1
  model name      : AMD A4-3300M APU with Radeon(tm) HD Graphics
  stepping         : 0
  cpu MHz          : 1896.236
  cache size       : 1024 KB
  fdiv_bug         : no
  hlt_bug          : no
  f00f_bug        : no
  coma_bug      : no
  fpu                : yes
  fpu_exception   : yes
  cpuid level      : 6
  wp                : yes
  flags             : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr

                           sse sse2 syscall mmxext lm 3dnowext 3dnow
  bogomips      : 3774.87
  5、# getconf LONG_BIT  (Linux查看版本说明当前CPU运行在32bit模式下, 但不代表CPU不支持64bit)

32
6、# lsb_release -a