Nginx(7)Nginx实现服务器端集群搭建

Nginx与Tomcat部署

前面课程已经将Nginx的大部分内容进行了讲解,我们都知道了Nginx在高并发场景和处理静态资源是非常高性能的,但是在实际项目中除了静态资源还有就是后台业务代码模块,一般后台业务都会被部署在Tomcat,weblogic或者是websphere等web服务器上。那么如何使用Nginx接收用户的请求并把请求转发到后台web服务器?
在这里插入图片描述

步骤分析:

1.准备Tomcat环境,并在Tomcat上部署一个web项目
2.准备Nginx环境,使用Nginx接收请求,并把请求分发到Tomat上

采用Tomcat作为后台web服务器
在Centos上准备一个Tomcat

1.Tomcat官网地址:https://tomcat.apache.org/
2.下载tomcat,本次课程使用的是apache-tomcat-8.5.59.tar.gz
3.将tomcat进行解压缩
mkdir web_tomcat
tar -zxf apache-tomcat-8.5.59.tar.gz -C /web_tomcat

准备一个web项目,将其打包为war

1.将demo.war上传到tomcat8目录下的webapps包下
2.将tomcat进行启动,进入tomcat8的bin目录下
./startup.sh

启动tomcat进行访问测试

静态资源: http://192.168.221.199:8088/demo/index.html
动态资源:  http://192.168.221.199:8088/demo/getAddress

在这里插入图片描述
在这里插入图片描述

Nginx环境准备【192.168.221.198】

使用Nginx的反向代理,将请求转给Tomcat进行处理。

upstream webservice {
	server 192.168.221.199:8088;
}
server{
    listen		80;
    server_name localhost;
    location /demo {
    	proxy_pass http://webservice;
    }
}

启动访问测试
在这里插入图片描述
在这里插入图片描述
明明直接通过tomcat就能访问,为什么还需要多加一个nginx,这样不是反而是系统的复杂度变高了么?原因如下:

1.使用Nginx实现动静分离
2.使用Nginx搭建Tomcat的集群

Nginx实现动静分离

什么是动静分离?
动:后台应用程序的业务处理
静:网站的静态资源(html、javaScript、css、images等文件)
分离:将两者进行分开部署访问,提供用户进行访问。举例说明就是以后所有和静态资源相关的内容都交给Nginx来部署访问,非静态内容则交个类似于Tomcat的服务器来部署访问。

为什么要动静分离?
Nginx在处理静态资源的时候,效率是非常高的,而且Nginx(5w)的并发访问量也是名列前茅,而Tomcat(500)则相对比较弱一些,所以把静态资源交个Nginx后,可以减轻Tomcat服务器的访问压力并提高静态资源的访问速度。动静分离以后,降低了动态资源和静态资源的耦合度。如动态资源宕机了也不影响静态资源的展示。

如何实现动静分离?
实现动静分离的方式很多,比如静态资源可以部署到CDN、Nginx等服务器上,动态资源可以部署到Tomcat,weblogic或者websphere上。本次使用Nginx+Tomcat来实现动静分离。

需求分析
在这里插入图片描述
动静分离实现步骤

将demo.war项目中的静态资源都删除掉,重新打包生成一个war包。
将war包部署到tomcat中,把之前部署的内容删除掉

进入到tomcat的webapps目录下,将之前的内容删除掉
将新的war包复制到webapps下
将tomcat启动

在Nginx所在服务器创建如下目录,并将对应的静态资源放入指定的位置
在这里插入图片描述
其中index.html页面的内容如下:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <script src="js/jquery.min.js"></script>
    <script>
        $(function(){
           $.get('http://192.168.221.198/demo/getAddress',function(data){
               $("#msg").html(data);
           });
        });
    </script>
</head>
<body>
    <img src="images/logo.png"/>
    <h1>Nginx如何将请求转发到后端服务器</h1>
    <h3 id="msg"></h3>
    <img src="images/mv.png"/>
</body>
</html>

配置Nginx的静态资源与动态资源的访问

upstream webservice{
   server 192.168.221.199:8088;
}
server {
        listen       80;
        server_name  localhost;

        #动态资源
        location /demo {
                proxy_pass http://webservice;
        }
        #静态资源
        location ~/.*\.(png|jpg|gif|js){
                root html/web;
                gzip on;
        }
     #首页重定向
        location / {
            root   html/web;
            index  index.html index.htm;
        }
}

启动测试,访问http://192.168.221.198/index.html
在这里插入图片描述

假如某个时间点,由于某个原因导致Tomcat后的服务器宕机了,我们再次访问Nginx,会得到如下效果,用户还是能看到页面,只是缺失了访问次数的统计,这就是前后端耦合度降低的效果,并且整个请求只和后的服务器交互了一次,js和images都直接从Nginx返回,提供了效率,降低了后的服务器的压力。

在这里插入图片描述

Nginx实现Tomcat集群搭建

在使用Nginx和Tomcat部署项目的时候,我们使用的是一台Nginx服务器和一台Tomcat服务器,效果图如下:
在这里插入图片描述

