Tomcat、Nginx等Web容器
2022-05-12 15:28:23 3 举报
AI智能生成
Tomcat、Nginx等Web容器
作者其他创作
大纲/内容
常见HTTP服务器、Web Server
Java EE WEB 服务器也称为 Java WEB 容器.
开源
Nginx
Nginx - Nginx
Apache
Apache Webserver - Apache基金会
Apache Tomcat (Java EE)
Jetty (Java EE)
Lighthttpd
商业
Microsoft IIS
IIS - 微软
IBM Webspare (Java EE)
Oracle Weblogic (Java EE)
GWS - Google
Jetty
Jetty是什么?
一个开源的servlet容器
它为基于Java的web容器,例如JSP和servlet提供运行环境
Jetty是使用Java语言编写的,它的API以一组JAR包的形式发布。
开发人员可以将Jetty容器实例化成一个对象,可以迅速为一些独立运行的Java应用提供网络和web连接。
独立运行(stand-alone)
Jetty和Tomcat插件使用
1. 此说明文档只对Java web开发中使用Maven管理项目时才生效;
2. 在maven配置文件中使用jetty插件的配置语句如下:
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>8.1.8.v20121106</version>
<configuration>
<!-- <httpPort>8089</httpPort> -->
<webAppConfig>
<contextPath>/${project.build.finalName}</contextPath>
</webAppConfig>
</configuration>
</plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>8.1.8.v20121106</version>
<configuration>
<!-- <httpPort>8089</httpPort> -->
<webAppConfig>
<contextPath>/${project.build.finalName}</contextPath>
</webAppConfig>
</configuration>
</plugin>
3. 在eclipse工具中运行jetty插件的语句为:package jetty:run -Dmaven.test.skip=true
4. 具体运行操作选择运行项目-run as-run configurations如图1-图2所示:
子主题
子主题
Tomcat
Tomcat插件的配置
在maven配置文件中使用Tomcat插件的配置语句如下:
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<path>/${project.build.finalName}</path>
<!-- <httpPort>8089</httpPort> -->
</configuration>
</plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<path>/${project.build.finalName}</path>
<!-- <httpPort>8089</httpPort> -->
</configuration>
</plugin>
运行tomcat插件语句
package tomcat7:run -Dmaven.test.skip=true
使用tomcat插件需要注意的问题:
别在项目构建中加入jsp-api.jar;因为tomcat已经自带这个jar包;
Tomcat概述
Server标签设置的端口号为8005,shutdown=”SHUTDOWN” ,表示在8005端口监听“SHUTDOWN”命令,如果接收到了就会关闭Tomcat。
Tomcat中只有一个Server,一个Server可以有多个Service,一个Service可以有多个Connector和一个Container;
Server掌管着整个Tomcat的生死大权;
Service 是对外提供服务的;
Connector用于接受请求并将请求封装成Request和Response来具体处理;
Container用于封装和管理Servlet,以及具体处理request请求;
Connector最底层使用的是Socket来进行连接的,Request和Response是按照HTTP协议来封装的,所以Connector同时需要实现TCP/IP协议和HTTP协议
Tomcat的目录结构、文件结构
bin(执行目录)
各种操作脚本
catalina
tomcat启动参数调整
configtest
校验tomcat配置文件server.xml的格式、内容等是否合法、正确。
digest
service
安装tomcat服务,可用net start tomcat 启动
setclasspath
设置类加载路径的脚本
shutdown
shutdown.bat
关闭tomcat实例
startup
startup.bat
启动tomcat实例
tool-wrapper
Tomcat服务器的命令行工具包装器脚本
version
查看当前tomcat的版本号
lib(加载的jar包目录)
tomcat需要的jar包
lib
tomcat-xxx.jar
servlet.jar
lib
conf(配置文件目录)
server.xml(核心配置文件)
server.xml
server.xml
配置端口:<Connector port...
配置虚拟主机:<Engine>下添加一个<Host >
Server(服务器)
Service(服务)
Executor(线程池)
name
线程池名称
namePrefix
线程名称前缀
maxThreads
最大线程数
minSpareThreads
最小空闲线程数
Connector(连接器)
port
tomcat连接器端口
protocol
连接器协议
maxThreads
最大线程数
acceptCount
连接等待队列的大小
connectionTimeout
连接超时时间
redirectPort
重定向端口
Executor与Connector的关系
Connector指客户端请求服务器,tomcat需要建立、维护、管理这些连接,当Connector建立连接后,服务器会分配一个线程(可能
是从线程池)去服务这个连接,即执行doPost等方法,执行完,回收线程,这是一个同步的过程,是交给tomcat的Executor去处理的
是从线程池)去服务这个连接,即执行doPost等方法,执行完,回收线程,这是一个同步的过程,是交给tomcat的Executor去处理的
web.xml(应用程序配置文件)
web.xml
DefaultServlet(默认Servlet,加载静态文件)
JspServlet(专门处理Jsp)
mime-mapping(tomcat处理的文件类型)
web文件中的MIME.PNG
context.xml
context.xml
context.xml
catalina.policy(权限配置文件)
catalina.policy
权限相关 Permission ,Tomcat是跑在jvm上的,所以有些默认的权限。
tomcat-users.xml
tomcat-users.xml
tomcat-user.xml
logging.properties
logs(日志目录)
说明
这个目录中都是日志文件,记录了Tomcat启动和关闭的信息
如果启动Tomcat时有错误,那么异常也会记录在日志文件中
catalina日志
catalina-xxx.log
控制台日志
主要记录tomcat启动时候的信息
commons-daemon日志
主要存放利用服务方式启动tomcat作为守护进程的日志记录
localhost日志
localhost-xxx.log
Web应用的内部程序日志
主要存放应用初始化未处理的异常输出的日志,同时也包含部分tomcat的启动和暂停时的运行日志
建议保留
localhost-access日志
localhost_access_log_xxx.log
用户请求Tomcat的访问日志(这个文件在conf/server.xml里配置)
主要存放访问tomcat的日志,记录请求时间、资源和状态码等信息
建议关闭
host-manager日志
host-manager.xxx.log
Tomcat管理页面中的host-manager的操作日志,
主要存放tomcat的自带的manager项目的日志信息
建议关闭
manager日志
主要存放tomcat manager项目专有的日志文件
tomcat7-stderr日志
主要存放log4j的错误日志,因此在程序中要合理的捕捉异常
tomcat7-stdout日志
主要存放程序中的System语句打印的日志(包括系统抛出的异常)
webapps(应用程序目录)
docs
examples
hello1
hello2
host-manager
manager
ROOT:名为ROOT的应用在浏览器中访问是可以不给出应用名称,给了反而是错的
webapps
temp(临时目录)
temp
存放Tomcat的临时文件
这个目录下的东西可以在停止Tomcat后删除!
work(运行时生成的文件)
运行时生成的文件,最终运行的文件都在这里。
通过webapps中的项目生成的!可以把这个目录下的内容删除,再次运行时会生再次生成work目录。
当客户端用户访问一个JSP文件时,Tomcat会通过JSP生成Java文件,然后再编译Java文件生成class文件,生成的java和class文件都会存放到这个目录下。
Tomcat把有jsp生成Servlet放在目录下
LICENSE
> 许可证。
NOTICE
> 说明文件。
Tomcat的部署
Tomcat部署模式
显式部署
1. 在server.xml中添加content元素方式
添加context元素
server.xml中的Host加入一个Context(指定路径和文件地址)
例如:
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
<Context path="/Demo1" docBase="d:/Demo1" reloadable="true"></Context>
</Host>
2. 创建xml的方式
创建xml文件
隐式部署
隐式部署
将一个war文件或者整个应用程序复制到tomcat到webapps目录下
Tomcat部署方式
利用tomcat自动部署
把web应用拷贝到webapps目录。Tomcat在启动时会加载目录下的应用,并将编译后的结果放入work目录下。
使用Manager App控制台自动部署
在tomcat主页点击“Manager App” 进入应用管理控制台,可以指定一个web应用的路径或war文件。
修改config/server.xml文件部署
修改conf/server.xml文件,增加Context节点可以部署应用。
增加自定义的web文件部署
在conf/Catalina/localhost/ 路径下增加 xyz.xml文件,内容是Context节点,可以部署应用。
Tomcat架构模块设计、架构解析、整体构成
server
service
HTTP请求的过程
Jasper
Connector连接器
ProtocolHandler
Endpoint(处理底层的socket网络连接)
AbstractEndpoint
Acceptor内部类
Acceptor
监听请求
从线程池中拿到线程后等待连接到来
建立连接后,将请求任务丢到线程池中等待SocketProcessor处理
Executor
AsyncTimeout内部类
检查异步request的超时
Handler接口
用于处理收到的socket,在内部调用processor进行处理
SocketProcessor
如果不特殊配置,该线程池使用与Acceptor不同的池
LimitLatch
限制最大连接数
io
bio
同步阻塞 io
请求量较小时可考虑使用
tomcat8.5已经去掉该io
nio
使用jvm堆
由jvm管理,不容易出现内存泄露
io多路复用
处理流程图
nio2
异步io
windows内核提供了较成熟方案
Linux暂未有商业可用的异步io
如果在linux上使用该模式,是jvm在应用层模拟的
apr
比nio快在哪里
系统调用
c语言实现,与内核交互效率更高
更加开放的优化配置
tcp_defer_accept
延迟建立tcp连接直到真正的数据到来
有些操作系统不支持该配置
Jvm堆 vs 本地内存
apr使用本地内存,nio使用jvm堆
本地内存比jvm堆少拷贝一次
缺点:本地内存比jvm堆更难管理,出现内存泄露不容易定位
扩展:sendfile(零拷贝)
静态资源可考虑使用sendfile提升效率
不使用sendfile
使用sendfile
Processor
将Endpoint接收到的Socket封装成Request
解析应用层
http
由Processor组件解析
解析为Request对象时只解析了请求头
真正解析请求体是在Servlet调用获取请求体内容的时候,如果一直不调用则一直不解析
ajp
与Apache服务器交互的协议
Adapter
CoyoteAdapter
将Request交给Container进行具体的处理。
processor解析后生成Request对象,而Servlet容器需要ServletRequest对象
所以需要Adapter对Request、ServletRequest和Response、ServletResponse之间进行互转
Mapper
Connector运行模式
同步阻塞(BIO)
linux环境tomcat7默认使用方式
并发量高时,线程数较多,浪费资源
配制项:protocol=”HTTP/1.1”
一个线程处理一个请求
同步非阻塞(NIO)
利用Java的异步IO处理,可以通过少量的线程处理大量的请求,
可以复用同一个线程处理多个connection(多路复用)。
可以复用同一个线程处理多个connection(多路复用)。
linux环境tomcat8默认使用方式
配制项:protocol=”org.apache.coyote.http11.Http11NioProtocol”
Http11NioProtocol
LimitLatcher
Acceptor
Poller
SocketPorcessor
HttpProcessor
Http11Nio2Protocol
异步非阻塞(APR)
(Apache Portable Runtime/Apache可移植运行时)
(Apache Portable Runtime/Apache可移植运行时)
及AIO又叫NIO2
从操作系统层面解决io阻塞问题;与NIO的区别主要是操作系统的底层区别.
可以做个比喻:比作快递,
NIO就是网购后要自己到官网查下快递是否已经到了(可能是多次),然后自己去取快递;
AIO就是快递员送货上门了(不用关注快递进度)。
可以做个比喻:比作快递,
NIO就是网购后要自己到官网查下快递是否已经到了(可能是多次),然后自己去取快递;
AIO就是快递员送货上门了(不用关注快递进度)。
配制项:protocol=”org.apache.coyote.http11.Http11AprProtocol”
Http11AprProtocol
缺点
安装困难
配置apr模式之后还需要安装 apr 、 apr-utils 、tomcat-native包
运行高并发应用的首选模式
Container容器
容器
Web容器
new ServerSocket(8080)
Servlet容器
List<Servlet>
Catalina
(Engine)
(Engine)
Host
(webapp)
(webapp)
Context
(WEB-INF)
(WEB-INF)
Wrapper
servlet
servlet
每个Wrapper封装一个servlet请求
Pipeline
AccessLog
Realm
功能模块
按功能可拆分为解析http请求、管理Servlet
主要可分为两个组件:连接器和Servlet容器
图解Tomcat的总体架构、架构结构、架构图
Tomcat总体架构图
架构结构
发展方向
该架构为硬件资源稀缺的环境下产生的,即一个应用服务器部署多个应用,现在多为微服务架构,tomcat发展方向可以简化架构
Servlet容器
有多层容器,由外到内为Engine、Host、Context、Wrapper
各容器父类ContainerBase内有pipeline
pipeline为valve链
在pipeline末端都有响应的BasicValve
在BasicValve中会调用子容器Pipeline的FirstValve
各容器抽象出接口Container
主要功能为管理子容器
Container处理请求
使用Pipeline-Valve管道来处理(职责链模)
使用Pipeline-Valve管道来处理(职责链模)
与普通职责链的区别
每个Pipeline都有特定的Valve,而且是在管道的最后一个执行,这个Valve叫做BaseValve,BaseValve是不可删除的;
在上层容器的管道的BaseValve中会调用下层容器的管道。
四个子容器
StanderEngineValve
StanderHostValve
StanderContextValve
StanderWrapperValve
处理流程
connector调用EnginePipeline
依次会执行EngineValve1、EngineValve2等等,最后会执行StandardEngineValve,在StandardEngineValve中会调用Host管道
依次执行Host的HostValve1、HostValve2等,最后在执行StandardHostValve
再依次调用Context的管道和Wrapper的管道,最后执行到StandardWrapperValve。
当执行到StandardWrapperValve的时候,会在StandardWrapperValve中创建FilterChain,
并调用其doFilter方法来处理请求,这个FilterChain包含着我们配置的与请求相匹配的Filter和Servlet,
其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet的service方法,这样请求就得到了处理!
并调用其doFilter方法来处理请求,这个FilterChain包含着我们配置的与请求相匹配的Filter和Servlet,
其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet的service方法,这样请求就得到了处理!
当所有的Pipeline-Valve都执行完之后,并且处理完了具体的请求,
这个时候就可以将返回的结果交给Connector了,
Connector再通过Socket的方式将结果返回给客户端。
这个时候就可以将返回的结果交给Connector了,
Connector再通过Socket的方式将结果返回给客户端。
Tomcat源码解析、源码解读
源码导入与调试
Server接口
Server类接口关系图
Server接口由StandardServer类实现,并继承Lifecycle生命周期接口,实现对Server生命周期状态的管理
Service接口
Service类接口关系图
Service接口有StandService类实现,同样继承Lifecycle生命周期接口,实现对Service生命周期状态的管理
Tomcat启动流程与类加载机制
Tomcat启动时序图
Tomcat启动时序图
Jvm类加载器
双亲委派机制
BootstrapClassLoader
rt.jar
ExtClassLoader
ext目录
ApplicationClassLoader
classpath目录
Bootstrap中定义类加载器
BootstrapClassLoader 引导类加载器
ExtClassLoader 扩展类加载器
AppClassLoader 应用类加载器
CustomClassLoader 用户自定义类加载器
Tomcat类加载器
自定义类加载器
WebAppClassLoader
打破双亲委派
打破双亲委派模型(没有完全打破)
重写loadclass方法
判断是否在当前classloader缓存中已加载过
判断是否在parent缓存中已加载过
尝试使用ExtClassLoader加载
防止覆盖Jvm原生类
尝试自己加载,即调用findclass方法
交给parent加载
若加载失败,抛出异常
Servlet规范建议优先加载web应用目录下的类
tomcat自定义类加载器原因
为什么要这样做
各web应用之间的隔离与共享
1 .tomcat可能要部署多个web项目,多个项目可以依赖同一个类库不同版本jar包,但是不同版本的jar包要进行隔离
2. 多个项目不能共享一份jar包的class,不同的项目不能直接共用同一个类加载器
3. 避免类加载器的内存泄漏
4. 服务器本身也有自己依赖的jar包
5. 多个项目如果依赖同一个类库的相同版本,tomcat提供了一个共享类加载器sharedLoader,解决这个问题
6. 实现项目热部署需要
隔离性
多个web应用会有多个自己的WebAppClassLoader
web应用共享的类可以使用SharedClassLoader加载
tomcat自己目录下的类使用CatalinaClassLoader加载,与web应用隔离
web应用与tomcat共享的类可以使用CommonClassLoader加载
嵌入式Tomcat
定义:非传统的部署方式,将tomcat嵌入到主程序中进行运行
优点:灵活部署、任意指定位置、通过复杂的条件判断
调用tomcat提供的API实现,就是Tomcat.class这个类
Maven集成Tomcat启动分析
分析它的启动
Tomcat7RunnerCli是引导类,有个main方法
进一步分析
Tomcat7RunnerCli主要依靠Tomcat7Runner
分析结论
原来嵌入式启动就是调用了Tomcat的API来实现的
tomcat API接口
实现嵌入式Tomcat的基础
Tomcat本身提供了外部可以调用的API
Tomcat类(在Tomcat6或之前的版本,这个类叫做Embedded)
1. 位于:org.apache.catalina.startup.Tomcat
2. 该类由public修饰,外部可调用
3. 该类有Server、Service、Engine、Connector、Host等属性
4. 该类有init()、start()、stop()、destroy()等方法
5. 了解这个类的时候结合server.xml来理解效果更佳
分析得出的结论
Tomcat类是外部调用Tomcat的接口(看源码的时候有注释的地方要特别注意)
手写嵌入式tomcat思路
1. 新建一个Tomcat对象
2. 设置Tomcat的端口号
3. 设置Context的目录
4. 添加Servlet容器
5. 调用Tomcat对象的start()方法
6. 强制Tomcat等待
Tomcat性能优化
性能优化的三个指标
降低响应时间
提高系统吞吐量(QPS)
提高服务的可用性
性能优化的原则
具体情况具体分析
积少成多
性能优化工具
JConsole
内置的Java性能分析器
JMeter
基于Java的压力测试工具
Tomcat中server.xml的优化
Connector优化
方法:连接器模式改为NIO模式
原因:NIO模式最大化压榨了CPU,把时间片更好利用起来;NIO适合大量长连接
Servlet优化
方法:去掉不必要的资源,例如:JspServlet;Session也可以移除
Valve优化
方法:移除掉AccessLogValve
原因:Valve实现都需要消耗Java应用的计算时间,一般可以使用Nginx计算日志
Context优化
方法:关闭自动加载
原因:自动加载增加运行开销,并且很容易内存溢出
Executor优化
方法:配置线程池
JSP预编译优化
方法:可以使用ant先编译Jsp
方法:Jspservlet开发模式(development)设置为false
SpringBoot中Tomcat的优化
1. 设置线程池
server.tomcat.max-threads
2. 关闭Accesslog日志
server.tomcat.accesslog
优化思路
conf/server.xml核心组件
Connector
Context
conf/server.xml非核心组件
Listener
Global Resources
Valve
Realm
conf/web.xml
全局的web.xml文件有些标签用不到的,可以删除掉。
JVM层面
配置优化
减少web.xml/server.xml中标签
调整优化server.xml中标签
Connector标签
Host标签
Context标签
启动速度优化
删除没用的web应用
关闭websocket
随机数优化
多个线程启动web应用
其他方面优化
优化指标
server.xml优化
web.xml优化
常见问题排查
CPU使用率过高
拒绝连接
tomcat自带管理界面
psi-probe
线程参数
Apr库
ssl
native内存
sendfile
deferAccept
Tomcat的设计模式
模板方法
Lifecycle
模板模式
模版设计模式
模版设计模式定义:模板方法模式抽象出某个业务操作公共的流程,将流程分为几个步骤,其中有一些步骤是固定不变的,有一些步骤是变
化的,固定不变的步骤通过一个基类来实现,而变化的部分通过钩子方法让子类去实现,这样就实现了对系统中流程的统一化规范化管理
化的,固定不变的步骤通过一个基类来实现,而变化的部分通过钩子方法让子类去实现,这样就实现了对系统中流程的统一化规范化管理
tomcat中的模版设计模式:tomcat中关于生命周期管理的地方很好应用了模板方法模式,在一个组件的生命周期中都会涉及到init(初始化),
start(启动),stop(停止),destory(销毁),而对于每一个生命周期阶段其实都有固定一些事情要做,比如判断前置状态,设置后置状态,
以及通知状态变更事件的监听者等,而这些工作其实是可以固化的,所以Tomcat中就将每个生命周期阶段公共的部分固化,然后通过
initInternal,startInternal,stopInternal,destoryInternal这几个钩子方法开放给子类去实现具体的逻辑
start(启动),stop(停止),destory(销毁),而对于每一个生命周期阶段其实都有固定一些事情要做,比如判断前置状态,设置后置状态,
以及通知状态变更事件的监听者等,而这些工作其实是可以固化的,所以Tomcat中就将每个生命周期阶段公共的部分固化,然后通过
initInternal,startInternal,stopInternal,destoryInternal这几个钩子方法开放给子类去实现具体的逻辑
说明
1. 基类LifecycleBase实现了Lifecycle接口并实现init、start、stop、destroy等方法
2. init()方法内部模板化初始化流程,抽象具体的实现initInternal()方法
3. start()方法内部模板化启动流程,抽象具体的实现startInternal()方法
4. stop()方法内部模板化停止流程,抽象具体的实现stopInternal()方法
5. destroy()方法内部模板化释放流程,抽象具体的实现destroyInternal()方法
责任链模式
责任链
分别处理request
责任链设计模式
责任链设计模式定义:当系统在处理某个请求的时候,请求需要经过很多个节点进行处理,每个节点只关注自己的应该做的工作,做完自己的
工作以后,将工作转给下一个节点进行处理,直到所有节点都处理完毕
工作以后,将工作转给下一个节点进行处理,直到所有节点都处理完毕
tomcat中的责任链设计模式:tomcat中每一个容器都会有一个Pipeline,而一个Pipeline又会具有多个Valve阀门,其中StandardEngine对应
的阀门是StandardEngineValve,StandardHost对应的阀门是StandardHostValve,StandardContext对应的阀门是StandardContextValve,
StandardWrapper对应的阀门是StandardWrapperValve。这里每一Pipeline就好比一个管道,而每一Valve就相当于一个阀门,一个管道可以
有多个阀门,而对于阀门来说有两种,一种阀门在处理完自己的事情以后,只需要将工作委托给下一个和自己在同一管道的阀门即可,第二种阀
门是负责衔接各个管道的,它负责将请求传递给下个管道的第一个阀门处理,而这种阀门叫Basic阀门,它是每个管道中最后一个阀门,上面的
Standard*Valve都属于第二种阀门
的阀门是StandardEngineValve,StandardHost对应的阀门是StandardHostValve,StandardContext对应的阀门是StandardContextValve,
StandardWrapper对应的阀门是StandardWrapperValve。这里每一Pipeline就好比一个管道,而每一Valve就相当于一个阀门,一个管道可以
有多个阀门,而对于阀门来说有两种,一种阀门在处理完自己的事情以后,只需要将工作委托给下一个和自己在同一管道的阀门即可,第二种阀
门是负责衔接各个管道的,它负责将请求传递给下个管道的第一个阀门处理,而这种阀门叫Basic阀门,它是每个管道中最后一个阀门,上面的
Standard*Valve都属于第二种阀门
tomcat责任链处理过程:当用户请求服务器的时候,Connector会接受请求,从Socket连接中根据http协议解析出对应的数据,构造Request和
Response对象,然后传递给后面的容器处理,顶层容器是StandardEngine,StandardEngine处理请求其实是通过容器的Pipeline进行的,而
Pipeline其实最终是通过管道上的各个阀门进行的,当请求到达StandardEngineValve的时候,此阀门会将请求转发给对应StandardHost的
Pipeline的第一个阀门处理,然后以此最终到达StandardHostValve阀门,它又会将请求转发给StandardContext的Pipeline的第一个阀门,这样
以此类推,最后到达StandardWrapperValve,此阀门会根据Request来构建对应的Servelt,并将请求转发给对应的HttpServlet处理。从这里可
以看出其实Tomcat核心处理流程就是通过责任链一步步的组装起来的
Response对象,然后传递给后面的容器处理,顶层容器是StandardEngine,StandardEngine处理请求其实是通过容器的Pipeline进行的,而
Pipeline其实最终是通过管道上的各个阀门进行的,当请求到达StandardEngineValve的时候,此阀门会将请求转发给对应StandardHost的
Pipeline的第一个阀门处理,然后以此最终到达StandardHostValve阀门,它又会将请求转发给StandardContext的Pipeline的第一个阀门,这样
以此类推,最后到达StandardWrapperValve,此阀门会根据Request来构建对应的Servelt,并将请求转发给对应的HttpServlet处理。从这里可
以看出其实Tomcat核心处理流程就是通过责任链一步步的组装起来的
过程梳理
1. 请求被Connector组件接收,创建Request和Response对象
2. Connector将Request和Response交给Container,先通过Engine的Pipeline组件流经内部的每个Valve
3. 请求流转到Host的Pipeline组件中,并且经过内部Valve过滤
4. 请求流转到Context的Pipeline组件中,并且经过内部Valve过滤
5. 请求流转到Wrapper的Pipeline组件中,并且经过内部Valve过滤
6. Wrapper内部的WrapperValve创建FilterChain实例,调用指定的Servlet实例处理请求
7. 返回
观察者
Tomcat的工作模式
按照作为servlet容器分类
独立的servlet容器
servlet容器是web服务器的一部分
进程内的servlet容器
servlet容器是作为web服务器的插件和java容器的实现,
web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。
反应速度快但伸缩性不足;
web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。
反应速度快但伸缩性不足;
进程外的servlet容器
servlet容器运行于web服务器之外的地址空间,并作为web服务器的插件和java容器实现的结合。
反应时间不如进程内但伸缩性和稳定性比进程内优;
反应时间不如进程内但伸缩性和稳定性比进程内优;
请求模式分类
作为应用程序服务器
请求来自于前端的web服务器,这可能是Apache, IIS, Nginx等
作为独立服务器
请求来自于web浏览器
Tomcat中的IO模型、线程模型
IO过程
以Read为例,分为两个阶段
将网卡从数据copy到内核空间
将内核空间的数据copy到用户空间
将网卡从数据copy到内核空间
将内核空间的数据copy到用户空间
同步阻塞
同步非阻塞
多路IO复用
异步IO
阻塞式(BIO)
非阻塞式(NIO)
Tomcat的Sesssion会话
浏览器通过在cookie中带着JSESSIONID或者重写URL实现会话
分布式session
tomcat提供了主从方案和复制session方案
主从方案依赖于负载均衡,并且需要节点较多
复制方案在小集群可行,大集群会导致网络拥堵
tomcat提供了可配置的redis共享session
Spring大都使用Spring Redis Session方案
Session清理
由StandardContext调用StandardManager的backgroundProcess方法实现
默认每六次process清理一次session,即60s
Session管理
Context中Manager对象
Tomcat的使用
本地访问
http://www.localhost:8080
http://127.0.0.1:8080
http://真实ip地址:8080
如果不写具体路径,默认访问ROOT下的index文件。其他资源,不写具体路径,也访问该资源下的index文件
安装、启动
配置端口
创建JavaWeb应用
手动
静态网站
webapps
hello1
index.html
动态网站
webapps
hello2
WEB-INF
web.xml
classes:放class文件
lib:放jar包
静态或动态页面,但此时无法被客户断访问
静态或动态页面
index.html
index.jsp
Myeclipse自动生成
配置外部应用(了解)
方式1
conf/server.xml
<Host>
添加<Context>元素
server文件截图.png
<Context path="hello33" docBase="e:/hello3"/>
访问路径:http://localhost:8080/hello33/index.html
方式2
conf/Catalina/localhost
创建hello33.xml
在文件中编写<Context docBase="e:/hello3"/>
访问路径:http://localhost:8080/hello33/index.html
配置虚拟主机
1,conf/server文件中Connector元素修改端口
2,C:\WINDOWS\system32\drivers\etc\hosts中绑定www.huangsunting.com到127.0.0.1
3,server文件中另外添加一个<Host>
配置host.png
配置虚拟主机(激情五月天).mp4
server文件元素介绍.PNG
其他
一键启动
各组件都有生命周期,所以抽象出接口LifeCycle
主要功能为生命周期方法,start、init、stop、destroy
父组件负责启动子组件,只需启动Server组件,即可启动整个tomcat
类图
定时任务
StandardEngine会在init的时候使用schedule启动一个定时任务
该定时任务会调用当前容器以及子容器的backgroundprocess方法,所以各个容器可以依托该定时任务做一些操作
在执行定时任务的时候,会产生周期性的事件,说明容器还活着,可以干点什么事情
热加载
默认关闭,需要手动开启,配置loadable=true
StandardContext容器重写了backgroundProcess方法
扫描webapp目录下各个类文件是否有变更,如果有变更,调用context的reload方法
停止和销毁context容器及其子容器(即Servlet)
停止和销毁context下的filter和listener
停止和销毁context下的pipeline和valve
停止和销毁context的classloader及其加载的类
重新启动和初始化context,以及创建前四步销毁的组件
该reload并没有调用manager相关方法,即session没有被销毁
热部署
StandardHost容器注册定时任务事件监听器实现
粗粒度扫描,只扫描文件夹或者war包是否新增删除
如果扫描到文件夹被移除,则会把context销毁掉
如果扫描到有新增的文件夹,则创建context
扩展方式
Valve
各个Container都有Pipeline,可以添加Valve扩展
listener
各个Container状态改变时都有事件产生
线程池
扩展线程池
重写jvm线程池的execute方法
捕获RejectedException异常后执行队列的force方法,再尝试入队一次,入队失败再抛出RejectedException
记录当前线程池任务数
扩展LinkedBlockingQueue
重写offer方法
判断线程数是否达到最大线程,是则直接尝试塞入
判断任务数是否小于当前线程数,是则直接尝试塞入
判断任务数是否大于当前线程数,是则返回false
与jvm不同:当线程数没有达到最大线程数并且没有空闲线程的时候,优先创建线程
Tomcat的集群
Nginx
Nginx缺点
1、适应范围较小,仅能支持http、https、Email协议。
2、对后端服务器的健康检查,只支持通过端口检测,不支持url来检测。
比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,
Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,
如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。
Nginx优点
1、工作在网络7层之上,可针对http应用做一些分流的策略,如针对域名、目录结构,它的正规规则比HAProxy更为强大和灵活,所以,目前为止广泛流行。
2、Nginx对网络稳定性的依赖非常小,理论上能ping通就能进行负载功能。
3、Nginx安装与配置比较简单,测试也比较方便,基本能把错误日志打印出来。
4、可以承担高负载压力且稳定,硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS小。
5、Nginx可以通过端口检测到服务器内部的故障,如根据服务器处理网页返回的状态码、超时等,并会把返回错误的请求重新提交到另一个节点。
6、不仅仅是优秀的负载均衡器/反向代理软件,同时也是强大的Web应用服务器。LNMP也是近些年非常流行的Web架构,在高流量环境中稳定性也很好。
7、可作为中层反向代理使用。
8、可作为静态网页和图片服务器。
9、Nginx社区活跃,第三方模块非常多,相关的资料在网上比比皆是。
2、Nginx对网络稳定性的依赖非常小,理论上能ping通就能进行负载功能。
3、Nginx安装与配置比较简单,测试也比较方便,基本能把错误日志打印出来。
4、可以承担高负载压力且稳定,硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS小。
5、Nginx可以通过端口检测到服务器内部的故障,如根据服务器处理网页返回的状态码、超时等,并会把返回错误的请求重新提交到另一个节点。
6、不仅仅是优秀的负载均衡器/反向代理软件,同时也是强大的Web应用服务器。LNMP也是近些年非常流行的Web架构,在高流量环境中稳定性也很好。
7、可作为中层反向代理使用。
8、可作为静态网页和图片服务器。
9、Nginx社区活跃,第三方模块非常多,相关的资料在网上比比皆是。
IO多路复用epoll
轻量级
功能模块少
代码模块化
CPU亲和(affinity)
Nginx安装
rpm依赖包下载地址:http://www.rpmfind.net/
环境依赖
对于依赖库的安装,如果环境允许,推荐是使用yum安装方式。
依赖包 下载地址
openssl库 http://www.rpmfind.net/
zlib库 http://www.zlib.net/
pcre库 https://sourceforge.net/projects/pcre/files/pcre/
zlib库 http://www.zlib.net/
pcre库 https://sourceforge.net/projects/pcre/files/pcre/
依赖包的下载
安装openssl库
rpm -ivh openssl-1.0.1e-57.el6.x86_64.rpm
安装zlib库
tar -zxvf zlib-1.2.11.tar.gz
cd zlib-1.2.11
./configure
make && make install
cd zlib-1.2.11
./configure
make && make install
安装pcre库
tar -zxvf pcre-8.41.tar.gz
cd pcre-8.41
./configure --prefix=/usr/local/pcre
make
make install
cd pcre-8.41
./configure --prefix=/usr/local/pcre
make
make install
安装Nginx
源码编译方式
系统版本
Red Hat 6.6
注意:发行版本为7.x以上的,系统服务、防火墙端口指令与旧版本不同。
Nginx (组件)
下载地址
http://nginx.org/en/download.html
1. 创建运行用户
useradd -s /sbin/nologin nginx
2. 源码包解压安装
注意:pcre是源码目录,不是安装后的目录,也就是解压完所得到的目录。
tar -zxvf nginx-1.12.2.tar.gz
cd nginx-1.12.2
./configure --prefix=/home/nginx/ --with-pcre=~/pcre-8.41 --with-http_ssl_module
make
make install
cd nginx-1.12.2
./configure --prefix=/home/nginx/ --with-pcre=~/pcre-8.41 --with-http_ssl_module
make
make install
3. 修改端口号和服务地址
端口和地址,视自己情况而定
cd /home/nginx/conf/
vi nginx.conf
修改:
listen 88 #自己分配
server_name 10.219.14.115
vi nginx.conf
修改:
listen 88 #自己分配
server_name 10.219.14.115
4. 修改运行用户,和添加安装目录所属用户
cd /home/
chown -R nginx:nginx nginx/
chown -R nginx:nginx nginx/
vi /home/nginx/conf/nginx.conf
在文件头部,去掉注释,修改user 为nginx
在文件头部,去掉注释,修改user 为nginx
在文件头部,去掉注释,修改user 为nginx
5. 开放端口
开放端口命令: /sbin/iptables -I INPUT -p tcp --dport 88-j ACCEPT
保存:/etc/rc.d/init.d/iptables save
重启服务:/etc/init.d/iptables restart
保存:/etc/rc.d/init.d/iptables save
重启服务:/etc/init.d/iptables restart
6. 添加系统服务脚本
源码安装方式不提供系统服务脚本,所以我们只能新建脚本文件。
cd /etc/init.d/
touch nginx
vi nginx
chmod +x nginx
chkconfig --add nginx
chkconfig --level 35 nginx on
touch nginx
vi nginx
chmod +x nginx
chkconfig --add nginx
chkconfig --level 35 nginx on
注意修改标红的两处地方,也就是执行程序和配置文件。都是自己的安装目录下。
代码:地址——https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginxinit/
#!/bin/sh
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig: - 85 15
# description: NGINX is an HTTP(S) server, HTTP(S) reverse \
# proxy and IMAP/POP3 proxy server
# processname: nginx
# config: /etc/nginx/nginx.conf
# config: /etc/sysconfig/nginx
# pidfile: /var/run/nginx.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0
nginx="/usr/sbin/nginx"
prog=$(basename $nginx)
NGINX_CONF_FILE="/etc/nginx/nginx.conf"
[ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx
lockfile=/var/lock/subsys/nginx
make_dirs() {
# make required directories
user=`$nginx -V 2>&1 | grep "configure arguments:\
.*--user=" | sed 's/[^*]*--user=\([^ ]*\).*/\1/g' -`
if [ -n "$user" ]; then
if [ -z "`grep $user /etc/passwd`" ]; then
useradd -M -s /bin/nologin $user
fi
options=`$nginx -V 2>&1 | grep 'configure arguments:'`
for opt in $options; do
if [ `echo $opt | grep '.*-temp-path'` ]; then
value=`echo $opt | cut -d "=" -f 2`
if [ ! -d "$value" ]; then
# echo "creating" $value
mkdir -p $value && chown -R $user $value
fi
fi
done
fi
}
start() {
[ -x $nginx ] || exit 5
[ -f $NGINX_CONF_FILE ] || exit 6
make_dirs
echo -n $"Starting $prog: "
daemon $nginx -c $NGINX_CONF_FILE
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}
stop() {
echo -n $"Stopping $prog: "
killproc $prog -QUIT
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}
restart() {
configtest || return $?
stop
sleep 1
start
}
reload() {
configtest || return $?
echo -n $"Reloading $prog: "
killproc $nginx -HUP
RETVAL=$?
echo
}
force_reload() {
restart
}
configtest() {
$nginx -t -c $NGINX_CONF_FILE
}
rh_status() {
status $prog
}
rh_status_q() {
rh_status >/dev/null 2>&1
}
case "$1" in
start)
rh_status_q && exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart|configtest)
$1
;;
reload)
rh_status_q || exit 7
$1
;;
force-reload)
force_reload
;;
status)
rh_status
;;
condrestart|try-restart)
rh_status_q || exit 0
;;
*)
echo $"Usage: $0
{start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
exit 2
esac
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig: - 85 15
# description: NGINX is an HTTP(S) server, HTTP(S) reverse \
# proxy and IMAP/POP3 proxy server
# processname: nginx
# config: /etc/nginx/nginx.conf
# config: /etc/sysconfig/nginx
# pidfile: /var/run/nginx.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0
nginx="/usr/sbin/nginx"
prog=$(basename $nginx)
NGINX_CONF_FILE="/etc/nginx/nginx.conf"
[ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx
lockfile=/var/lock/subsys/nginx
make_dirs() {
# make required directories
user=`$nginx -V 2>&1 | grep "configure arguments:\
.*--user=" | sed 's/[^*]*--user=\([^ ]*\).*/\1/g' -`
if [ -n "$user" ]; then
if [ -z "`grep $user /etc/passwd`" ]; then
useradd -M -s /bin/nologin $user
fi
options=`$nginx -V 2>&1 | grep 'configure arguments:'`
for opt in $options; do
if [ `echo $opt | grep '.*-temp-path'` ]; then
value=`echo $opt | cut -d "=" -f 2`
if [ ! -d "$value" ]; then
# echo "creating" $value
mkdir -p $value && chown -R $user $value
fi
fi
done
fi
}
start() {
[ -x $nginx ] || exit 5
[ -f $NGINX_CONF_FILE ] || exit 6
make_dirs
echo -n $"Starting $prog: "
daemon $nginx -c $NGINX_CONF_FILE
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}
stop() {
echo -n $"Stopping $prog: "
killproc $prog -QUIT
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}
restart() {
configtest || return $?
stop
sleep 1
start
}
reload() {
configtest || return $?
echo -n $"Reloading $prog: "
killproc $nginx -HUP
RETVAL=$?
echo
}
force_reload() {
restart
}
configtest() {
$nginx -t -c $NGINX_CONF_FILE
}
rh_status() {
status $prog
}
rh_status_q() {
rh_status >/dev/null 2>&1
}
case "$1" in
start)
rh_status_q && exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart|configtest)
$1
;;
reload)
rh_status_q || exit 7
$1
;;
force-reload)
force_reload
;;
status)
rh_status
;;
condrestart|try-restart)
rh_status_q || exit 0
;;
*)
echo $"Usage: $0
{start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
exit 2
esac
7. 服务脚本命令
启动:service nginx start
停止:service nginx stop
重启:service nginx restart
停止:service nginx stop
重启:service nginx restart
8. 访问
地址:http://10.219.14.115:88/
子主题
编译安装
wget http://nginx.org/download/nginx-1.12.2.tar.gz
useradd nginx
mkdir /usr/local/nginx
yum -y install pcre-devel openssl openssl-devel
tar -zxf nginx-1.12.2.tar.gz
cd nginx-1.12.2
./configure --prefix=/usr/local/nginx --user=nginx --with-http_ssl_module
make
make install
cd nginx-1.12.2
./configure --prefix=/usr/local/nginx --user=nginx --with-http_ssl_module
make
make install
nginx -c /usr/local/nginx/conf/nginx.conf
ps -A|grep nginx
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload
firewall-cmd --reload
http:/ip
yum方式
安装
yum -y install nginx
systemctl start nginx.service
systemctl stop nginx.service
systemctl restart nginx.service
systemctl enable nginx.service
ps -A|grep nginx
http://ip地址
Docker方式
Nginx与普通负载均衡软件的区别
普通的负载均衡软件
如LVS
其实现的功能只是对请求数据包的转发、传递,
从负载均衡下的节点服务器来看,接收到的请求,还是来自访问负载均衡器的客户端的真实用户
Nginx反向代理负载均衡
而反向代理就不一样了
反向代理服务器在接收访问用户请求后,会代理用户 重新发起请求代理下的节点服务器,最后把数据返回给客户端用户。
从负载均衡下的节点服务器来看,访问的节点服务器的客户端用户就是反向代理服务器,而非真实的网站访问用户。
Nginx负载均衡配置(LB)
Nginx负载均衡功能依赖于ngx_http_upstream_module模块
upstream_module和健康检测
upstream模块
ngx_http_upstream_module是负载均衡模块
可以实现网站的负载均衡功能即节点的健康检查
允许Nginx定义一组或多组节点服务器组
使用时,可通过 proxy_pass 代理方式把网站的请求发送到事先定义好的对应 Upstream组 的名字上。
upstream模块内参数与参数说明
server ip:port
负载均衡后端RealServer的IP或者域名,端口不写的话默认为80。
高并发场景用域名,再通过DNS进行负载均衡
weight
服务器权重
weight=n
权重,默认为1,权重越大接收的请求越多
max_fails
Nginx尝试连接后端主机失败的此时,这是值是配合 proxy_next_upstream、fastcgi_next_upstream和memcached_next_upstream这三个参数来使用的。当Nginx接收后端服务器返回这三个参数定义的状态码时,会将这个请求转发给正常工作的的后端服务器。如404、503、503,max_files=1
max_fails=n
最大尝试的失败次数,默认为1,0表示禁止失败尝试
fail_timeout
max_fails 和 fail_timeout 一般会关联使用,如果某台server在 fail_timeout 时间内出现了 max_fails 次连接失败,那么Nginx会认为其已经挂掉,从而在 fail_timeout 时间内不再去请求它,fail_timeout默认是 10s,max_fails默认是1,即默认情况只要是发生错误就认为服务器挂了,如果将max_fails设置为0,则表示取消这项检查
fail_timeout=10s
失败超时时间,默认是10秒,通常3s左右比较合适
backup
表示当前server是备用服务器,只有其它非backup后端服务器都挂掉了或很忙才会分配请求给它
标志服务器不可用,这个参数通常配合IP_HASH使用,保存ip哈希值
backup
热备配置,前段RealServer出现问题后会自动上线backup服务器
down
标志服务器永远不可用,可配合ip_hash使用
完整使用案例
upstream lvsServer{
server 191.168.1.11 weight=5 ;
server 191.168.1.22:82;
server example.com:8080 max_fails=2 fail_timeout=10s backup;
#域名的话需要解析的哦,内网记得hosts
}
server 191.168.1.11 weight=5 ;
server 191.168.1.22:82;
server example.com:8080 max_fails=2 fail_timeout=10s backup;
#域名的话需要解析的哦,内网记得hosts
}
详细介绍请访问官方
https://www.nginx.com/resources/admin-guide/load-balancer/
支持的代理方式有
proxy_pass请求转发
proxy_pass指令属于ngx_http_proxy_module模块
此模块可以将请求转发到另一台服务器,
在实际的反向代理工作中,会通过location功能匹配指定的URI,然后把接收到服务匹配URI的请求通过proyx_pass抛给定义好的upstream节点池。
location /download/ {
proxy_pass http://download/vedio/;
}
#这是前端代理节点的设置 #交给后端upstream为download的节点
proxy_pass http://download/vedio/;
}
#这是前端代理节点的设置 #交给后端upstream为download的节点
proxy模块内参数与参数说明
proxy_next_upstream
什么情况下将请求传递到下一个upstream
proxy_limite_rate
限制从后端服务器读取响应的速率
proxy_set_header
设置http请求header传给后端服务器节点,
如:可实现让代理后端的服务器节点获取访问客户端的这是ip
client_body_buffer_size
客户端请求主体缓冲区大小
proxy_connect_timeout
代理与后端节点服务器连接的超时时间
proxy_send_timeout
后端节点数据回传的超时时间
proxy_read_timeout
设置Nginx从代理的后端服务器获取信息的时间,表示连接成功建立后,Nginx等待后端服务器的响应时间
proxy_buffer_size
设置缓冲区大小
proxy_buffers
设置缓冲区的数量和大小
proxy_busy_buffers_size
用于设置系统很忙时可以使用的proxy_buffers大小
推荐为proxy_buffers*2
proxy_temp_file_write_size
指定proxy缓存临时文件的大小
fastcgi_pass
memcached_pass。
HTTP负载均衡配置
图解需要实现的效果
子主题
图解实际Nginx的配置
图解实际Nginx的配置
只需要在upstream上填写需要被访问的服务地址,和修改location
http {
upstream my_upstream {
server server1.example.com; #真实的提供服务的地址
server server2.example.com;
}
server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
}
upstream my_upstream {
server server1.example.com; #真实的提供服务的地址
server server2.example.com;
}
server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
}
Nginx的负载均衡
nginx支持许多应用程序负载平衡方法,用于HTTP,TCP和UDP负载平衡
负载均衡方式
Round-Robin(默认轮询)
请求按服务器列表顺序分发。
每一个请求按时间顺序均匀的分布到服务器中,宕机后,能自动从轮询列表中剔除
upstream backend {
server backend1.example.com;
server backend2.example.com;
}
server backend1.example.com;
server backend2.example.com;
}
least_conn(最少连接)
考虑到分配给服务器的权重,将每个请求发送到活动连接数最少的服务器。
请求被发送到具有服务器权重的活动连接数最少的服务器
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
least_conn;
server backend1.example.com;
server backend2.example.com;
}
hash(哈希)
请求根据用户定义的密钥(如客户端IP地址或URL)进行分发。
如果上游服务器组发生变化,nginx可以选择应用一致的哈希值来最小化负载的重新分配。
upstream backend {
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
ip_hash(ip哈希,仅限HTTP)
根据客户端IP地址的前三个八位字节分发请求。
根据客户端的IP地址来确定发送请求的服务器,
在这种情况下,使用IPv4地址的前三个八位字节或整个IPv6地址来计算哈希值。
该方法保证来自同一地址的请求到达同一台服务器,除非它不可用。
涉及到Session会话,可以使用该方案解决,这样同一客户端的请求都会被分发到同一台服务器上处理。
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
如果其中一个服务器需要临时删除,则可以使用该down参数标记,以便保留当前客户端IP地址的哈希值。
要由该服务器处理的请求将自动发送到组中的下一个服务器。
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
}
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
}
Nginx修改服务器权重
默认情况下,nginx使用循环方法根据其权重在组内的服务器之间分配请求。
指令的weight参数server设置服务器的权重,默认情况下为1:
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
server 192.0.0.1 backup;
}
server backend1.example.com weight=5;
server backend2.example.com;
server 192.0.0.1 backup;
}
在示例中,backend1.example.com的权重为5; 其他两台服务器的默认权重(1),
但IP地址为192.0.0.1的服务器被标记为备份服务器,除非其他服务器都不可用,否则不接收请求。
随着权重的这种配置,每六个请求,5个被送到backend1.example.com和一个backend2.example.com。
Nginx负载配置演示
这里使用的是轮询(默认)的方法配置负载。
首先我们准备2台提供服务的地址,最好被访问的时候可以看出区别。
准备服务主机
服务器软件不受限制,Apache,Nginx,tomcat等。
10.219.14.113:这台机提供服务的是Apache
10.219.14.112:这台机也是Nginx
10.219.14.113:这台机提供服务的是Apache
10.219.14.112:这台机也是Nginx
修改Nginx负载配置,轮询的方式(默认)
vi /home/nginx/conf/nginx.conf
子主题
开放端口
开放端口命令: /sbin/iptables -I INPUT -p tcp --dport 9090-j ACCEPT
保存:/etc/rc.d/init.d/iptables save
重启服务:/etc/init.d/iptables restart
保存:/etc/rc.d/init.d/iptables save
重启服务:/etc/init.d/iptables restart
测试,输入10.219.14.115,访问顺序为upstream的地址列表顺序。
输入地址后我们刷新页面可以来回切换服务器。就可以看到效果了。
子主题
子主题
Nginx的配置
Nginx的功能是通过配置文件实现的,使用Nginx就是会使用Nginx的配置文件
nginx配置文件位置
编译安装版本
/usr/local/nginx/conf/nginx.conf
yum安装版本
/etc/nginx/nginx.conf
Nginx配置文件nginx.conf的结构
通用(全局)配置参数
http{
http 协议通用参数
server{
虚拟机配置参数
}
server{
虚拟机配置参数
}
}
http 协议通用参数
server{
虚拟机配置参数
}
server{
虚拟机配置参数
}
}
全局通用参数
1. worker_processes
建议按照处理器数量进行设置, 4处理器设置为4
worker_processes 1;
ngx_core_module
ngx_core_conf_t
ngx_set_worker_processes
NGX_MAIN_CONF|NGX_DIRECT_CONF|NGX_CONF_TAKE1
2.worker_connections
events下面
每个进程的线程数量, 就是进程中线程池的大小
events {
worker_connections 1024;
}
worker_connections 1024;
ngx_event_core_module
ngx_event_conf_t
ngx_event_connections
NGX_EVENT_CONF|NGX_CONF_TAKE1
3. pid
pid文件用于存储 Nginx 主进程号
4.access_log
日志文件, 如果打开可以记录日志,但同时服务器的性能也会下降
http通用参数
1. ContentType
类型映射, 也就是多媒体文件类型映射.
include mime.types;
default_type application/octet-stream;
default_type application/octet-stream;
include mime.types;
ngx_conf_module
ngx_conf_include
NGX_ANY_CONF|NGX_CONF_TAKE1
types
ngx_http_core_module
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_core_loc_conf_t
types
ngx_http_core_types
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|
NGX_HTTP_LOC_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS
default_type application/octet-stream;
ngx_http_core_module
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_core_loc_conf_t
default_type
ngx_conf_set_str_slot
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|
NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1
2. keepalive
指定HTTP/1.1 协议时候的服务器端的长连接等待超时时间
keepalive_timeout 65;
ngx_http_core_module
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_core_loc_conf_t
keepalive_timeout
ngx_http_core_keepalive
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|
NGX_HTTP_LOC_CONF|NGX_CONF_TAKE12
3.gzip on
对服务器的响应进行gzip压缩传输, 可以节省网络流量.
但是问题有两个
一个是老旧浏览器(IE6)不支持
第二个会占用服务器的处理器.
4.sendfile on;
ngx_http_core_module
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_core_loc_conf_t
sendfile
ngx_conf_set_flag_slot
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|
NGX_HTTP_LIF_CONF|NGX_CONF_FLAG
server
ngx_http_core_module
ngx_http_core_server
NGX_HTTP_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS
listen 80;
ngx_http_core_module
NGX_HTTP_SRV_CONF_OFFSET
ngx_http_core_listen
ngx_http_listen_opt_t
根据listen 子项,配置该结构
ngx_http_add_address
ngx_http_conf_addr_t
将ngx_http_listen_opt_t赋值为该结构体,并初始化该结构体
将ngx_http_core_srv_conf_t赋值给该结构体的servers
NGX_HTTP_SRV_CONF|NGX_CONF_1MORE
server_name localhost;
ngx_http_core_module
NGX_HTTP_SRV_CONF_OFFSET
ngx_http_core_server_name
ngx_http_core_srv_conf_t->server_names
server = cscf
name = "localhost"
NGX_HTTP_SRV_CONF|NGX_CONF_1MORE
location /
ngx_http_core_module
NGX_HTTP_SRV_CONF_OFFSET
ngx_http_core_location
NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|
NGX_CONF_BLOCK|NGX_CONF_TAKE12
root html;
子主题
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_core_root
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|
NGX_HTTP_LIF_CONF|NGX_CONF_TAKE1
index index.html index.htm;
ngx_http_index_module
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_index_set_index
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|
NGX_HTTP_LOC_CONF|NGX_CONF_1MORE
error_page 500 502 503 504 /50x.html;
ngx_http_core_module
NGX_HTTP_LOC_CONF_OFFSET
ngx_http_core_error_page
NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|
NGX_HTTP_LIF_CONF|NGX_CONF_2MORE
location = /50x.html
root html;
涉及性能的参数
worker_processes
worker_cpu_affinity
worker_rlimit_nofile
event module
epoll
worker_connections
Nginx的虚拟主机
在一个Web服务器上通过服务器软件模拟多台Web 服务器, 其中每个虚拟的Web服务器称为一个虚拟主机.
虚拟主机的好处是可以充分复用同一个web服务器. 对于用户来说, 用户感觉是多个网站.
Nginx 配置文件中 每个 server{} 块对应一个虚拟主机
三种虚拟主机
基于域名的虚拟主机(最常用的虚拟主机)
需要为服务器指定多个域名
域名资源解析方便, 便于用户记忆, 用户体验好
基于IP虚拟主机
需要为服务器指定多个IP地址
需要租用IP
很少使用这种方式
基于端口的虚拟主机
绑定到服务器的多个端口
默认80端口只有一个
使用其他端口号提供服务, 因为用户需要记忆端口, 用户的体验差
测试使用虚拟主机
编写nginx文件
请求 t1.canglaoshi.org 访问 t1文件夹 index.html文件
server{
listen 80;
server_name t1.canglaoshi.org;
location / {
root t1;
index index.html;
}
}
server{
listen 80;
server_name t1.canglaoshi.org;
location / {
root t1;
index index.html;
}
}
Nginx的使用
在Nginx文件夹/usr/local/nginx中
添加新文件夹t1和文件index.html
<html>
<body>
<h1>Hello t1.canglaosho.org</h1>
</body>
</html>
<body>
<h1>Hello t1.canglaosho.org</h1>
</body>
</html>
测试Nginx的效果
测试:
http://t1.canglaoshi.org
http://t1.canglaoshi.org
Nginx的HTTPS加密通讯
HTTPS = HTTP Over SSL = 基于SSL加密的HTTP通讯
> HTTPS加密通讯不会被第三方监听.HTTPS是安全通讯.
证书工作原理:
1. 浏览器中内嵌了证书颁发机构的根证书, 用于鉴定证书的真伪
2. 建立网站时候需要向证书颁发机构申请证书, 用于证明网站域名的真实性.
- 阿里云等云计算服务器可以代为签发证书
3. 将证书配置到Nginx等Web服务器
4. 在进行 HTTPS 通讯时候, 浏览器会自动从服务器下载证书并且自动鉴定证书真伪, 并且自动建立加密通讯通道.
1. 下载证书文件到 /usr/local/nginx/conf/cert
2. 更新 nginx.conf 的配置, 并且测试配置文件
3. 重新启动Nginx
4. 在客户端配置域名解析
5. 利用客户端访问 https://tts.canglaoshi.org
niginx.conf
Nginx的反向代理集群
优势
提高网站整体的并发处理能力
配置
1. 进行合理的规划: 规定每个服务器所扮演的角色.
2. 配置每个Tomcat应用服务器, 并且启动测试.
3. 配置Nginx服务器, 测试配置文件
4. 重新启动Nginx
5. 客户端配置域名解析
6. 客户端浏览器访问域名, 可以看到多台Tomcat为一个域名服务
nginx.conf
阿里云配置Nginx转发到Tomcat
1.配置Nginx
2. 测试 重新启动nginx
3. 在阿里云的dns解析中解析 两个域名tom.canglaoshi.org, 1711.canglaoshi.org 到服务器ip
4. 测试: 用浏览器访问这两个域名.
Nginx 集群转发策略
1. 轮询(默认)
2.指定权重
3. ip_hash
4. fair(第三方)
5. url_hash(第三方)
Nginx的应用场景 与 衍生应用
代理服务
反向代理(proxy_pass)
负载均衡
七层(upstream)
round robin
ip hash
url hash
weight
fair(第三方)
四层(Nginx PLUS)
缓存
proxy_cache
HTTPS
动静分离
静态资源(动态资源)
跨域访问
防盗链
动态资源(tomcat,php-fpm)
限流
算法
令牌桶
漏桶
实现
limit_conn_zone
limit_req_zone
ngx_http_upstream_module
Openresty
Kong
Tengine
Nginx与LUA开发
WAF
Nginx的main
ngx_strerror_init
按顺序将系统错误码及错误信息初始化至本地
ngx_get_options
处理程序启动参数
ngx_time_init
初始化nginx内部时间
ngx_log_init
根据编译时生成的参数,初始化日志
ngx_create_pool
使用内存对齐的方式生成内存池
ngx_memalign
ngx_save_argv
保存启动参数到本地
ngx_process_options
根据启动参数、编译参数,确认配置文件路径
nginx.conf
ngx_os_init
配置系统相关选项
ngx_init_setproctitle
保存环境变量到本地,为后续修改进程名做准备
ngx_crc32_table_init
没看明白
ngx_add_inherited_sockets
从环境变量继承socket,没看明白怎么用
ngx_preinit_modules
对module的index、name赋值
ngx_init_cycle
初始化配置文件
判断是否为控制命令
如果为控制命令,则直接将对应信号发送至运行中的对应pid的nginx
ngx_init_signals
初始化信号、控制命令及信号处理函数
ngx_daemon
以守护进程方式运行
将stdin、stdout映射到/dev/null
ngx_create_pidfile
将pid写入pid文件
ngx_log_redirect_stderr
将stderr重定向到ngx_log_t
开始循环执行程序
ngx_master_process_cycle
ngx_single_process_cycle
常见模块
官方模块
http_stub_status_module
http_random_index_module
http_sub_module
limit_conn_module
limit_req_module
http_access_module
http_auth_basic_module
proxy_pass
upstream
第三方模块
memc-nginx-module
echo-nginx-module
lua-nginx-module
srcache-nginx-module
drizzle-nginx-module
rds-json-nginx-module
http_geoip_module
ngx_cache_purge
Nginx+Keepalived负载高可用(HA)
Keepalive高可用的原理?
keepalive的发展
起初:为LVS设计的,专门用来监控lvs各个服务节点的状态
后来:加入了VRRP的功能,因此除了lvs,也可以作为其他服务(nginx,haproxy)的高可用软件。
VRRP是什么?
virtual router redundancy protocal(虚拟路由器冗余协议)的缩写
目的:为了解决静态路由出现的单点故障,它能够保证网络可以不间断的稳定的运行
Keepalive的功能
具有LVS cluster node healthcheck
具有LVS director failover
Keepalived安装
环境准备
涉及到依赖包(系统发行版6.6以下版本1.0.0.1)
rpm依赖包下载地址:http://www.rpmfind.net/ ,搜索对应包名,查找el6系统版本。
libnfnetlink-1.0.0-1.el6.x86_64.rpm
libnfnetlink-devel-1.0.0-1.el6.x86_64.rpm
libnl-3.2.25.tar.gz
libnl-devel-1.1.4-2.el6.x86_64.rpm
libnfnetlink-devel-1.0.0-1.el6.x86_64.rpm
libnl-3.2.25.tar.gz
libnl-devel-1.1.4-2.el6.x86_64.rpm
依赖包安装
有网络情况,且配置了yum源:
yum install libnfnetlink
yum install libnfnetlink-devel
yum install libnl*
yum install libnfnetlink-devel
yum install libnl*
无网络情况下,对应包类型的安装方法都一样:
rpm -ivh libnfnetlink-1.0.0-1.el6.x86_64.rpm
tar -zxvf libnl-3.2.25.tar.gz
cd libnl-3.2.25
./configure
make && make install
cd libnl-3.2.25
./configure
make && make install
安装Keepalived
tar -zxvf keepalived-1.3.5.tar.gz
cd keepalived-1.3.5
./configure –prefix=/usr/local/keepalived
make
make install
cd keepalived-1.3.5
./configure –prefix=/usr/local/keepalived
make
make install
配置Keepalived
mkdir /etc/keepalived
拷贝Keepalived解压目录下的一些文件
cp /root/keepalived-1.3.5/keepalived/etc/keepalived/keepalived.conf
/etc/keepalived/keepalived.conf
cp /root/keepalived-1.3.5/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/keepalived
cp /root/keepalived-1.3.5/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
/etc/keepalived/keepalived.conf
cp /root/keepalived-1.3.5/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/keepalived
cp /root/keepalived-1.3.5/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
添加系统服务
chkconfig --add keepalived
chkconfig --level 35 keepalived on
chkconfig --level 35 keepalived on
查看网卡名
ifconfig
子主题
修改/etc/keepalived/keepalived.conf
修改vrrp_instance VI_1中的interface 网卡名。不正确无法启动。
vi /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
state MASTER
interface eth1
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.16
192.168.200.17
192.168.200.18
}
}
state MASTER
interface eth1
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.16
192.168.200.17
192.168.200.18
}
}
启动Keepalived,验证
service keepalived start
ps -ef | grep keepalived
root 21769 1 0 04:07 ? 00:00:00 keepalived -D
root 21770 21769 0 04:07 ? 00:00:00 keepalived -D
root 21772 21769 0 04:07 ? 00:00:00 keepalived -D
root 21809 12328 0 04:13 pts/2 00:00:00 grep keepalived
ps -ef | grep keepalived
root 21769 1 0 04:07 ? 00:00:00 keepalived -D
root 21770 21769 0 04:07 ? 00:00:00 keepalived -D
root 21772 21769 0 04:07 ? 00:00:00 keepalived -D
root 21809 12328 0 04:13 pts/2 00:00:00 grep keepalived
Nginx心跳健康检查脚本
当Nginx宕机时,keepalived是无法切换到备机的,所以在检测到Nginx时,把对应的keepalived服务杀死,让它切换到备机上。
需要nmap支持,如果没有请安装。
脚本:
#!/bin/bash
# check nginx server status
NGINX=/home/nginx/sbin/nginx
PORT=9090
nmap localhost -p $PORT | grep "$PORT/tcp open"
#echo $?
if [ $? -ne 0 ];then
$NGINX -s stop
$NGINX
sleep 3
nmap localhost -p $PORT | grep "$PORT/tcp open"
[ $? -ne 0 ] && /etc/init.d/keepalived stop
fi
# check nginx server status
NGINX=/home/nginx/sbin/nginx
PORT=9090
nmap localhost -p $PORT | grep "$PORT/tcp open"
#echo $?
if [ $? -ne 0 ];then
$NGINX -s stop
$NGINX
sleep 3
nmap localhost -p $PORT | grep "$PORT/tcp open"
[ $? -ne 0 ] && /etc/init.d/keepalived stop
fi
Keepalived+Nginx高可用配置
采用Keepalived,通过VRRP协议将外网虚拟IP绑定到Nginx主/备机上,通过权重控制,当主机宕机后,Keepalived释放当前对主机的控制,转移到备机上。
Keepalived+Nginx高可用配置
1. 规划
外网VIP地址:10.219.14.200:9090
Nginx服务器地址:
主机(MASTER):10.219.14.115:9090
备机(BACKUP):10.219.14.111:9090
Server地址:
10.219.14.112:80
10.219.14.113:80
Nginx服务器地址:
主机(MASTER):10.219.14.115:9090
备机(BACKUP):10.219.14.111:9090
Server地址:
10.219.14.112:80
10.219.14.113:80
2. 准备主/备机的Nginx配置
参考Nginx负载均衡配置。
3. 配置Keepalived绑定2台机器
主/备机,只需修改state,real_server,priority这几项。
主机(Master)10.219.14.115:9090:
修改配置文件keepalived.conf,添加Nginx心跳检测脚本。
vi /etc/keepalived/keepalived.conf
修改:其它多余的代码可以删掉。
! Configuration File for keepalived
global_defs {
notification_email {
xxx@desay-svautomotive.com
}
notification_email_from xxx@desay-svauotomotive.com
smtp_server 1.1.1.1
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
global_defs {
notification_email {
xxx@desay-svautomotive.com
}
notification_email_from xxx@desay-svauotomotive.com
smtp_server 1.1.1.1
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
#Nginx服务检测脚本
vrrp_script check_nginx_alive {
script "/etc/keepalived/check_nginx_alive.sh"
interval 3
weight -10
}
vrrp_instance VI_1 {
state MASTER #备机 为BACKUP
interface eth1 #主/备机的网卡名需一样,若不一样请参考更改网卡名
virtual_router_id 55
priority 100 #备机比主机低即可
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.219.14.220 #VIP地址,一行一个
}
track_script {
check_nginx_alive #Nginx脚本,对应vrrp_script名字
}
}
virtual_server 10.219.14.220 9090 {
delay_loop 3
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 10.219.14.115 9090 { #主机真实地址,对应本机IP服务
weight 1
TCP_CHECK{
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 9090
}
}
}
vrrp_script check_nginx_alive {
script "/etc/keepalived/check_nginx_alive.sh"
interval 3
weight -10
}
vrrp_instance VI_1 {
state MASTER #备机 为BACKUP
interface eth1 #主/备机的网卡名需一样,若不一样请参考更改网卡名
virtual_router_id 55
priority 100 #备机比主机低即可
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.219.14.220 #VIP地址,一行一个
}
track_script {
check_nginx_alive #Nginx脚本,对应vrrp_script名字
}
}
virtual_server 10.219.14.220 9090 {
delay_loop 3
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP
real_server 10.219.14.115 9090 { #主机真实地址,对应本机IP服务
weight 1
TCP_CHECK{
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 9090
}
}
}
4. 测试高可用
原则上如果Keepalived的故障转移,是需要Keepalived自身宕掉,
所以我们上文中已经通过Nginx心跳监控,当Nginx宕机的时候,把Keepalived关掉,从而达到故障转移的效果。
开启Keepalived和Nginx
service nginx start
service keepalived start
service keepalived start
查看当前VIP指向的Nginx
ip addr show
Master(主机):10.219.14.115,可以看到VIP地址已经指向这台机器
子主题
salve(备机):10.219.14.111
子主题
宕机10.219.14.115
1. 当前我们指向的是10.219.14.115这台master机器,可以输入VIP地址10.219.14.220:9090测试。
子主题
2. 现在我们把10.219.14.115,Master主机的Nginx服务关闭。
查看slave备机的ip addr,也可以看到vip已经转移了,或者查看Keepalived日志。
ip addr show
子主题
cat /var/log/keepalived.
子主题
刷新页面:服务访问正常
子主题
Keepalived.conf配置文件详解
! Configuration File for keepalived
global_defs {
notification_email {
xxx@xxxx.com #接受报警的邮箱地址,每行一个
}
notification_email_from xxx@xxxxxx.com #发送报警的邮箱
smtp_server mail@xxxxxx.com #smtp服务器地址,可以是IP
smtp_connect_timeout 30 #连接超时时间
router_id LVS_DEVEL #表示运行keepalived服务器的一个标识。发邮件时显示在邮件主题的信息
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER #指定keepalived的角色,MASTER表示此主机是主服务器,BACKUP表示此主机是备用服务器
interface eth1 #指定HA监测网络的接口名,主备需要一样
virtual_router_id 55 #虚拟路由标识,这个标识是一个数字,同一个vrrp实例使用唯一的标识。即同一vrrp_instance下,MASTER和BACKUP必须是一致的
priority 100 #定义优先级,数字越大,优先级越高,在同一个vrrp_instance下,MASTER的优先级必须大于BACKUP的优先级
advert_int 1 #设定MASTER与BACKUP负载均衡器之间同步检查的时间间隔,单位是秒
authentication {
auth_type PASS #设置验证类型,主要有PASS和AH两种
auth_pass 1111 #设置验证密码,在同一个vrrp_instance下,MASTER与BACKUP必须使用相同的密码才能正常通信
}
virtual_ipaddress {
10.219.14.220 #设置虚拟IP地址(VIP),可以设置多个虚拟IP地址,每行一个
}
virtual_server 10.219.14.220 9090 { #设置虚拟服务器,需要指定虚拟IP地址和服务端口,IP与端口之间用空格隔开
delay_loop 6 #设置运行情况检查时间,单位是秒
lb_algo rr #设置负载调度算法,这里设置为rr,即轮询算法
lb_kind DR #设置LVS实现负载均衡的机制,有NAT、TUN、DR三个模式可选
persistence_timeout 50 #会话保持时间,单位是秒。这个选项对动态网页是非常有用的,为集群系统中的session共享提供了一个很好的解决方案。有了这个会话保持功能,用户的请求会被一直分发到某个服务节点,直到超过这个会话的保持时间。需要注意,这个会话保持时间是最大无响应超时时间,也就是说,用户在操作动态页面时,如果50秒内没有执行任何操作,那么接下来的操作会被分发到另外的节点,但是如果用户一直在操作动态页面,则不受50秒的时间限制
protocol TCP #指定转发协议类型,有TCP和UDP两种
real_server 10.219.14.115 9090 { #配置服务节点,需要指定real server的真实IP地址和端口,IP与端口之间用空格隔开
weight 1 #配置服务节点的权值,设置权值大小可以为不同性能的服务器分配不同的负载,可以为性能高的服务器设置较高的权值,而为性能较低的服务器设置相对较低的权值,这样才能合理地利用和分配系统资源
TCP_CHECK{
connect_timeout 3 #表示3秒无响应超时
nb_get_retry 3 #表示重试次数
delay_before_retry 3 #表示重试间隔
connect_port 9090 #连接端口,
}
}
}
global_defs {
notification_email {
xxx@xxxx.com #接受报警的邮箱地址,每行一个
}
notification_email_from xxx@xxxxxx.com #发送报警的邮箱
smtp_server mail@xxxxxx.com #smtp服务器地址,可以是IP
smtp_connect_timeout 30 #连接超时时间
router_id LVS_DEVEL #表示运行keepalived服务器的一个标识。发邮件时显示在邮件主题的信息
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 {
state MASTER #指定keepalived的角色,MASTER表示此主机是主服务器,BACKUP表示此主机是备用服务器
interface eth1 #指定HA监测网络的接口名,主备需要一样
virtual_router_id 55 #虚拟路由标识,这个标识是一个数字,同一个vrrp实例使用唯一的标识。即同一vrrp_instance下,MASTER和BACKUP必须是一致的
priority 100 #定义优先级,数字越大,优先级越高,在同一个vrrp_instance下,MASTER的优先级必须大于BACKUP的优先级
advert_int 1 #设定MASTER与BACKUP负载均衡器之间同步检查的时间间隔,单位是秒
authentication {
auth_type PASS #设置验证类型,主要有PASS和AH两种
auth_pass 1111 #设置验证密码,在同一个vrrp_instance下,MASTER与BACKUP必须使用相同的密码才能正常通信
}
virtual_ipaddress {
10.219.14.220 #设置虚拟IP地址(VIP),可以设置多个虚拟IP地址,每行一个
}
virtual_server 10.219.14.220 9090 { #设置虚拟服务器,需要指定虚拟IP地址和服务端口,IP与端口之间用空格隔开
delay_loop 6 #设置运行情况检查时间,单位是秒
lb_algo rr #设置负载调度算法,这里设置为rr,即轮询算法
lb_kind DR #设置LVS实现负载均衡的机制,有NAT、TUN、DR三个模式可选
persistence_timeout 50 #会话保持时间,单位是秒。这个选项对动态网页是非常有用的,为集群系统中的session共享提供了一个很好的解决方案。有了这个会话保持功能,用户的请求会被一直分发到某个服务节点,直到超过这个会话的保持时间。需要注意,这个会话保持时间是最大无响应超时时间,也就是说,用户在操作动态页面时,如果50秒内没有执行任何操作,那么接下来的操作会被分发到另外的节点,但是如果用户一直在操作动态页面,则不受50秒的时间限制
protocol TCP #指定转发协议类型,有TCP和UDP两种
real_server 10.219.14.115 9090 { #配置服务节点,需要指定real server的真实IP地址和端口,IP与端口之间用空格隔开
weight 1 #配置服务节点的权值,设置权值大小可以为不同性能的服务器分配不同的负载,可以为性能高的服务器设置较高的权值,而为性能较低的服务器设置相对较低的权值,这样才能合理地利用和分配系统资源
TCP_CHECK{
connect_timeout 3 #表示3秒无响应超时
nb_get_retry 3 #表示重试次数
delay_before_retry 3 #表示重试间隔
connect_port 9090 #连接端口,
}
}
}
主机物理网卡名更改
系统信息
发行版本7以上的规则不太一样。
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
Red Hat Enterprise Linux Server release 6.6 (Santiago)
查看当前网卡信息
ifconfig
子主题
修改70-persistent-net.rules文件
cd /etc/udev/rules.d
vi 70-persistent-net.rules
vi 70-persistent-net.rules
修改对应ATTR{address}物理地址的网卡名,NAME
子主题
修改网卡文件名
cd /etc/sysconfig/network-scripts
mv ifcfg-eth0 ifcfg-eth1
vi ifcfg-eth1
修改:
DEVICE=eth1
NAME=”System eth1”
mv ifcfg-eth0 ifcfg-eth1
vi ifcfg-eth1
修改:
DEVICE=eth1
NAME=”System eth1”
重启机器
shutdown -r now
ipvsadm工具安装
安装popt-static-1.13-7.el6.x86_64.rpm
rpm -ivh popt-static-1.13-7.el6.x86_64.rpm
安装ipvsadm
tar -zxvf ipvsadm-1.26.tar.gz
cd ipvsadm-1.26
make
make install
cd ipvsadm-1.26
make
make install
使用:
可以看到我们的虚拟地址和指向的真实地址
ipvsadm -L -n查看地址端口信息
子主题
安装问题
5.1. Nginx编译出错,PCRE问题
原因:
编译安装时,nginx自己要去编译pcre的源码
解决:
需要提供的是源码目录,而不是已经安装好的pcre目录
pcre下载地址:
子主题
5.2. Keepalived无法连接问题
1. iptables问题,ping不通VIP地址,
请检查iptables防火墙问题,如果没有开启防火墙,在启动时,可能会被加上了DROP的规则,导致VIP拒绝所有的访问。
现象:
子主题
解决:
[root@hzht113x ~]# iptables -nL --line-number
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9092
2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
3 DROP all -- 0.0.0.0/0 10.219.14.200
按行号删除:
iptables -D INPUT 3
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9092
2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
3 DROP all -- 0.0.0.0/0 10.219.14.200
按行号删除:
iptables -D INPUT 3
5.3. 缺少依赖包:
缺少依赖包:
其他
1.基本概念
1.1 基本特性
1.2 基本功能
1.3 相关功能
1.4 组织结构
1.4 .1 组织模型
1.4 .2 进程间通信
1.5 模块功能
1.5.1 核心模块
1.5.2 标准HTTP模块
1.5.3 可选HTTP模块
1.5.4 邮件服务模块
1.5.5 第三方模块
1.6 部署模式
1.6.1 yum部署
1.6.2 二进制部署
2.基本模型
2.1 Nginx与Apache
2.1.1 Apache
prefork模型
work模型
event模型
2.1.2 Nginx
高性能模型
2.2 系统I/O模型
2.2.1 异步/同步
2.2.2 阻塞/非阻塞
2.2.3 模型组合
2.3 网路I/O模型
2.3.1 同步阻塞IO(blocking IO)
2.3.2 同步非阻塞IO(nonblocking IO)
2.3.3 IO多路复用(IO multipexing)
2.3.4 信号驱动式IO(signal-driven IO)
2.3.5 异步非阻塞(asynchronous IO)
2.3.6 横向IO对比
2.3.7 常用模型
2.3.8 MMAP
3.主机配置
3.1 核心配置
3.1.1 全局配置
3.1.2 http配置
3.1.3 核心配置
站点模式
基于IP
基于端口
基于域名
站点功能(include)
别名(alias)
正则匹配(location)
精确匹配
区分大小
不区分大小
URI定向
文件名定向
优先级
生产案例
四层访问控制
账号认证
自定义错误提示
自定义访问日志
日志参数
日志目录
日志配置
日志模板
并发优化
日志切割
判断文件
超时时间设置
作为下载服务器
作为上传服务器
其他配置
3.2 高级配置
3.2.1 状态页面
3.2.2 三方模块
3.2.3 使用变量
3.2.4 日志目录
3.2.5 压缩功能
3.2.6 HTTP功能
3.2.7 图标显示
3.2.8 安全选项
版本隐藏
OpenSSL升级
3.3 Rewrite 重定向
3.3.1 模块语法
if指令
set指令
break指令
return指令
rewrite_log指令
3.3.2 指令案例
rewrite flag介绍
域名重定向
临时重定向
永久重定向
break与last
break案例
last案例
自动跳转HTTPS
判断文件
3.3.3 防盗链
web防盗链
防盗链
3.4 反向代理
3.4.1 HTTP反向代理
配置参数
单台服务
指定location
缓存服务
压力测试
缓存配置
文件校验
高级应用
配置参数
多台web
IP透传
动静分离
3.4.2 负载均衡(proxy)
配置参数
负载案例
redis
mysql
3.4.3 FsatCGI
配置指令
配置示例
Nginx&&php-fpm
同环境
异环境
tengine
配置文件
concat模块
DSO模块
3.4.4 健康检查(check)
3.5 参数优化
4.实际案例
4.1 LNMP-WordPress站点
4.2 集群测试
4.2.1 集群概念
集群介绍
集群优势
高性能(Performance)
价格有效性(Cost-effectiveness)
可伸缩性(Scalability)
高可用性(Availability)
透明性(Transparency)
可管理性(Manageability)
可编程性(Programmability)
集群分类
常见分类
负载均衡集群(Load Balancing Clusters,LBC或者LB)
高可用性集群(High-Availability Clusters,HAC)
高性能计算集群(High-Performance Clusters,HPC
网格计算(Grid Computing)
不同种类
负载均衡集群
高可用性集群
高性能计算集群
网格计算集群
软硬选型
硬件
F5、Netscaler、Radware、A10等,工作模式相当于Haproxy
缺点
成本高,不能二次开发
优点
性能强、更稳定
软件
Nginx、LVS、Haproxy、Keepalived、Heartbeat
缺点
需要强有力的运维以及开发
优点
可以进行二次开发,互联网行业更倾向于开源软件
选型
硬件
业务重要、技术薄弱、舍得开钱
银行、证券、金融、宝马、奔驰
银行、证券、金融、宝马、奔驰
软件
利润较低的中小型企业
混合
门户网站
淘宝、腾讯、新浪
淘宝、腾讯、新浪
集群选型
中小互联网企业
负载均衡
Nginx
配置简单、使用方便、安全稳定、社区活跃、市场主流
Haproxy
支持L4/L7,社区活跃较低
高可用
Keeplived
部署快速、配置简单、使用方便、安全稳定
Heartbeat
使用较为复杂,经验到位的工程师可以进行选型
大型互联网企业
负载均衡
应用服务器
前端
LVS+Keepalived 四层转发(主备或主主) 可拓展DNS或OSPF
后端
Nginx 或 Haproxy 七层转发(支持百台级别)
数据库/存储
LVS+Heartbeat
LVS支持TCP转发,DR模式高效,Heartbeat可以配合DRBD
可以进行VIP切换,可以支持块设备级别的数据同步,可以支持资源服务管理
LVS支持TCP转发,DR模式高效,Heartbeat可以配合DRBD
可以进行VIP切换,可以支持块设备级别的数据同步,可以支持资源服务管理
集群均衡
反向代理与负载均衡差异
负载均衡组件
并发调优参数
4.2.2 部署测试
集群规划
集群部署
集群调优
Nginx的常见问题
Nginx做高可用的集群解决方案?
如何下线Nginx上的服务?
Nginx如何动态的增加应用服务器的节点
Nginx服务器是如何知道客户端的地址的呢?
Nginx有哪几种负载均衡策略/算法?+1
Nginx如何实现负载均衡的呢?+1
软件系统体系结构
常见软件系统体系结构
B/S
C/S
Web资源
Web资源介绍
静态资源和动态资源区别
访问Web资源
Web服务器介绍
负载均衡
是什么?
负载均衡 建立在现有网络结构之上
它提供了一种廉价有效透明的方法
扩展网络设备和服务器的带宽
增加吞吐量
加强网络数据处理能力
提高网络的灵活性和可用性
负载平衡的类型
无负载平衡
没有负载平衡的简单Web应用程序环境可能如下所示
没有负载平衡的简单Web应用程序环境
在此示例中,用户直接连接到您的Web服务器,在yourdomain.com上,并且没有负载平衡。
如果您的单个Web服务器出现故障,用户将无法再访问您的Web服务器。
此外,如果许多用户试图同时访问您的服务器并且无法处理负载,他们可能会遇到缓慢的体验,或者可能根本无法连接。
四层负载均衡
四层负载均衡(目标地址和端口交换)
将网络流量负载平衡到多个服务器的最简单方法是使用第4层(传输层)负载平衡。
主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
以常见的TCP为例,
负载均衡设备在接收到第一个来自客户端的SYN 请求时,
即通过上述方式选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP),直接转发给该服务器。
TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。
在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改
实现四层负载均衡的软件有:
F5:硬件负载均衡器,功能很好,但是成本很高。
lvs:重量级的四层负载软件。
nginx:轻量级的四层负载软件,带缓存功能,正则表达式较灵活。
haproxy:模拟四层转发,较灵活。
lvs:重量级的四层负载软件。
nginx:轻量级的四层负载软件,带缓存功能,正则表达式较灵活。
haproxy:模拟四层转发,较灵活。
图解四层负载均衡
图解四层负载均衡
以这种方式进行负载均衡将根据IP范围和端口转发用户流量
4层负载平衡
(即,如果请求进入http://yourdomain.com/anything,则流量将转发到处理yourdomain.com的所有请求的后端。端口80)。
用户访问负载均衡器,负载均衡器将用户的请求转发给后端服务器的Web后端组。
无论选择哪个后端服务器,都将直接响应用户的请求。
通常,Web后端中的所有服务器应该提供相同的内容 - 否则用户可能会收到不一致的内容。
七层负载均衡
七层负载均衡(内容交换)
所谓七层负载均衡,也称为“内容交换”
主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
七层应用负载的好处
是使得整个网络更智能化。
例如访问一个网站的用户流量,可以通过七层的方式,
将对图片类的请求转发到特定的图片服务器并可以使用缓存技术;
将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。
实现七层负载均衡的软件
HAProxy:天生负载均衡技能,全面支持七层代理,会话保持,标记,路径转移;
Nginx:只在http协议和mail协议上功能比较好,性能与haproxy差不多;
Apache:功能较差
Mysql proxy:功能尚可。
Nginx:只在http协议和mail协议上功能比较好,性能与haproxy差不多;
Apache:功能较差
Mysql proxy:功能尚可。
图解七层负载均衡
图解七层负载均衡
7层负载平衡是更复杂的负载均衡网络流量的方法是使用第7层(应用层)负载均衡。
使用第7层允许负载均衡器,根据用户请求的内容,将请求转发到不同的后端服务器。
这种负载平衡模式,允许您在同一域和端口下,运行多个Web应用程序服务器。
示例中,如果用户请求yourdomain.com/blog,则会将其转发到博客后端,后端是一组运行博客应用程序的服务器。
其他请求被转发到web-backend,后端可能正在运行另一个应用程序。
负载均衡的作用
负载服务器对外提供公共的访问地址,将所有访问转发到一组服务器上。从而减轻服务器的压力和确保服务的稳定提供。
负载均衡算法/策略
轮循均衡(Round Robin)
每一次来自网络的请求轮流分配给内部中的服务器,从1至N然后重新开始。
此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
权重轮循均衡(Weighted Round Robin)
根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求。
例如:服务器A的权值被设计成1,B的权值是 3,C的权值是6,则服务器A、B、C将分别接受到10%、30%、60%的服务请求。
此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重。
负载均衡调度算法默认是 round robin,也就是轮询调度算法。
算法本身很简单,轮着一个一个来,非常简单高效公平的调度算法。
为什么轮询调度算法称为 Round Robin ?
round robin 来源于法语ruban rond(round ribbon),意思是环形丝带。
在17、18世纪时法国农民希望以请愿的方式抗议国王时,通常君主的反应是将请愿书中最前面的两至三人逮捕并处决,所以很自然地没有人希望自己的名字被列在前面。为了对付这种专制的报复,人们在请愿书底部把名字签成一个圈(如同一条环状的带子),这样就找不出带头大哥,于是只能对所有参与者进行同样的惩罚。
1731年,英国皇家海军最初使用了这个名词,以循环顺序签署请愿书,这样就没法找到带头大哥了。
非常贴切有木有,后端服务器轮着来处理请求,一个个都不要抢,都要出来接受处决。
随机均衡(Random)
把来自网络的请求随机分配给内部中的多个服务器。
权重随机均衡(Weighted Random)
此种均衡算法类似于权重轮循算法,不过在处理请求分担时是个随机选择的过程。
响应速度均衡(Response Time探测时间)
负载均衡设备对内部各服务器发出一个探测请求(例如Ping)
然后根据内部中各服务器对探测请求的最快响应时间,来决定哪一台服务器来响应客户端的服务请求。
优点;较好反映服务器当前运行状态
缺点:最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间,而不是客户端与服务器间的最快响应时间。
最少连接数均衡(Least Connection)
最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录,记录当前该服务器正在处理的连接数量
当有新的服务连接请求时,将把当前请求分配给连接数最少的服务器,使均衡更加符合实际情况,负载更加均衡。
此种均衡算法适合长时处理的请求服务,如FTP。
处理能力均衡(CPU、内存)
此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成)最轻的服务器,
由于考虑到了内部服务器的处理能力及当前网络运行状况,
所以此种均衡算法相对来说更加精确,尤其适合运用到第七层(应用层)负载均衡的情况下。
DNS响应均衡(Flash DNS)
在此均衡算法下,分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求,并在同一时间内把此域名解析成各自相对应服务器的IP地址并返回给客户端,则客户端将以最先收到的域名解析IP地址来继续请求服务,而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下,对本地负载均衡是没有意义的。
哈希算法
一致性哈希一致性Hash,相同参数的请求总是发到同一提供者。
当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
IP地址散列
(保证客户端服务器对应关系稳定)
通过管理发送方IP和目的地IP地址的散列,将来自同一发送方的分组(或发送至同一目的地的分组)统一转发到相同服务器的算法。
当客户端有一系列业务需要处理而必须和一个服务器反复通信时,
该算法能够以流(会话)为单位,保证来自相同客户端的通信能够一直在同一服务器中进行处理。
URL散列
通过管理客户端请求URL信息的散列,将发送至相同URL的请求转发至同一服务器的算法。
LVS
LVS原理
IPVS
LVS 的 IP 负载均衡技术是通过 IPVS 模块来实现的
IPVS是什么?
IPVS 是 LVS集群系统的核心软件,
主要作用
安装在 Director Server 上,同时在 Director Server上虚拟出一个IP 地址,用户必须通过这个虚拟的 IP 地址访问服务器。
这个虚拟 IP 一般称为 LVS 的VIP,即 Virtual IP
访问的请求首先经过 VIP 到达负载调度器,然后由负载调度器从Real Server 列表中选取一个服务节点响应用户的请求。
在用户的请求到达负载调度器后,调度器如何将请求发送到提供服务的 Real Server 节点,
而 Real Server节点如何返回数据给用户,是 IPVS 实现的重点技术。
ipvs
工作于内核空间,主要用于使用户定义的策略生效
ipvsadm
工作于用户空间,主要用于用户定义和管理集群服务的工具
图解LVS原理
图解LVS原理
ipvs工作于内核空间的INPUT链上,当收到用户请求某集群服务时,经过PREROUTING链,经检查本机路由表,送往INPUT链;
在进入netfilter的INPUT链时,ipvs强行将请求报文通过ipvsadm定义的集群服务策略的路径改为FORWORD链,将报文转发至后端真实提供服务的主机。
LVS NAT 模式
LVS NAT 模式
①.客户端将请求发往前端的负载均衡器,请求报文源地址是CIP(客户端IP),后面统称为CIP),目标地址为VIP(负载均衡器前端地址,后面统称为VIP)。
②.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
③.报文送到Real Server后,由于报文的目标地址是自己,所以会响应该请求,并将响应报文返还给LVS。
④.然后lvs将此报文的源地址修改为本机并发送给客户端。
注意:在NAT模式中,Real Server的网关必须指向LVS,否则报文无法送达客户端
②.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
③.报文送到Real Server后,由于报文的目标地址是自己,所以会响应该请求,并将响应报文返还给LVS。
④.然后lvs将此报文的源地址修改为本机并发送给客户端。
注意:在NAT模式中,Real Server的网关必须指向LVS,否则报文无法送达客户端
特点
1、NAT 技术将请求的报文和响应的报文都需要通过 LB 进行地址改写,因此网站访问量比较大的时候 LB 负载均衡调度器有比较大的瓶颈,一般要求最多之能 10-20 台节点
2、只需要在 LB 上配置一个公网 IP 地址就可以了。
3、每台内部的 realserver 服务器的网关地址必须是调度器 LB 的内网地址。
4、NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
2、只需要在 LB 上配置一个公网 IP 地址就可以了。
3、每台内部的 realserver 服务器的网关地址必须是调度器 LB 的内网地址。
4、NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
优点
集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址。
缺点
扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈,因为所有的请求包和应答包的流向都经过负载均衡器。
当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢!
LVS DR 模式(局域网改写mac地址)
LVS DR 模式(局域网改写mac地址)
①.客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP。
②.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址,目标MAC改为了RIP的MAC地址,并将此包发送给RS。
③.RS发现请求报文中的目的MAC是自己,就会将次报文接收下来,处理完请求报文后,将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意:需要设置lo接口的VIP不能响应本地网络内的arp请求。
②.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址,目标MAC改为了RIP的MAC地址,并将此包发送给RS。
③.RS发现请求报文中的目的MAC是自己,就会将次报文接收下来,处理完请求报文后,将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意:需要设置lo接口的VIP不能响应本地网络内的arp请求。
总结
1、通过在调度器 LB 上修改数据包的目的 MAC 地址实现转发。注意源地址仍然是 CIP,目的地址仍然是 VIP 地址。
2、请求的报文经过调度器,而 RS 响应处理后的报文无需经过调度器 LB,因此并发访问量大时使用效率很高(和 NAT 模式比)
3、因为 DR 模式是通过 MAC 地址改写机制实现转发,因此所有 RS 节点和调度器 LB 只能在一个局域网里面
4、RS 主机需要绑定 VIP 地址在 LO 接口(掩码32 位)上,并且需要配置 ARP 抑制。
5、RS 节点的默认网关不需要配置成 LB,而是直接配置为上级路由的网关,能让 RS 直接出网就可以。
6、由于 DR 模式的调度器仅做 MAC 地址的改写,所以调度器 LB 就不能改写目标端口,那么 RS 服务器就得使用和 VIP 相同的端口提供服务。
7、直接对外的业务比如WEB等,RS 的IP最好是使用公网IP。对外的服务,比如数据库等最好使用内网IP。
2、请求的报文经过调度器,而 RS 响应处理后的报文无需经过调度器 LB,因此并发访问量大时使用效率很高(和 NAT 模式比)
3、因为 DR 模式是通过 MAC 地址改写机制实现转发,因此所有 RS 节点和调度器 LB 只能在一个局域网里面
4、RS 主机需要绑定 VIP 地址在 LO 接口(掩码32 位)上,并且需要配置 ARP 抑制。
5、RS 节点的默认网关不需要配置成 LB,而是直接配置为上级路由的网关,能让 RS 直接出网就可以。
6、由于 DR 模式的调度器仅做 MAC 地址的改写,所以调度器 LB 就不能改写目标端口,那么 RS 服务器就得使用和 VIP 相同的端口提供服务。
7、直接对外的业务比如WEB等,RS 的IP最好是使用公网IP。对外的服务,比如数据库等最好使用内网IP。
优点
和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。
DR模式的效率很高,但是配置稍微复杂一点,因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000W PV或者并发请求1万一下都可以考虑用haproxy/nginx。
DR模式的效率很高,但是配置稍微复杂一点,因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000W PV或者并发请求1万一下都可以考虑用haproxy/nginx。
缺点
所有 RS 节点和调度器 LB 只能在一个局域网里面
LVS TUN 模式(IP封装、跨网段)
LVS TUN 模式(IP封装、跨网段)
①.客户端将请求发往前端的负载均衡器,请求报文源地址是CIP,目标地址为VIP。
②.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP,目标地址改为RIP,并将此包发送给RS。
③.RS收到请求报文后,会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP,所以会处理次请求报文,并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意:需要设置lo接口的VIP不能在共网上出现。
②.负载均衡器收到报文后,发现请求的是在规则里面存在的地址,那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP,目标地址改为RIP,并将此包发送给RS。
③.RS收到请求报文后,会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP,所以会处理次请求报文,并将响应报文通过lo接口送给eth0网卡直接发送给客户端。
注意:需要设置lo接口的VIP不能在共网上出现。
总结:
1.TUNNEL 模式必须在所有的 realserver 机器上面绑定 VIP 的 IP 地址
2.TUNNEL 模式的 vip ------>realserver 的包通信通过 TUNNEL 模式,不管是内网和外网都能通信,所以不需要 lvs vip 跟 realserver 在同一个网段内。
3.TUNNEL 模式 realserver 会把 packet 直接发给 client 不会给 lvs 了
4.TUNNEL 模式走的隧道模式,所以运维起来比较难,所以一般不用。
2.TUNNEL 模式的 vip ------>realserver 的包通信通过 TUNNEL 模式,不管是内网和外网都能通信,所以不需要 lvs vip 跟 realserver 在同一个网段内。
3.TUNNEL 模式 realserver 会把 packet 直接发给 client 不会给 lvs 了
4.TUNNEL 模式走的隧道模式,所以运维起来比较难,所以一般不用。
优点
负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点:
隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。
LVS FULLNAT模式
无论是 DR 还是 NAT 模式,不可避免的都有一个问题:LVS 和 RS 必须在同一个 VLAN 下,否则 LVS 无法作为 RS 的网关。这引发的两个问题是:
1、同一个 VLAN 的限制导致运维不方便,跨 VLAN 的 RS 无法接入。
2、LVS 的水平扩展受到制约。当 RS 水平扩容时,总有一天其上的单点 LVS 会成为瓶颈。
Full-NAT 由此而生,解决的是 LVS 和 RS 跨 VLAN 的问题,而跨 VLAN 问题解决后,LVS 和 RS 不再存在 VLAN 上的从属关系,可以做到多个 LVS 对应多个 RS,解决水平扩容的问题。
Full-NAT 相比 NAT 的主要改进是,在 SNAT/DNAT 的基础上,加上另一种转换,转换过程如下:
1、同一个 VLAN 的限制导致运维不方便,跨 VLAN 的 RS 无法接入。
2、LVS 的水平扩展受到制约。当 RS 水平扩容时,总有一天其上的单点 LVS 会成为瓶颈。
Full-NAT 由此而生,解决的是 LVS 和 RS 跨 VLAN 的问题,而跨 VLAN 问题解决后,LVS 和 RS 不再存在 VLAN 上的从属关系,可以做到多个 LVS 对应多个 RS,解决水平扩容的问题。
Full-NAT 相比 NAT 的主要改进是,在 SNAT/DNAT 的基础上,加上另一种转换,转换过程如下:
子主题
1. 在包从 LVS 转到 RS 的过程中,源地址从客户端 IP 被替换成了 LVS 的内网 IP。内网 IP 之间可以通过多个交换机跨 VLAN 通信。目标地址从VIP修改为RS IP.
2. 当 RS 处理完接受到的包,处理完成后返回时,将目标地址修改为LVS ip,原地址修改为RS IP,最终将这个包返回给 LVS 的内网 IP,这一步也不受限于 VLAN。
3. LVS 收到包后,在 NAT 模式修改源地址的基础上,再把 RS 发来的包中的目标地址从 LVS 内网 IP 改为客户端的 IP,并将原地址修改为VIP。
Full-NAT 主要的思想是把网关和其下机器的通信,改为了普通的网络通信,从而解决了跨 VLAN 的问题。采用这种方式,LVS 和 RS 的部署在 VLAN 上将不再有任何限制,大大提高了运维部署的便利性。
2. 当 RS 处理完接受到的包,处理完成后返回时,将目标地址修改为LVS ip,原地址修改为RS IP,最终将这个包返回给 LVS 的内网 IP,这一步也不受限于 VLAN。
3. LVS 收到包后,在 NAT 模式修改源地址的基础上,再把 RS 发来的包中的目标地址从 LVS 内网 IP 改为客户端的 IP,并将原地址修改为VIP。
Full-NAT 主要的思想是把网关和其下机器的通信,改为了普通的网络通信,从而解决了跨 VLAN 的问题。采用这种方式,LVS 和 RS 的部署在 VLAN 上将不再有任何限制,大大提高了运维部署的便利性。
总结
1. FULL NAT 模式不需要 LBIP 和 realserver ip 在同一个网段;
2. full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10%
2. full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10%
OpenAPI网关
OpenAPI 是什么?
Open API 即开放 API,也称开放平台。
Open API 即开放 API,也称开放平台。
所谓的开放 API(OpenAPI)是服务型网站常见的一种应用,网站的服务商将自己的网站服务封装成一系列
API(Application Programming Interface,应用编程接口)开放出去,供第三方开发者使用,这种行为就叫做开放网站的 API,所开放的 API 就被称作 OpenAPI(开放 API )。
API(Application Programming Interface,应用编程接口)开放出去,供第三方开发者使用,这种行为就叫做开放网站的 API,所开放的 API 就被称作 OpenAPI(开放 API )。
OpenAPI现状及解决
现状
传统第三方接入
项目访问路径完全暴露给第三方
无法对接入请求做到统一权限把控
无法对多协议请求做到统一分发(异构)
需重复考虑系统流控,如流量分流
无法对接入请求做到统一权限把控
无法对多协议请求做到统一分发(异构)
需重复考虑系统流控,如流量分流
解决
Open-api接入
让后端系统服务专注于业务的处理,提高开发效率,降低开发成本
实现请求的标准化接入,隐藏项目真实访问路径
实现接口统一权限把控
实现对多协议请求进行统一分发处理
认证授权,安全管控的服务功能前置,提高服务质量
实现请求的标准化接入,隐藏项目真实访问路径
实现接口统一权限把控
实现对多协议请求进行统一分发处理
认证授权,安全管控的服务功能前置,提高服务质量
OpenAPI整体组成
统一入口
统一从Open-api网关接入
四项应用配置
应用服务配置
应用服务是指不同的业务接口,如获取订单列表接口、支付接口、智能场景设置接口等。
通过配置应用服务的所属服务中心、服务方法、协议等实现对不同业务请求的具体分发。
服务中心配置
服务中心是指不同的第三方平台,如CMS、Lion、DEQMock平台。
通过配置服务中心的具体实现类全限定类名或者远程地址,实现对不同服务中心的业务请求分发。
应用接口配置
应用接口是指对商户进行平台接口访问权限的配置。
可通过设置接口的调用次数上限、调用次数统计周期、调用次数超限处理策略对商户访问接口进行严格的权限把控。
应用信息配置
应用信息是指赋予商户对网关平台的访问权限,实现对商户访问平台接口的权限把控。
商户可通过向平台申请的应用信息接入网关平台。
一个服务支撑中心
认证中心
五大流程管控职责链
01 流程处理前置
检查传入Context对象中的参数,如是否为空;
检查应用ID appId是否合法;
检查加解密密钥appKey是否合法;
检查服务编码是否合法。
检查应用ID appId是否合法;
检查加解密密钥appKey是否合法;
检查服务编码是否合法。
02 访问控制
记录应用ID appId的调用次数;
记录服务编码processCode的调用次数;
根据服务编码检查调用次数是否超过设置的调用次数上限。超过调用次数上限后,根据设置的处理方式选择预警还是拒绝调用者访问接口;
03 黑白名单
检查调用服务的调用者IP及端口号是否处在白名单中。如果不处在白名单中,记录接入的appId的调用次数信息。
04 路由分发
根据服务编码找到对应的服务处理类,并将请求分发到对应的服务中心的具体接口。
05 流程处理后置
处理请求第三方平台接口的返回数据,根据服务编码配置决定是否需要对返回数据进行解密处理等。
一个可视化平台
Open-api系统管理平台
六个维度的数据统计与分析
应用统计
黑名单统计
应用调用排行
服务统计
远程服务统计
服务调用排行
黑名单统计
应用调用排行
服务统计
远程服务统计
服务调用排行
黑名单统计
用于统计当前接入Open-api网关平台黑名单数量
应用统计
用于统计当前接入Open-api网关平台商户应用数量
应用调用排行
用于统计当前接入Open-api网关平台应用调用次数Top5的商户应用信息
服务调用排行
用于统计当前接入Open-api网关平台服务调用次数Top5的服务信息
服务统计
用于统计当前Open-api网关平台接入服务数量
远程服务统计
用于统计当前Open-api网关平台接入服务中心数量
在线文档
版本项目划分
可同时接入多项目,并具体划分文档版本号
接口详细信息介绍
提供接口请求参数、响应参数、接口地址、具体请求及响应示例等接口详细信息介绍
接口类型组别划分
对接口进行类型组别划分,支持自定义组别设置
接口变更热发布
支持接口变更热发布,摒除传统文档手动更新的烦恼
OpenResty
OpenResty 使用介绍
锤子科技在 T2 发布会上将门票收入捐赠给了 OpenResty 开源项目,今天我们就来为大家介绍下 OpenResty 是个什么鬼?
OpenResty 使用介绍
OpenResty(又称:ngx_openresty) 是一个基于 NGINX 的可伸缩的 Web 平台,由中国人章亦春发起,提供了很多高质量的第三方模块。
OpenResty 是一个强大的 Web 应用服务器,Web 开发人员可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块,更主要的是在性能方面,OpenResty可以 快速构造出足以胜任 10K 以上并发连接响应的超高性能 Web 应用系统。
360,UPYUN,阿里云,新浪,腾讯网,去哪儿网,酷狗音乐等都是 OpenResty 的深度用户。
OpenResty 安装
菜鸟教程是基于 ubuntu14.04 安装 OpenResty。
OpenResty 依赖库有: perl 5.6.1+, libreadline, libpcre, libssl。
所以我们需要先安装好这些依赖库,也非常简单:
apt-get install libreadline-dev libpcre3-dev libssl-dev perl
如果你的系统是 Centos 或 RedHat 可以使用以下命令:
yum install readline-devel pcre-devel openssl-devel
接下我们可以在官方(https://openresty.org/cn/)下载最新的 OpenResty 源码包并解压编译安装:
wget https://openresty.org/download/ngx_openresty-1.9.7.1.tar.gz # 下载
tar xzvf ngx_openresty-1.9.7.1.tar.gz # 解压
cd ngx_openresty-1.9.7.1/
./configure
make
make install
默认情况下程序会被安装到 /usr/local/openresty 目录,你可以使用 ./configure --help 查看更多的配置选项。
Hello World 实例
安装成功后,我们就可以使用 openresty 直接输出 html 页面。
首先我们可以创建一个工作目录:
mkdir /home/www
cd /home/www/
mkdir logs/ conf/
其中 logs 目录用于存放日志,conf 用于存放配置文件。
接着,我们在 conf 目录下创建一个 nginx.conf 文件 代码如下:
worker_processes 1;
error_log logs/error.log;
events {
worker_connections 1024;
}
http {
server {
listen 9000;
location / {
default_type text/html;
content_by_lua '
ngx.say("<p>Hello, World!</p>")
';
}
}
}
如果你熟悉 nginx 的配置,应该对以上代码就很熟悉。这里我们将 html 代码直接写在了配置文件中。
启动 openresty
默认情况下 openresty 安装在 /usr/local/openresty 目录中,启动命令为:
cd /home/www
/usr/local/openresty/nginx/sbin/nginx -p `pwd`/ -c conf/nginx.conf
如果没有任何输出,说明启动成功,-p 指定我们的项目目录,-c 指定配置文件。
接下来我们可以使用 curl 来测试是否能够正常范围:
curl http://localhost:9000/
输出结果为:
<p>Hello, World!</p>
或者通过浏览器访问 http://localhost:9000/:
看到了吧,我们在配置文件写的 html 已正常输出。
OpenResty 的目标是让你的 Web 服务直接跑在 Nginx 服务内部,充分利用 Nginx 的非阻塞 I/O 模型,不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如 MySQL,PostgreSQL,~Memcaches 以及 ~Redis 等都进行一致的高性能响应。
所以对于一些高性能的服务来说,可以直接使用 OpenResty 访问 Mysql或Redis等,而不需要通过第三方语言(PHP、Python、Ruby)等来访问数据库再返回,这大大提高了应用的性能。
相关站点
OpenResty 英文官网:http://openresty.org/
OpenResty 中文官网:http://openresty.org/cn/
Nginx 维基官网:http://wiki.nginx.org/
Lua 入门教程:https://www.runoob.com/lua/lua-tutorial.html
OpenResty 中文官网:http://openresty.org/cn/
Nginx 维基官网:http://wiki.nginx.org/
Lua 入门教程:https://www.runoob.com/lua/lua-tutorial.html
A10
A10的原理是什么?
A10有什么功能?
HAProxy
是什么?
一个使用C语言编写的自由及开放源代码软件
其提供高可用性、负载均衡,以及基于TCP和HTTP的应用程序代理
HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。
并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。
使用场景
特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理
HAProxy的事件驱动模型
HAProxy实现了一种事件驱动, 单一进程模型
此模型支持非常大的并发连接数
多进程或多线程模型的问题
受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。
事件驱动模型的缺点
在多核系统上,这些程序通常扩展性较差。
这就是为什么他们必须进行优化,以使每个CPU时间片(Cycle)做更多的工作。
事件驱动模型的优点
事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务,所以没有这些问题。
HAProxy基础配置文件详解
haproxy 配置中分成五部分内容,分别如下:
global: 设置全局配置参数,属于进程的配置,通常是和操作系统相关。
defaults:配置默认参数,这些参数可以被用到frontend,backend,Listen组件;
frontend:接收请求的前端虚拟节点,Frontend可以更加规则直接指定具体使用后端的backend;
backend:后端服务集群的配置,是真实服务器,一个Backend对应一个或者多个实体服务器;
Listen :frontend和backend的组合体。
global: 设置全局配置参数,属于进程的配置,通常是和操作系统相关。
defaults:配置默认参数,这些参数可以被用到frontend,backend,Listen组件;
frontend:接收请求的前端虚拟节点,Frontend可以更加规则直接指定具体使用后端的backend;
backend:后端服务集群的配置,是真实服务器,一个Backend对应一个或者多个实体服务器;
Listen :frontend和backend的组合体。
HAProxy优点
1、HAProxy是支持虚拟主机的,可以工作在4、7层(支持多网段)
2、HAProxy的优点能够补充Nginx的一些缺点,比如支持Session的保持,Cookie的引导;同时支持通过获取指定的url来检测后端服务器的状态。
3、HAProxy跟LVS类似,本身就只是一款负载均衡软件;单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的。
4、HAProxy支持TCP协议的负载均衡转发,可以对MySQL读进行负载均衡,对后端的MySQL节点进行检测和负载均衡,大家可以用LVS+Keepalived对MySQL主从做负载均衡。
HAPorxy缺点
1. 不支持POP/SMTP协议
2. 不支持SPDY协议
3. 不支持HTTP cache功能。现在不少开源的lb项目,都或多或少具备HTTP cache功能。
4. 重载配置的功能需要重启进程,虽然也是soft restart,但没有Nginx的reaload更为平滑和友好。
5. 多进程模式支持不够好
2. 不支持SPDY协议
3. 不支持HTTP cache功能。现在不少开源的lb项目,都或多或少具备HTTP cache功能。
4. 重载配置的功能需要重启进程,虽然也是soft restart,但没有Nginx的reaload更为平滑和友好。
5. 多进程模式支持不够好
8种HAProxy的负载均衡算法、策略
① roundrobin
表示简单的轮询,每个服务器根据权重轮流使用,在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。最大支持4095个后端主机;
② leastconn
连接数最少的服务器优先接收连接。leastconn建议用于长会话服务,例如LDAP、SQL、TSE等,而不适合短会话协议。如HTTP.该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。
③ static-rr
每个服务器根据权重轮流使用,类似roundrobin,但它是静态的,意味着运行时修改权限是无效的。另外,它对服务器的数量没有限制。该算法一般不用;
④ source
对请求源IP地址进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。只要服务器正常,同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化,那么客户端会定向到不同的服务器;该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑤ uri
表示根据请求的URI左端(问号之前)进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。只要服务器正常,同一个URI地址总是访问同一个服务器。一般用于代理缓存和反病毒代理,以最大限度的提高缓存的命中率。该算法只能用于HTTP后端;该算法一般用于后端是缓存服务器;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑥ url_param
在HTTP GET请求的查询串中查找<param>中指定的URL参数,基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求;该算法一般用于将同一个用户的信息发送到同一个后端服务器;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑦ hdr(name)
在每个HTTP请求中查找HTTP头<name>,HTTP头<name>将被看作在每个HTTP请求,并针对特定的节点;如果缺少头或者头没有任何值,则用roundrobin代替;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑧ rdp-cookie(name)
为每个进来的TCP请求查询并哈希RDP cookie<name>;该机制用于退化的持久模式,可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie,则使用roundrobin算法代替;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
表示简单的轮询,每个服务器根据权重轮流使用,在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。最大支持4095个后端主机;
② leastconn
连接数最少的服务器优先接收连接。leastconn建议用于长会话服务,例如LDAP、SQL、TSE等,而不适合短会话协议。如HTTP.该算法是动态的,对于实例启动慢的服务器权重会在运行中调整。
③ static-rr
每个服务器根据权重轮流使用,类似roundrobin,但它是静态的,意味着运行时修改权限是无效的。另外,它对服务器的数量没有限制。该算法一般不用;
④ source
对请求源IP地址进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。只要服务器正常,同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化,那么客户端会定向到不同的服务器;该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑤ uri
表示根据请求的URI左端(问号之前)进行哈希,用可用服务器的权重总数除以哈希值,根据结果进行分配。只要服务器正常,同一个URI地址总是访问同一个服务器。一般用于代理缓存和反病毒代理,以最大限度的提高缓存的命中率。该算法只能用于HTTP后端;该算法一般用于后端是缓存服务器;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑥ url_param
在HTTP GET请求的查询串中查找<param>中指定的URL参数,基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求;该算法一般用于将同一个用户的信息发送到同一个后端服务器;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑦ hdr(name)
在每个HTTP请求中查找HTTP头<name>,HTTP头<name>将被看作在每个HTTP请求,并针对特定的节点;如果缺少头或者头没有任何值,则用roundrobin代替;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
⑧ rdp-cookie(name)
为每个进来的TCP请求查询并哈希RDP cookie<name>;该机制用于退化的持久模式,可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie,则使用roundrobin算法代替;该算法默认是静态的,所以运行时修改服务器的权重是无效的,但是算法会根据“hash-type”的变化做调整。
0 条评论
下一页