nginx lvs

nginx内核参数优化

内核参数的优化，主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化，常见的优化参数值如下。

下面给出一个优化实例以供参考:

net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_syncookies = 1

net.core.somaxconn = 262144

net.core.netdev_max_backlog = 262144

net.ipv4.tcp_max_orphans = 262144

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 30

将上面的内核参数值加入/etc/sysctl.conf文件中，然后执行如下命令使之生效:
[root@ localhost home]#/sbin/sysctl -p
下面是对实例中选项的含义进行介绍：
net.ipv4.tcp_max_tw_buckets参数用来设定timewait的数量，默认是180000，这里设为6000。 太大会阻塞,处理不过来
net.ipv4.ip_local_port_range选项用来设定允许系统打开的端口范围。
net.ipv4.tcp_tw_recycle选项用于设置启用timewait快速回收。腾出资源处理更多请求
net.ipv4.tcp_tw_reuse选项用于设置开启重用，允许将TIME-WAIT sockets重新用于新的TCP连接。
net.ipv4.tcp_syncookies选项用于设置开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies进行处理。
net.core.somaxconn选项默认值是128， 这个参数用于调节系统同时发起的tcp连接数，在高并发的请求中，默认的值可能会导致链接超时或者重传，因此，需要结合并发请求数来调节此值。
net.core.netdev_max_backlog选项表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许发送到队列的数据包的最大数目。队列中存更多的请求
net.ipv4.tcp_max_orphans选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤立连接将立即被复位并打印出警告信息。这个限制只是为了防止简单的DoS攻击。不能过分依靠这个限制甚至人为减小这个值，更多的情况是增加这个值。
net.ipv4.tcp_max_syn_backlog选项用于记录那些尚未收到客户端确认信息的连接请求的最大值。对于有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。
net.ipv4.tcp_synack_retries参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。
net.ipv4.tcp_syn_retries选项表示在内核放弃建立连接之前发送SYN包的数量。
net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。正确设置这个值非常重要，有时候即使一个负载很小的Web服务器，也会出现因为大量的死套接字而产生内存溢出的风险。
net.ipv4.tcp_keepalive_time选项表示当keepalive启用的时候，TCP发送keepalive消息的频度。默认值是2（单位是小时）。

crontab 编辑定时任务

nginx的缓存设置  提高网站性能

在location或if段里,来写.

格式  expires 30s;

      expires 30m;

      expires 2h;

      expires 30d;

缓存成功的不会发请求

(注意:服务器的日期要准确,如果服务器的日期落后于实际日期,可能导致缓存失效)

另: 304 也是一种很好的缓存手段,但设置缓存比304更优

原理是: 服务器响应文件内容时,同时响应etag标签(内容的签名,内容一变,他也变), 和 last_modified_since 2个标签值

nginx负载均衡

但proxy_pass如何指向多台服务器?

把多台服务器用 upstream指定绑定在一起并起个组名,

然后proxy_pass指向该组

常用负载均衡

HTTP 重定向

对于HTTP 重定向，你一定不陌生，它可以将 HTTP 请求进行转移，在 Web 开发中我们经常会用它来完成自动跳转，比如用户登录成功后跳转到相应的管理页面。 这种重定向完全由HTTP 定义，并且由HTTP 代理和Web 服务器共同实现。很简单，当HTTP 代理（比如浏览器）向Web服务器请求某个URL后，Web 服务器可以通过HTTP 响应头信息中的Location 标记来返回一个新的URL，这意味着HTTP代理需要继续请求这个新的URL ，这便完成了自动跳转。当然，如果你自己写了一个 HTTP 代理，也可以不支持重定向，也就是对于Web 服务器返回的Location 标记视而不见，虽然这可能不符合HTTP标准，但这完全取决于你的应用需要。 也正是因为HTTP 重定向具备了请求转移和自动跳转的本领，所以除了满足应用程序需要的各种自动跳转之外，它还可以用于实现负载均衡，以达到Web 扩展的目的。

 