如果Tomcat的真的宕机了,整个系统就会不完整,所以如何解决上述问题,一台服务器容易宕机,那就多搭建几台Tomcat服务器,这样的话就提升了后的服务器的可用性。这也就是我们常说的集群,搭建Tomcat的集群需要用到了Nginx的反向代理和赋值均衡的知识,具体如何来实现?
在这里插入图片描述

环境准备

准备3台tomcat,使用端口进行区分[实际环境应该是三台服务器],修改server.ml,将端口修改分别修改为8988,8180,8280

启动tomcat并访问测试,

http://192.168.221.199:8988/demo/getAddress

在这里插入图片描述

http://192.168.221.199:8180/demo/getAddress

在这里插入图片描述

http://192.168.221.199:8383/demo/getAddress

在这里插入图片描述

在Nginx对应的配置文件中添加如下内容:

upstream webservice{
        server 192.168.221.199:8988;
        server 192.168.221.199:8180;
        server 192.168.221.199:8383;
    }

完成上述环境的部署,已经解决了Tomcat的高可用性,一台服务器宕机,还有其他两条对外提供服务,同时也可以实现后台服务器的不间断更新。但是新问题出现了,上述环境中,如果是Nginx宕机了呢,那么整套系统都将服务对外提供服务了,这个如何解决?

Nginx高可用解决方案

针对于上面提到的问题,需要两台以上的Nginx服务器对外提供服务,这样的话就可以解决其中一台宕机了,另外一台还能对外提供服务,但是如果是两台Nginx服务器的话,会有两个IP地址,用户该访问哪台服务器,用户怎么知道哪台是好的,哪台是宕机了的?
在这里插入图片描述

Keepalived

使用Keepalived来解决,Keepalived 软件由 C 编写的,最初是专为 LVS 负载均衡软件设计的,Keepalived 软件主要是通过 VRRP 协议实现高可用功能。

VRRP介绍
在这里插入图片描述
VRRP(Virtual Route Redundancy Protocol)协议,翻译过来为虚拟路由冗余协议。VRRP协议将两台或多台路由器设备虚拟成一个设备,对外提供虚拟路由器IP,而在路由器组内部,如果实际拥有这个对外IP的路由器如果工作正常的话就是MASTER,MASTER实现针对虚拟路由器IP的各种网络功能。其他设备不拥有该虚拟IP,状态为BACKUP,处了接收MASTER的VRRP状态通告信息以外,不执行对外的网络功能。当主机失效时,BACKUP将接管原先MASTER的网络功能。

从上面的介绍信息获取到的内容就是VRRP是一种协议,那这个协议是用来干什么的?

1.选择协议

VRRP可以把一个虚拟路由器的责任动态分配到局域网上的 VRRP 路由器中的一台。其中的虚拟路由即Virtual路由是由VRRP路由群组创建的一个不真实存在的路由,这个虚拟路由也是有对应的IP地址。而且VRRP路由1和VRRP路由2之间会有竞争选择,通过选择会产生一个Master路由和一个Backup路由。

2.路由容错协议

Master路由和Backup路由之间会有一个心跳检测,Master会定时告知Backup自己的状态,如果在指定的时间内,Backup没有接收到这个通知内容,Backup就会替代Master成为新的Master。Master路由有一个特权就是虚拟路由和后端服务器都是通过Master进行数据传递交互的,而备份节点则会直接丢弃这些请求和数据,不做处理,只是去监听Master的状态

用了Keepalived后,解决方案如下:
在这里插入图片描述
在两个nginx服务器上分别装Keepalived,通过VRRP的选择协议定出一个主节点和备份节点,再通过VRRP协议虚拟出一个ip地址,(虚拟IP地址使得用户不需要关注有几个nginx节点,只需访问虚拟ip),虚拟ip收到请求后,找对应的主节点来处理请求,如果主节点宕机,备份节点升级为主节点去处理请求。

环境准备

VIPIP主机名主/从
192.168.221.199keepalived1Master
192.168.221.222
192.168.221.198keepalived2Backup

keepalived的安装

1.从官方网站下载keepalived,官网地址https://keepalived.org/
2.将下载的资源上传到服务器
	keepalived-2.0.20.tar.gz
3.创建keepalived目录,方便管理资源
	mkdir keepalived
4.将压缩文件进行解压缩,解压缩到指定的目录
	tar -zxf keepalived-2.0.20.tar.gz -C keepalived/
5.对keepalived进行配置,编译和安装
	cd keepalived/keepalived-2.0.20
	./configure --sysconf=/etc --prefix=/usr/local
	make && make install

安装完成后,需要认识两个文件,一个是 /etc/keepalived/keepalived.conf(keepalived的系统配置文件,主要操作的就是该文件),一个是/usr/local/sbin目录下的keepalived,是系统配置脚本,用来启动和关闭keepalived。

Keepalived配置文件

打开keepalived.conf配置文件

第一部分是global全局配置、第二部分是vrrp相关配置、第三部分是LVS相关配置。
主要是使用keepalived实现高可用部署,没有用到LVS,所以重点关注的是前两部分

global全局部分:
global_defs {
   #通知邮件,当keepalived发送切换(主节点备份节点切换)时需要给指定的邮箱地址发email(收件人)
   notification_email {
     tom@itcast.cn
     jerry@itcast.cn
   }
   #设置发件人的邮箱信息
   notification_email_from zhaomin@itcast.cn
   #指定smpt服务地址
   smtp_server 192.168.200.1
   #指定smpt服务连接超时时间
   smtp_connect_timeout 30
   #运行keepalived服务器的一个标识,可以用作发送邮件的主题信息
   router_id LVS_DEVEL
   
   #默认是不跳过检查。检查收到的VRRP通告中的所有地址可能会比较耗时,设置此命令的意思是,如果通告与接收的上一个通告来自相同的master路由器,则不执行检查(跳过检查)
   vrrp_skip_check_adv_addr
   #严格遵守VRRP协议。
   vrrp_strict
   #在一个接口发送的两个免费ARP之间的延迟。可以精确到毫秒级。默认是0
   vrrp_garp_interval 0
   #在一个网卡上每组na消息之间的延迟时间,默认为0
   vrrp_gna_interval 0
}
VRRP部分,该部分可以包含以下四个子模块
1. vrrp_script
2. vrrp_sync_group
3. garp_group
4. vrrp_instance
我们会用到第一个和第四个,
#设置keepalived实例的相关信息,VI_1为VRRP实例名称
vrrp_instance VI_1 {
    state MASTER  		#有两个值可选MASTER主 BACKUP备
    interface ens33		#vrrp实例绑定的接口,用于发送VRRP包[当前服务器使用的网卡名称]
    virtual_router_id 51  #指定VRRP实例ID,范围是0-255(虚拟ip)
    priority 100		#指定优先级,优先级高的将成为MASTER
    advert_int 1		#指定发送VRRP通告的间隔,单位是秒
    authentication {	#vrrp之间通信的认证信息
        auth_type PASS	#指定认证方式。PASS简单密码认证(推荐)
        auth_pass 1111	#指定认证使用的密码,最多8位
    }
    virtual_ipaddress { #虚拟IP地址设置虚拟IP地址,供用户访问使用,可设置多个,一行一个
        192.168.221.222
    }
}

配置内容如下:

192.168.221.199

global_defs {
   notification_email {
        tom@itcast.cn
        jerry@itcast.cn
   }
   notification_email_from zhaomin@itcast.cn
   smtp_server 192.168.221.1
   smtp_connect_timeout 30
   router_id keepalived1
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.221.222
    }
}

192.168.221.198

! Configuration File for keepalived

global_defs {
   notification_email {
        tom@itcast.cn
        jerry@itcast.cn
   }
   notification_email_from zhaomin@itcast.cn
   smtp_server 192.168.221.1
   smtp_connect_timeout 30
   router_id keepalived2
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.221.222
    }
}

访问测试

  1. 启动keepalived之前,咱们先使用命令 ip a,查看192.168.221.199和192.168.221.198这两台服务器的IP情况。

在这里插入图片描述
在这里插入图片描述

  1. 分别启动两台服务器的keepalived
cd /usr/local/sbin
./keepalived

再次通过 ip a查看ip

在这里插入图片描述

  1. 当把192.168.221.199服务器上的keepalived关闭后,再次查看ip

在这里插入图片描述

通过上述的测试会发现,虚拟IP(VIP)会在MASTER节点上,当MASTER节点上的keepalived出问题以后,因为BACKUP无法收到MASTER发出的VRRP状态通过信息,就会直接升为MASTER。VIP也会"漂移"到新的MASTER。

上面测试和Nginx有什么关系?

192.168.221.199服务器的keepalived再次启动下,由于它的优先级高于服务器192.168.221.198的,所以它会再次成为MASTER,VIP也会"漂移"过去,然后我们再次通过浏览器访问:

http://192.168.221.222/
#数据来自192.168.221.199

在这里插入图片描述

如果把192.168.221.199服务器的keepalived关闭掉,再次访问相同的地址,变成198的nginx首页
在这里插入图片描述

效果实现了以后, 会发现要想让vip进行切换,就必须要把服务器上的keepalived进行关闭,而什么时候关闭keepalived呢?应该是在keepalived所在服务器的nginx出现问题后,把keepalived关闭掉,就可以让VIP执行另外一台服务器,但是现在这所有的操作都是通过手动来完成的,我们如何能让系统自动判断当前服务器的nginx是否正确启动,如果没有,要能让VIP自动进行"漂移",这个问题该如何解决?

keepalived之vrrp_script

keepalived只能做到对网络故障和keepalived本身的监控,即当出现网络故障或者keepalived本身出现问题时,进行切换。但是这些还不够,我们还需要监控keepalived所在服务器上的其他业务,比如Nginx,如果Nginx出现异常了,仅仅keepalived保持正常,是无法完成系统的正常工作的,因此需要根据业务进程的运行状态决定是否需要进行主备切换,这个时候,可以通过编写脚本对业务进程进行检测监控。

实现步骤:

  1. 在keepalived配置文件中添加对应的配置像
vrrp_script 脚本名称
{
    script "脚本位置"
    interval 3 #执行时间间隔
    weight -20 #动态调整vrrp_instance的优先级
}
  1. 编写脚本 ck_nginx.sh