DNS 负载均衡

我们知道，DNS负责提供域名解析服务，当我们访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP 地址，在这一过程中，DNS服务器完成了域名到IP 地址的映射，同样，这种映射也可以是一对多的，这时候，DNS 服务器便充当了负载均衡调度器（也称均衡器），它就像前面提到的重定向转移策略一样，将用户的请求分散到多台服务器上，但是它的实现机制完全不同。

 

反向代理负载均衡

反向代理服务器的核心工作便是转发 HTTP 请求，因此它工作在 HTTP 层面，也就是 TCP 七层结构中的应用层（第七层），所以基于反向代理的负载均衡也称为七层负载均衡，实现它并不困难，目前几乎所有主流的 Web 服务器都热衷于支持基于反向代理的负载均衡，随后我们将进行Nginx反向代理负载均衡的实验

IP 负载均衡

事实上，在数据链路层（第二层）、网络层（第三层）以及传输层（四层）都可以实现不同机制的负载均衡，但有所不同的是，这些负载均衡调度器的工作必须由Linux 内核来完成，因为我们希望网络数据包在从内核缓冲区进入进程用户地址空间之前，尽早地被转发到其他实际服务器上，没错，Linux 内核当然可以办得到，位于内核的Netfilter和IPVS可以解决问题，而用户空间的应用程序对此却束手无策。 另一方面，也正是因为可以将调度器工作在应用层以下，这些负载均衡系统可以支持更多的网络服务协议，比如FTP 、SMTP 、DNS ，以及流媒体和Vo I P 等应用。

【1.2】LVS历史概述

Linux Virtual Server项目的目标：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。在某种程度上是对市场上商业化硬件集群解决方案的开源替代方案。

LVS项目创始人章文嵩，1973年生人，国防科技大学博士。曾与LIDS项目创始人谢华刚联合创建中国集群技术有限公司。2009年9月加盟淘宝网，为淘宝资深总监、研究员、淘宝技术委员会主席，主要负责淘宝网基础核心软件研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本淘宝电子商务基础设施。

在1998年5月，章文嵩先生成立了Linux Virtual Server的自由软件项目，进行Linux服务器集群的开发工作。同时，Linux Virtual Server项目是国内最早出现的自由软件项目之一。LVS第一个版本只花了两个星期的时间便把开源软件代码完成了，然后放到网上。因为是开源的，到网站上下载的人很多。LVS项目于1998年5月在网站上发布IPVS第一个版本源程序以来，一直得到了来自 Internet 的用户和开发者的鼓励和支持。

2004年12月24日，ipvs-1.2.1作为Netfilter的模块正式入驻linux官方内核2.6.10，得到更广泛地传播和应用。

官方网站：http://www.linuxvirtualserver.org/

基于LVS的负载均衡集群

三种网络/工作模式：NAT、DR、TUN

十个调度算法： rr、wrr、lc、wlc、lblc、lblcr、dh、sh、sed、 nq

1.轮叫调度（Round Robin）(简称rr)

调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

2.加权轮叫（Weighted Round Robin）（简称wrr)

调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

3.最少链接（Least Connections）(LC)

调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。

4.加权最少链接（Weighted Least Connections）(WLC)

在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

5.基于局部性的最少链接（Locality-BasedLeast Connections）(LBLC)

“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。

6.带复制的基于局部性最少链接（Locality-BasedLeast Connections with Replication）(LBLCR)

“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

7.目标地址散列（DestinationHashing）(DH)

“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

8.源地址散列（Source Hashing）(SH)

“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

9. 最短的期望的延迟（ShortestExpected Delay Scheduling SED）(SED)

基于wlc算法。这个必须举例来说了

ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算

A(1+1)/1

B(1+2)/2

C(1+3)/3

根据运算结果，把连接交给C 。

10.最少队列调度（Never QueueScheduling NQ）(NQ)

无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算