#!/bin/bash
num=`ps -C nginx --no-header | wc -l`
if [ $num -eq 0 ];then #没有Nginx进程
 /usr/local/nginx/sbin/nginx #启动nginx
 sleep 2
 if [ `ps -C nginx --no-header | wc -l` -eq 0 ]; then #没有nginx进程
  killall keepalived # 删掉keepalived进程
 fi
fi

在这里插入图片描述

Linux ps命令用于显示当前进程 (process) 的状态。
-C(command) :指定命令的所有进程
--no-header 排除标题
  1. 为脚本文件设置权限
chmod 755 ck_nginx.sh
  1. 将脚本添加到
vrrp_script ck_nginx {
   script "/etc/keepalived/ck_nginx.sh" #执行脚本的位置
   interval 2		#执行脚本的周期,秒为单位
   weight -20		#权重的计算方式,优先级-20
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 10
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.111
    }
    track_script {
      ck_nginx
    }
}
  1. 如果效果没有出来,可以使用 tail -f /var/log/messages查看日志信息,找对应的错误信息。
    在这里插入图片描述
    问题思考:
    通常如果master服务死掉后backup会变成master,但是当master服务又好了的时候master此时会抢占VIP,这样就会发生两次切换对业务繁忙的网站来说是不好的。所以要在配置文件加入 nopreempt 非抢占,但是这个参数只能用于state 为backup,故我们在用HA的时候最好master 和backup的state都设置成backup 让其通过priority来竞争。

Nginx制作下载站点

打开一个网站http://nginx.org/download/,该网站主要就是用来提供用户来下载相关资源的网站,就叫做下载网站。
在这里插入图片描述

如何制作一个下载站点?

nginx使用的是模块ngx_http_autoindex_module来实现的,该模块处理以斜杠(“/”)结尾的请求,并生成目录列表。nginx编译的时候会自动加载该模块,但是该模块默认是关闭的,需要使用下来指令来完成对应的配置。

autoindex: 启用或禁用目录列表输出

语法autoindex on|off;
默认值autoindex off;
位置http、server、location

autoindex_exact_size: 对应HTLM格式,指定是否在目录列表展示文件的详细大小

默认为on,显示出文件的确切大小,单位是bytes。
改为off后,显示出文件的大概大小,单位是kB或者MB或者GB

语法autoindex_exact_size on|off;
默认值autoindex_exact_size on;
位置http、server、location

autoindex_format: 设置目录列表的格式

语法autoindex_format html|xml|json|jsonp;
默认值autoindex_format html;
位置http、server、location

注意:该指令在1.7.9及以后版本中出现

autoindex_localtime: 对应HTML格式,是否在目录列表上显示时间。

默认为off,显示的文件时间为GMT时间。
改为on后,显示的文件时间为文件的服务器时间

语法autoindex_localtime on | off;
默认值autoindex_localtime off;
位置http、server、location

配置方式如下:

# 下载站点相关配置
location /download{
 # 下载资源位置
    root /usr/local;
    autoindex on; #off页面会有403错误
    autoindex_exact_size on; #on显示大小byte,off KB单位
    autoindex_format html; # 显示格式XML/JSON格式[一般不用这两种方式]
    autoindex_localtime on; # on在服务器上的时间(什么时候放在服务器上)
}

Nginx的用户认证模块

对应系统资源的访问,往往需要限制谁能访问,谁不能访问。这块就是通常所说的认证部分,认证需要做的就是根据用户输入的用户名和密码来判定用户是否为合法用户,如果是则放行访问,如果不是则拒绝访问。

Nginx对应用户认证这块是通过ngx_http_auth_basic_module模块来实现的,它允许通过使用"HTTP基本身份验证"协议验证用户名和密码来限制对资源的访问。默认情况下nginx是已经安装了该模块,如果不需要则使用–without-http_auth_basic_module进行排除。

auth_basic: 使用“ HTTP基本认证”协议启用用户名和密码的验证

语法auth_basic string|off;
默认值auth_basic off;
位置http,server,location,limit_except

开启后,服务端会返回401,指定的字符串会返回到客户端,给用户以提示信息,但是不同的浏览器对内容的展示不一致。

auth_basic_user_file: 指定用户名和密码所在文件

语法auth_basic_user_file file;
默认值
位置http,server,location,limit_except

指定文件路径,该文件中的用户名和密码的设置,密码需要进行加密。可以采用工具自动生成

实现步骤:

1.nginx.conf添加如下内容

location /download{
    root /usr/local;
    autoindex on;
    autoindex_exact_size on;
    autoindex_format html;
    autoindex_localtime on;
    auth_basic 'please input your auth';
    # htpasswd存放路径
    auth_basic_user_file htpasswd;
}

在这里插入图片描述
2.我们需要使用htpasswd工具生成用户名密码

yum install -y httpd-tools

相关指令:

 //创建一个新文件记录用户名和密码
htpasswd -c /usr/local/nginx/conf/htpasswd username
//在指定文件追加一个用户名和密码
htpasswd -b /usr/local/nginx/conf/htpasswd username password 
//从指定文件删除一个用户信息
htpasswd -D /usr/local/nginx/conf/htpasswd username 
//验证用户名和密码是否正确
htpasswd -v /usr/local/nginx/conf/htpasswd username 

上述方式虽然能实现用户名和密码的验证,但是所有的用户名和密码信息都记录在文件里面,如果用户量过大的话,这种方式就显得有点麻烦了,这时候就得通过后台业务代码来进行用户权限的校验了。

  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
【资源说明】 1、该资源包括项目的全部源码,下载可以直接使用! 2、本项目适合作为计算机、数学、电子信息等专业的课程设计、期末大作业和毕设项目,作为参考资料学习借鉴。 3、本资源作为“参考资料”如果需要实现其他功能,需要能看懂代码,并且热爱钻研,自行调试。 基于SpringBoot框架搭建的物联网数据采集系统服务器端(源码+项目说明).zip ## 基于SpringBoot框架搭建的物联网数据采集系统服务器端 DAQ-IoT-SSM的升级版 #### 2020-7-15 更新内容 * 1.前端页面完全重构 * 使用elements-ui重新编写所有前端页面,优化视觉感受。 * 完全抛弃JQuery,使用vue.js + axios实现前后端交互,优化交互逻辑和用户体验。 * 2.API优化 * 取消虚拟路径 * 添加部分API,如根据时间段查询数据、条件查询传感器。 * 过时原有按时间段查询异常的API。 #### 2020-05-14 更新内容 * 1.框架迁移到SpringBoot+MyBatis,相比于SSM版的项目大大减少了xml配置,仅在application.yml文件中配置了少量信息 * 2.添加Redis缓存,在以下部分提供缓存支持: * 当查询单个Gateway、Sensor、SensorClassify时使用查询缓存,从数据库查询过的数据会存入缓存,提高查询效率 * 传感器提交Data数据时使用添加缓存,不直接操作数据库,而是将Data添加到Redis中形成缓存队列,提高并发效率 * 将用户登录信息不直接存入session,而是存入Redis缓存,以实现分布式session共享 * 3.提交Data数据的异步任务支持。通过线程池实现异步地将Redis中缓存队列添加到数据库,减少数据库的写入压力。 * 4.nginx与tomcat集群支持: * 通过SpringBoot的内置Tomcat方便了Tomcat集群的部署 * 提供查看IP和端口API方便进行nginx反向代理和负载均衡的部署和测试 * 分布式session共享避免了集群环境下用户登录信息失效的问题 * 5.测试页面优化 * 模拟传感器数据提交页面支持批量数据提交 * 按时间段查询传感器异常页面不再需要输入时间戳而是通过控件输入日期 * 修复了前端页面显示时间与数据库存储时间不一致的bug ### 注意: * 前端页面仅供测试,本系统主要是为底层传感网络提供数据提交和管理的平台。 * 默认请求路径 http://localhost:8080/ 8080为SpringBoot内置Tomcat端口,可在application.yml文件中修改。 * 以下所有API除测试、用户相关的/login、/info、/exit之外,都会被登录拦截器所拦截,调用其他API需要先登录一个用户。 * 本系统除下载部分外,所有响应数据均为同样的JSON格式。 * 格式:{"status" : true/false, "message" : "description...", "data": data } * status: 表示请求是否成功。 * message: 对请求的描述,如果响应失败,描述失败原因。 * data: 请求成功时响应的数据,为Object类型,可以是任何类型的数据。data的具体json的格式可参考domain包中的实体类结构。 ### 提供API #### 0. 测试 |功能|请求uri|请求方式|请求参数| |----|------|--------|-------| |测试|/api/home|GET|无| |查看IP和端口|/api/address|GET|无| #### 1. 用户相关 |功能|请求uri|请求方式|请求参数| |----|------|--------|-------| |用户登录|/api/user/login|POST|User对象| |查看登录用户|/api/user/info|GET|无| |退出登录|/api/user/exit|GET|无| |用户注册|/api/user/regist|POST|User对象| |修改密码|/api/user/password|POST|User对象、新密码| |修改基本信息|/api/user/modify|POST|User对象| #### 2. 网关相关(restful风格) |功能|请求uri|请求方式|请求参数| |----|------|--------|-------| |添加网关|/api/g
由国内著名技术社区联合推荐的2012年IT技术力作:《高性能Linux服务器构建实战:运维监控、性能调优与集群应用》,即将上架发行,此书从Web应用、数据备份与恢复、网络存储应用、运维监控与性能优化、集群高级应用等多个方面深入讲解了如何构建高性能的Linux服务器。其中蕴含了丰富的运维经验。更为重要的是,本书的内容不受硬件环境的限制,而且包含大量实用性极强的案例。对于广大Linux运维人员和系统管理人员来说,具有非常实用的指导意义。 全书共分五个篇幅,由14个章节组成,内容涉及Web应用、数据备份恢复、网络存储应用、性能优化与运维监控、集群高级应用方面,每个篇幅占用比例分别为:20%、20%、14%、14%,32%。 前言 第1篇 Web应用篇 第1章 轻量级HTTP服务器Nginx 1.1 什么是Nginx 1.2 为什么要选择Nginx 1.2.1 Nginx与Apache的异同 1.2.2 选择Nginx的优势所在 1.3 Nginx的模块与工作原理 1.4 Nginx的安装与配置 1.4.1 下载与安装Nginx 1.4.2 Nginx配置文件的结构 1.4.3 配置与调试Nginx 1.4.4 Nginx的启动、关闭和平滑重启 1.5 Nginx常用配置实例 1.5.1 虚拟主机配置实例 1.5.2 负载均衡配置实例 1.5.3 防盗链配置实例 1.5.4 日志分割配置实例 1.6 Nginx性能优化技巧 1.6.1 编译安装过程优化 1.6.2 利用TCMalloc优化Nginx的性能 1.6.3 Nginx内核参数优化 1.7 实战Nginx与PHP(FastCGI)的安装、配置与优化 1.7.1 什么是 FastCGI 1.7.2 Nginx+FastCGI运行原理 1.7.3 spawn-fcgi与PHP-FPM 1.7.4 PHP与PHP-FPM的安装及优化 1.7.5 配置Nginx来支持PHP 1.7.6 测试Nginx对PHP的解析功能 1.7.7 优化Nginx中FastCGI参数的实例 1.8 实战Nginx与Perl、Java的安装与配置 1.8.1 Perl(FastCGI)的安装 1.8.2 为Nginx添加FCGI支持 1.8.3 测试Nginx +Perl(FastCGI) 1.8.4 搭建Nginx+Java环境 1.9 本章小结 第2章 高性能HTTP加速器Varnish 2.1 初识Varnish 2.1.1 Varnish概述 2.1.2 Varnish的结构与特点 2.1.3 Varnish与Squid的对比 2.2 开始安装Varnish 2.2.1 安装前的准备 2.2.2 获取Varnish软件 2.2.3 安装pcre 2.2.4 安装Varnish 2.3 配置Varnish 2.3.1 VCL使用说明 2.3.2 配置一个简单的Varnish实例 2.3.3 Varnish对应多台Web服务器的配置实例 2.4 运行Varnish 2.4.1 varnishd指令 2.4.2 配置Varnish运行脚本 2.4.3 管理Varnish运行日志 2.5 管理Varnish 2.5.1 查看Varnish进程 2.5.2 查看Varnish缓存效果与状态 2.5.3 通过端口管理Varnish 2.5.4 管理Varnish缓存内容 2.6 Varnish优化 2.6.1 优化Linux内核参数 2.6.2 优化系统资源 2.6.3 优化Varnish参数 2.7 Varnish的常见应用实例 2.7.1 利用Varnish实现图片防盗链 2.7.2 利用Varnish实现静态文件压缩处理 2.8 本章小结 第3章 Memcached应用实战 3.1 Memcached基础 3.1.1 什么是Memcached 3.1.2 Memcached的特征 3.1.3 Memcached的安装 3.1.4 Memcached的简单使用过程 3.2 剖析Memcached的工作原理 3.2.1 Memcached的工作过程 3.2.2 Slab Allocation的工作机制 3.2.3 Memcached的删除机制 3.2.4 Memcached的分布式算法 3.3 Memcached的管理与性能监控 3.3.1 如何管理Memcached 3.3.2 Memcached的监控 3.3.3 Memcached变种产品介绍 3.4 通过UDFs实现Memcached与MySQL的自动更新 3.4.1 UDFs使用简介 3.4.2 memcached_functions_mysql应用实例 3.4.3 对memcached_functions_mysql的简单功能进行测试 3.4.4 使用memcached_functions_mysql的经验与技巧 3.5 本章小结 第2篇 数据备份恢复篇 第4章 开源网络备份软件bacula 4.1 bacula总体概述 4.1.1 bacula是什么 4.1.2 bacula适合哪些用户 4.1.3 bacula的功能特点 4.1.4 bacula的工作原理 4.2 安装bacula 4.2.1 bacula的几种网络备份拓扑 4.2.2 编译与安装bacula 4.2.3 初始化MySQL数据库 4.3 配置一个bacula备份系统 4.3.1 配置bacula的Console端 4.3.2 配置bacula的Director端 4.3.3 配置bacula的SD 4.3.4 配置bacula的FD端 4.4 启动与关闭bacula 4.4.1 启动bacula的Director daemon与Storage daemon 4.4.2 在客户端FD启动File daemon 4.5 实战bacula备份恢复过程 4.5.1 实例演示bacula的完全备份功能 4.5.2 实例演示bacula的增量备份功能 4.5.3 实例演示bacula的差异备份功能 4.5.4 实例演示bacula的完全恢复功能 4.5.5 实例演示bacula的不完全恢复功能 4.6 本章小结 第5章 数据镜像备份工具rsync与unison 5.1 rsync简介 5.1.1 什么是rsync 5.1.2 rsync的功能特性 5.1.3 下载与安装rsync软件 5.2 利用rsync搭建数据镜像备份系统 5.2.1 rsync的应用模式 5.2.2 企业案例:搭建远程容灾备份系统 5.3 通过rsync+inotify实现数据的实时备份 5.3.1 rsync的优点与不足 5.3.2 初识inotify 5.3.3 安装inotify工具inotify-tools 5.3.4 inotify相关参数 5.3.5 inotifywait相关参数 5.3.6 企业应用案例:利用rsync+inotify搭建实时同步系统 5.4 unison简介 5.5 安装unison 5.6 配置双机ssh信任 5.6.1 在两台机器上创建 RSA密钥 5.6.2 添加密钥到授权密钥文件中 5.7 unison的使用 5.7.1 本地使用unison 5.7.2 远程使用unison 5.7.3 unison参数说明 5.7.4 通过配置文件来使用unison 5.8 本章小结 第6章 ext3文件系统反删除利器ext3grep 6.1 “rm–rf”带来的困惑 6.2 ext3grep的安装与使用 6.2.1 ext3grep的恢复原理 6.2.2 ext3grep的安装过程 6.3 通过ext3grep恢复误删除的文件与目录 6.3.1 数据恢复准则 6.3.2 实战ext3grep恢复文件 6.4 通过ext3grep恢复误删除的MySQL表 6.4.1 MySQL存储引擎介绍 6.4.2 模拟MySQL表被误删除的环境 6.4.3 通过ext3grep分析数据、恢复数据 6.5 本章小结 第3篇 网络存储应用篇 第7章 IP网络存储iSCSI 7.1 存储的概念与术语 7.1.1 SCSI介绍 7.1.2 FC介绍 7.1.3 DAS介绍 7.1.4 NAS介绍 7.1.5 SAN介绍 7.2 iSCSI的概念 7.3 FC SAN与IP SAN 7.4 iSCSI的组成 7.4.1 iSCSI Initiator 7.4.2 iSCSI Target 7.5 iSCSI的工作原理 7.6 搭建基于IP SAN的iSCSI存储系统 7.6.1 安装iSCSI Target软件 7.6.2 配置一个简单的iSCSI Target 7.6.3 在Windows上配置iSCSI Initiator 7.6.4 在Linux上配置iSCSI Initiator 7.7 iSCSI 在安全方面的相关设定 7.7.1 Initiator主机以IP认证方式获取iSCSI Target资源 7.7.2 Initiator主机以密码认证方式获取iSCSI Target资源 7.8 iSCSI性能优化方案 7.8.1 iSCSI性能瓶颈 7.8.2 iSCSI性能优化 7.9 本章小结 第8章 分布式存储系统MFS 8.1 MFS概论 8.2 MFS 文件系统 8.2.1 MFS文件系统结构 8.2.2 MFS的编译与安装实例 8.3 编译与使用MFS的经验总结 8.3.1 安装选项说明 8.3.2 管理服务器 8.3.3 元数据日志服务器 8.3.4 数据存储服务器 8.3.5 客户端挂载 8.4 管理与使用MFS 8.4.1 在客户端挂载文件系统 8.4.2 MFS常用操作 8.4.3 为垃圾箱设定隔离时间 8.4.4 快照 8.4.5 MFS的其他命令 8.5 维护MFS 8.5.1 启动MFS集群 8.5.2 停止MFS集群 8.5.3 MFS 数据存储服务器的维护 8.5.4 MFS元数据的备份 8.5.5 MFS 管理服务器的恢复 8.5.6 从备份恢复MFS 管理服务器 8.6 通过冗余实现失败防护的解决方案 8.7 本章小结 第4篇 运维监控与性能优化篇 第9章 运维监控利器Nagios 9.1 Nagios综述 9.1.1 什么是Nagios 9.1.2 Nagios的结构与特点 9.2 Nagios的安装与配置 9.2.1 安装Nagios 9.2.2 配置Nagios 9.3 Nagios的运行和维护 9.3.1 验证Nagios配置文件的正确性 9.3.2 启动与停止Nagios 9.3.3 Nagios故障报警 9.4 Nagios性能分析图表的实现 9.4.1 Nagios性能分析图表的作用 9.4.2 PNP的概念与安装环境 9.4.3 安装PNP 9.4.4 配置PNP 9.4.5 修改Nagios配置文件 9.4.6 测试PNP功能 9.5 利用插件扩展Nagios的监控功能 9.5.1 利用NRPE外部构件监控远程主机 9.5.2 利用飞信实现Nagios短信报警功能 9.6 本章小结 第10章 基于Linux服务器的性能分析与优化 10.1 系统性能分析的目的 10.1.1 找到系统性能的瓶颈 10.1.2 提供性能优化方案 10.1.3 使系统硬件和软件资源的使用达到平衡 10.2 分析系统性能涉及的人员 10.2.1 Linux系统管理人员 10.2.2 系统架构设计人员 10.2.3 软件开发人员 10.3 影响Linux性能的各种因素 10.3.1 系统硬件资源 10.3.2 操作系统相关资源 10.3.3 应用程序软件资源 10.4 系统性能分析标准和优化原则 10.5 几种典型应用对系统资源使用的特点 10.5.1 以静态内容为主的Web应用 10.5.2 以动态内容为主的Web应用 10.5.3 数据库应用 10.5.4 软件下载应用 10.5.5 流媒体服务应用 10.6 Linux下常见的性能分析工具 10.6.1 vmstat命令 10.6.2 sar命令 10.6.3 iostat命令 10.6.4 free命令 10.6.5 uptime命令 10.6.6 netstat命令 10.6.7 top命令 10.7 基于Web应用的性能分析及优化案例 10.7.1 基于动态内容为主的网站优化案例 10.7.2 基于动态、静态内容结合的网站优化案例 10.8 本章小结 第5篇 集群高级应用篇 第11章 构建高可用的LVS负载均衡集群 11.1 LVS集群的组成与特点 11.1.1 LVS集群的组成 11.1.2 LVS集群的特点 11.1.3 LVS集群系统的优缺点 11.2 高可用 LVS负载均衡集群体系结构 11.3 高可用性软件Heartbeat与Keepalived 11.3.1 开源HA软件Heartbeat的介绍 11.3.2 安装heartbeat 11.3.3 开源HA软件Keepalived的介绍 11.3.4 安装Keepalived 11.4 安装LVS软件 11.4.1 配置与检查安装环境 11.4.2 在Director Server上安装IPVS管理软件 11.5 搭建高可用 LVS集群 11.5.1 通过heartbeat搭建LVS高可用性集群 11.5.2 通过Keepalived搭建LVS高可用性集群系统 11.5.3 通过piranha搭建LVS高可用性集群 11.6 测试高可用LVS负载均衡集群系统 11.6.1 高可用性功能测试 11.6.2 负载均衡测试 11.6.3 故障切换测试 11.7 本章小结 第12章 RHCS集群 12.1 RHCS集群概述 12.2 RHCS集群的组成与结构 12.2.1 RHCS集群的组成 12.2.2 RHCS集群结构 12.3 RHCS集群的运行原理及功能 12.3.1 分布式集群管理器(CMAN) 12.3.2 锁管理(DLM) 12.3.3 配置文件管理(CCS) 12.3.4 栅设备(Fence) 12.3.5 高可用性服务管理器 12.3.6 集群配置和管理工具 12.3.7 Redhat GFS 12.4 安装RHCS 12.4.1 安装前准备工作 12.4.2 配置共享存储和RHCS管理端Luci 12.4.3 在集群节点上安装RHCS软件包 12.4.4 在集群节点上安装和配置iSCSI客户端 12.5 配置RHCS高可用集群 12.5.1 创建一个cluster 12.5.2 创建Failover Domain 12.5.3 创建Resources 12.5.4 创建Service 12.5.5 配置存储集群GFS 12.5.6 配置表决磁盘 12.5.7 配置Fence设备 12.6 管理和维护RHCS集群 12.6.1 启动RHCS集群 12.6.2 关闭RHCS集群 12.6.3 管理应用服务 12.6.4 监控RHCS集群状态 12.6.5 管理和维护GFS2文件系统 12.7 RHCS集群功能测试 12.7.1 高可用集群测试 12.7.2 存储集群测试 12.8 本章小结 第13章 Oracle RAC集群 13.1 Oracle集群体系结构 13.2 Oracle ClusterWare体系结构与进程介绍 13.2.1 Oracle ClusterWare 简介 13.2.2 Oracle ClusterWare 进程介绍 13.3 RAC数据库体系结构与进程 13.3.1 RAC 简介 13.3.2 Oracle RAC的特点 13.3.3 RAC进程管理 13.3.4 RAC数据库存储规划 13.4 安装Oracle RAC数据库 13.4.1 安装前的系统配置需求 13.4.2 设置数据库安装资源 13.4.3 配置主机解析文件 13.4.4 检查所需软件包 13.4.5 配置系统内核参数 13.4.6 设置 Shell对Oracle用户的限制 13.4.7 配置hangcheck-timer内核模块 13.4.8 配置系统安全设置 13.4.9 创建Oracle用户和组 13.4.10 设置Oracle用户环境变量 13.4.11 配置节点间SSH信任 13.4.12 配置共享存储系统 13.4.13 安装Oracle Clusterware 13.4.14 安装Oracle数据库 13.4.15 配置Oracle Net 13.4.16 创建RAC数据库 13.5 Oracle CRS的管理与维护 13.5.1 查看集群状态 13.5.2 启动与关闭集群服务资源 13.5.3 启动与关闭CRS 13.5.4 管理voting disk 13.5.5 管理OCR 13.5.6 快速卸载CRS 13.6 ASM基本操作维护 13.6.1 ASM的特点 13.6.2 ASM的体系结构与后台进程 13.6.3 管理ASM实例 13.7 利用srvctl管理RAC数据库 13.7.1 查看实例状态(srvctl status) 13.7.2 查看RAC数据库配置信息(srvctl config) 13.7.3 启动 13.7.4 增加 13.8 测试RAC数据库集群的功能 13.8.1 负载均衡测试 13.8.2 透明应用失败切换测试 13.9 本章小结 第14章 构建MySQL+heartbeat+DRBD+LVS集群应用系统 14.1 MySQL高可用集群概述 14.2 heartbeat + DRBD高可用性方案的实现原理 14.3 部署MySQL高可用高扩展集群 14.3.1 配置之前的准备 14.3.2 DRBD的部署 14.3.3 DRBD的配置 14.3.4 DRBD的维护和管理 14.3.5 DRBD的性能优化 14.3.6 MySQL的部署 14.3.7 heartbeat的部署 14.4 搭建Slave集群 14.4.1 为什么要搭建Slave集群 14.4.2 利用LVS+Keepalived搭建高可用MySQL Slave集群 14.4.3 高可用Slave集群的一些注意点 14.5 部署MySQL集群要考虑的问题 14.6 本章小结

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值