cookiesession
多台主机
进程空间为每个用户单独的数据记录位置记录用户访问信息会话
只要用户带ｃｏｏｋｉｅ就可以识别用户神父
１.用户绑定
来自同一个用户请求始终绑定到一台服务器
（１）ｉｐ地址识别用户
（２）cookie
会话黏性实现一个主机绑定在一台主机
万一服务器挂了
２.ｓｅｓｓｉｏｎ集群
服务器构建成会话集群
但是每个服务器保存全部的会话巨大的消耗
３.共享内存
但是万一共享存储挂了
容易出现单点故障（冗余）
并且前台需要一个负载均衡器接受请求负责均衡请求
Linux Cluster：Cluster：计算机集合，为解决某个特定问题组合起来形成的单个系统；Linux Cluster类型：LB：Load Balancing，负载均衡；HA：High Availiablity，高可用；A=MTBF/（MTBF+MTTR）平均无故障时间＋平均修复时间(0,1)：90%, 95%, 99%, 99.5%, 99.9%, 99.99%, 99.999%, 99.9999%五个９一年３－５分钟不在线HP：High Performance，高性能；分布式系统：分布式存储分布式计算系统扩展方式：Scale UP：向上扩展Scale Out：向外扩展Cluster
分布式存储
LBCluster：LB Cluster的实现：硬件：F5 Big-IPCitrix NetscalerA10 A10软件：lvs：Linux Virtual Server附着在ｎｅｔｆｉｌｔｅｒ，内核级别的负载均衡器不受套接字文件数量限制不反代直接修改报文的方式nginx模拟工作在四层接受用户请求自己监听套接字作为客户端套接字封装报文然后将报文发送给服务端（后端真实服务器）的套接字。但是套接字最多只有６５０００＋实际只有２００００＋总共的并发能力也不超过６５５３５个受限于工作模型ｈａｐｒｏｘｙ同理haproxy模拟工作在四层ats：apache traffic server perlbalpound基于工作的协议层次划分：传输层（通用）：（DPORT）lvs：nginx：（stream）haproxy：（mode tcp）应用层（专用）：（自定义的请求模型分类）proxy server：http：nginx(http), httpd, haproxy(mode http), ...fastcgi：nginx, httpd, ...mysql：ProxySQL, ...站点指标：PV：Page View页面浏览量，很多个ｉｐ一个用户会打开多个页面UV：Unique Vistor可独立表示一个用户，打开两个浏览器访问一个站点被表示为两个UVIP：同一个IP假如并发每秒２０００００个请求每个页面１００个资源只有１秒２００００是访问页面１天／３１６亿／３＝５亿PV量一天服务站点一般没这么高美团并发平均值在十几万所以ｌｖｓ小规模站点没必要浪费是负载均衡的基础１.工作内核，没有很好的应用层工具２.基于ｃｏｏｋｉｅ，基于ｕｒｌ调度，动静分离都不可以所以很少使用ｌｖｓ美团一般使用BigIP硬件设备ｌｖｓ需要二次开发才很好的使用并发量只要超过套接字的就使用ｌｖｓ并发超过２０００００ｌｖｓ一级调度然后给ｎｇｉｎｘ或者ｈａｐｒｏｘｙ二级调度构建高并发站点不会所有业务都在一个站点需要切割不同站点不同的系统比如财经切分为多个小集群２００００个并发五六千万的ｐｖ也还不错ｎｇｉｎｘ受套接字限制但是一般也足以...会话保持：(1) session stickySource IPCookie(2) session replication; session cluster(3) session server
l4：四层路由器，四层交换机；VS：根据请求报文的目标IP和目标协议及端口将其调度转发至某RealServer，根据调度算法来挑选RS；iptables/netfilter：iptables：用户空间的管理工具；netfilter：内核空间上的框架；流入：PREROUTING --> INPUT 流出：OUTPUT --> POSTROUTING转发：PREROUTING --> FORWARD --> POSTROUTINGDNAT：目标地址转换； PREROUTING；SNAT：源地址转换；POSTROUTING；
ｌｖｓ工作在Input上
功能是基于规则写的
ｉｐｖｓ发现是集群服务强行放到ｐｏｓｔｒｏｕｔｉｎｇ
lvs: ipvsadm/ipvsipvsadm：用户空间的命令行工具，规则管理器，用于管理集群服务及相关的RealServer；ipvs：工作于内核空间的netfilter的INPUT钩子之上的框架；lvs集群类型中的术语：vs：Virtual Server, Director, Dispatcher, Balancerrs：Real Server, upstream server, backend serverCIP：Client IP, VIP: Virtual serve IP, RIP: Real server IP, DIP: Director IPCIP <--> VIP == DIP <--> RIP lvs集群的类型：lvs-nat：修改请求报文的目标IP；多目标IP的DNAT；lvs-dr：操纵封装新的MAC地址；lvs-tun：在原请求IP报文之外新加一个IP首部；lvs-fullnat：修改请求报文的源和目标IP；
LVS原理详解（3种工作模式）
1.集群
什么是集群
计算机集群简称集群是一种计算机系统，它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多。
集群就是一组独立的计算机，通过网络连接组合成一个组合来共同完一个任务
集群的特点
1）高性能performance 2）性价比 3）可伸缩性 4）高可用性
常用集群软硬件
常用开源集群软件有：lvs，keepalived，haproxy，nginx，apache，heartbeat常用商业集群硬件有：F5,Netscaler，Radware，A10等
2. LVS简介
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。 目前LVS已经被集成到Linux内核模块中
LVS采用IP负载均衡技术和基于内容请求分发技术.调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性
可以访问 /article/a/-09-22/1581
观看 吴佳明(普空)：LVS在大规模网络环境中的应用 的视频
工作流程：
lvs本身叫linux虚拟服务器是因为它不提供任何服务，而是将服务传发给后端真正服务器。 叫做director.根据用户请求的IP和端口，可解析三层四层请求，能识别用户IP地址和端口号。比如只有访问172.16.100.1:80才会转发给后端web服务器。如果22端口就是访问的是调度器本身。LVS本身也是工作在LINUX内核的TCP/IP协议栈上。本身工作在input链上。如果用户请求的ip和端口确实都是访问Lvs,那么就转发到input链上，LVS设置规则，一旦发现用户请求的是集群服务，比如刚才的172.16.100.1:80。它会强行修改数据报文的形成。本来过了input之后应该直接到LVS内部去了，到本机用户空间去了，但是强行把报文送到farword链，并通过forword—>post routing转发至其他主机。终端互联网用户从外部访问公司的外部负载均衡服务器，把终端用户的Web请求会发送给LVS调度器
调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器
比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器
但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器
得到的服务内容都是一样的，整个集群对用户而言都是透明的
最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户
反常于iptables机制,所以lvs和iptables不能同时使用。。
iptables两段式的：iptables写规则的，netfilter才是真正实现规则的。
两段式：必须是集群服务
1.ipvsadm：在用户空间定义集群服务的。管理集群服务的命令行工具。
2.ipvs:工作在内核上，并且监控在input链上的框架
首先在用户空间用ipvsadm写一堆规则，写好之后直接送给ipvs,ipvs结合input链发挥功能。工作函数钩子，请求到input链上，lvs来检查。发现用户请求是集群服务就转发指forwoed最后向外发送。
向外提供服务的Ip就是----vip.就是客户请求调度器上的Ip。 客户端ip — CIP 调度器和内网通信的IP ----- DIP Director ip 真正后端服务器---- real server RIP
后来的内核直接内置了lvs的ipvs代码，内核中内核的仅仅是ipvs代码。因为只有ipvs在内核里面，所以只要内核编译的时候已经支持了ipvs的功能，而且在用户空间又安装了ipvsadm,那么它就能够实现负载均衡调度器。
DNAT如何实现将用户请求转发后端的？？请求通过pre routing链，只有符合了才路由转换发送到farword链上去。
pre routing–input链–forward—output–post routing
负载均衡设备：
1.Hardware:
F5,BIG IP
Critrix,Netscaler
A10
2.Software:
四层（网络层）LVS 四层路由/交换机设备
七层（应用层）：（反向代理）
nginx,主要对http,smtp,pop3,imap服务
haproxy，主要是http。tcp基于四层的做负载均衡，比如（mysql,smtp）
四层，七层主要区别：
四层对应用层内容不做任何处理，只解析四层协议，由于不解析更高层协议，所有工作性能更好，但是支持的高级特性没有，比如根据用户所请求的真正的资源来做负载均衡，以web服务器为例，根据用户请求的Url,或uri来做负载均衡，LVS不具备这种能力。
七层 为某项特定服务 操作能力强
而工作在七层的反向代理服务设备，为某些特定协议提供的。因此能精确解码解剖对应的协议，而且能在协议的基础上做一定的修改之后向后做负载均衡，所以在前端它就可以实现一定的处理，因此操纵能力更强，但是一定程度上性能略逊于四层设备。七层有时候更符合生产环境的。根据项目需要选择。
调度一定要根据调度算法：
注意：一个调度器其实可以调度多个集群，比如定义俩个集群使用一个调度器，用户请求80时候有一组真实服务器提供服务，，如果是另外的服务，向另外集群服务。。
通常只为一个服务提供集群功能。
互联网用户访问web资源的时候先去访问lvs负载均衡调度器，再由lvs将用户的请求转给web服务器。
这样做的好处是可以均衡后端服务器的压力，防止同一时间某台后端web服务器的访问量过大，导致服务器瘫痪
既有利于公司服务的稳定运行，也有利于客户的使用
3.lvs的特点（优点和缺点）？
LVS的优点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会受到大流量的影响。5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。
LVS的缺点是：
1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了
4. LVS 的四种工作模式原理简介及优缺点
（1）NAT模式（转换一个ip地址，效率低）
（2）TUN模式（ip隧道）
（3）DR模式(调度器跟真正的服务器在同一网段，强行修改mac地址，并不改变ip地址)
1、NAT模式
原理
这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时（请求的目的IP为VIP），根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址（RIP）,这样真实服务器（RS）就能够接收到客户的请求数据包了。真实服务器响应完请求后，查看默认路由（NAT模式下我们需要把RS的默认路由设置为LB服务器。）把响应后的数据包发送给LB,LB再接收到响应包后，把包的源地址改成虚拟地址（VIP）然后发送回给客户端。
原理图简述：
1)客户端请求数据，目标IP为VIP
2)请求数据到达LB服务器，LB根据调度算法将目的地址修改为RIP地址及对应端口（此RIP地址是根据调度算法得出的。）并在连接HASH表中记录下这个连接。
3)数据包从LB服务器到达RS服务器webserver，然后webserver进行响应。Webserver的网关必须是LB，然后将数据返回给LB服务器。
4)收到RS的返回后的数据，根据连接HASH表修改源地址VIP&目标地址CIP，及对应端口80.然后数据就从LB出发到达客户端。
5)客户端收到的就只能看到VIP\DIP信息。
NAT模式优缺点：
1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈，一般要求最多之能10-20台节点
2、只需要在LB上配置一个公网IP地址就可以了。
3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。
ok:简化版图
个人总结：
NAT模式 地址转换（转换一个ip地址，效率低）LVS俩个网卡就是将用户请求转发至后台真正服务器用户请求CIP 目标地址VIP 发现是集群服务 挑选一个后端服务器 向后转发RIPx（x指后端服务器编号）写lvs规则 客户<---CIP+VIP-->负载均衡器<----cip+rs2---->真正的服务器理想最多只能负载10个 因为请求和相应都要经过负载均衡器 用户请求80服务，但是后端工作在8080上，也可以，后端服务器使用不同端口进行响应。端口映射。只要写一个规则：工作在NAT模式下，就可以了。1.集群节点和负载均衡一定要在同一个IP网络中。2.RIP通常是私有地址，仅用于各集群节点之间的通信。ＤＮＡＴ3.director位于client和real server之间，并负责处理进出的所有通信，所以压力很大。（面试）4.real sevrer必须将网关指向DIP5.director支持端口映射。6.real server可以使用任意OS，只要director是linux.7.较大规模应用场景中，director易成为系统瓶颈。
2、TUN模式（隧道模式）
原理
virtual server via ip tunneling模式:采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用VS/TUN模式后，集群系统的最大吞吐量可以提高10倍。
VS/TUN的工作流程图如下所示，它和NAT模式不同的是，它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面，然后发送给RS节点服务器，节点服务器接收到之后解开IP tunnel后，进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。
Tunnel原理流程图:
原理图过程简述：
1）客户请求数据包，目标地址VIP发送到LB上。
2）LB接收到客户请求包，进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。
3）RS节点服务器根据IP Tunnel包头信息（此时就有一种逻辑上的隐形隧道，只有LB和RS之间懂）收到请求包，然后解开IP Tunnel包头信息，得到客户的请求包并进行响应处理。
4）响应处理完毕之后，RS服务器使用自己的出公网的线路，将这个响应数据包发送给客户端。源IP地址还是VIP地址。
NAT模式优缺点：
优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。
个人总结：
IP隧道（IP
tunning）是一种数据包封装技术，它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器的VIP地址的数据包封装，通过隧道转发给后端的真实服务器（Real
Server），通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应口），LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。
TUN模式（ip隧道）：
所以LVS（TUN）的思路就是将请求与响应数据分离让调度器仅处理数据请求，而让真实服务器响应数据包直接返回给客户端，不再由调度器往返资源实现将一个目标为调度器的VIP地址的数据包封装，通过隧道转发给后端的真实服务器情况：三台real server在不同的城市根DR模型一样。不过转发的时候重新封装IP包。每一个real server即有RIP，VIP，其中RIP必须是公网IP。请求到director,选择一个real server.但是director和rs不在同一网络。怎么转发？？rs直接响应给客户端，所以以VIP为源地址。还要确保用户请求VIP是到director上，所以rs的VIP隐藏。。隧道模式：1.各集群节点可以跨越互联网2.real server的RIP必须是公网地址。3.director仅仅处理入栈请求，4.响应报文一定不能通过director,只有支持隧道功能的OS才能用于real server不支持端口映射。realserver的RIP和director的DIP不用处于同一物理网络中，且RIP必须可以和公网通信。也就是说集群节点可以跨互联网实现
3、DR模式（直接路由模式）
原理
DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。
DR模式是互联网使用比较多的一种模式。
DR模式将报文直接路由给目标真实服务器。在DR模式中，调度器根据各个真实服务器的负载情况，连接数多少等，动态地选择一台服务器，不修改目标IP地址和目标端口，也不封装IP报文，而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址，并且又在同一个局域网。那么根据局域网的通讯原理，真实复位是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候，解开IP包头查看到的目标IP是VIP。（此时只有自己的IP符合目标IP才会接收进来，所以我们需要在本地的回环借口上面配置VIP。
另：由于网络接口都会进行ARP广播响应，但集群的其他机器都有这个VIP的lo接口，都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。）然后真实服务器做成请求响应，之后根据自己的路由信息将这个响应数据包发送回给客户，并且源IP地址还是VIP。
DR模式小结：
1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。
2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比）
3、因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面
4、RS主机需要绑定VIP地址在LO接口上，并且需要配置ARP抑制。
5、RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。
6、由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。
个人总结：
与隧道模式不同的是，直接路由模式（DR模式）要求调度器与后端服务器必须在同一个局域网内 VIP地址需要在调度器与后端所有的服务器间共享，因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地目标IP为客户端IP，这样客户端访问的是调度器的VIP地址，回应的源地址也依然是该VIP地址（真实服务器上的VIP）
客户端是感觉不到后端服务器存在的 由于多台计算机都设置了同样一个VIP地址，所以在直接路由模式中要求调度器的VIP地址是对外可见的
客户端需要将请求数据包发送到调度器主机，而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上， 也就是该网络设备并不会向外广播自己的MAC及对应的IP地址，真实服务器的VIP对外界是不可见的
但真实服务器却可以接受目标地址VIP的网络请求，并在回应数据包时将源地址设置为该VIP地址， 调度器根据算法在选出真实服务器后，在不修改数据报文的情况下，将数据帧的MAC地址修改为选出的真实服务器的MAC地址
通过交换机将该数据帧发给真实服务器，整个过程中，真实服务器的VIP不需要对外界可见
需要路由限制一下
很显然RS给客户端发报文经过物理网卡也就是RIP
把VIP配置再lo别名上
DR给添加了源MAC和目的MAC后 通过更改内核参数 强制它先进入lo接口 然后在经过内核核心转发经过物理网卡RIP 发送出去
首先发给lo别名也就是VIP 然后再从RIP真实的物理网卡发送出去
这样子源IP就是VIP 需要路由限制一下
工作流程：
用于请求来时，通过交换机到director,注意三个real server和director都连接在交换机上。director知道自己有三个real server,根据挑选标准，挑选一台将请求发送至real server,real server直接响应给客户端。故director只负责转发+调度请求。
问题：
CIP没有请求RIP，因此如果用RIP响应，client不接受。故图中第三步的源地址必须是VIP，因此给它们4各都配VIP。问题又来了，存在地址冲突阿。director俩IP，一个VIP，一个DIP，一个配置在网卡上，一个配置在网卡别名上。一个主机有多个地址，但是real server的VIP都是一样的，但是RIP不同，VIP配置在网卡别名上并且是隐藏的。不跟任何人响应，只是响应客户端，请求时把VIP作为源地址使用，真正通信的还是RIP的网络设备。。。
本地路由器如何通过网卡把请求发给director VIP所在网卡呢？
其实真实通信的是靠MAC地址，发往VIP时必须封住成帧，源MAC（路由器MAC）-------->通过ARP解析知道director VIP的MAC（ARP是广播的，real server不响应，因此一定不能用VIP通信）只能director的VIP响应（通过MAC）
Director转发到各real server不改变报文的目标IP（VIP）地址，而是仅仅修改MAC地址实现，可以通过ARP解析得到各自的MAC地址，当这样用户请求到director,director发现请求是集群服务，把MAV首部拆了重新封装— 源MAC：MAC 目的MAC：RMAC
根据RMAC，real server接收到报文，拆开之后发现目标IP是VIP，是自己主机的VIP，故到自己本机用VIP响应 源VIP 目的CIP ，因此也不用把网关指向director,只负责处理请求。
DR模式 直接路由(调度器跟真正的服务器在同一网段，强行修改mac地址，并不改变ip地址)FullNAT(访问来源ip跟访问目的ip，效率低，麻烦，要编辑内核的，)以及EnhanceNAT（阿里巴巴，还不成熟）增强natDR：带动百十台，性能超强。。用LVS用DR模式遵循法则：1.各集群节点必须和director必须在同一物理网络中（没其他设备，只有交换机就可以连接起来的）同一机房2.RIP地址可以不用是私有地址。直接ssh连接管理。实现毕节的远程管理和监控。3.director只负责处理访问请求，响应报文直接有real server发往客户端。4.集群节点一定不能使用director当作默认网关。5.director无法实现端口映射。客户请求80，director是8080提供服务，转发到real server，80没提供服务不会响应。源地址源端口，目标地址目标端口都不变。只负责拆换MAC。NAT是因为director可以实现端口来回转换。6.大多数OS都可以用在real server 上因为real server必须要求可以隐藏VIP。7.director能处理比NAT多得多的服务器。
官方三种负载均衡技术比较总结表：
fullnat
lvs-fullnat： 非标准类型通过同时修改请求报文的源IP地址和目标IP地址进行转发；CIP <--> DIP VIP <--> RIP (1) VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络（在同一网络就是用nat模式了）；因此，RIP的网关一般不会指向DIP；(2) RS收到的请求报文源地址是DIP，因此，只能响应给DIP；但Director还要将其发往Client；(3) 请求和响应报文都经由Director；(4) 支持端口映射；注意：此类型默认不支持；`
所以可以跨网络了
可以隐藏内网主机 又可以让后端主机跨网络的目的
总结：lvs-nat, lvs-fullnat：请求和响应报文都经由Director；lvs-nat：RIP的网关要指向DIP；lvs-fullnat：RIP和DIP未必在同一IP网络，但要能通信；lvs-dr, lvs-tun：请求报文要经由Director，但响应报文由RS直接发往Client；lvs-dr：通过封装新的MAC首部实现，通过MAC网络转发；得在同一IP网络lvs-tun：通过在原IP报文之外封装新的IP首部实现转发，支持远距离通信；受限于mtu
4.LVS负载均衡的10种调度算法
根据其调度时是否考虑各RS当前的负载状态，可分为静态方法和动态方法两种：静态方法：仅根据算法本身进行调度；RR：roundrobin，轮询；WRR：Weighted RR，加权轮询；a主机权重为2，则第一台a服务器虚拟为两台虚拟主机。SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定；但是很多用户使用公网地址访问 导致可能多个用户都是访问一个RS 并且如果RS宕机了 该用户之前的会话也都没有了 所以应该基于七层的cookie进行此方法更好 lvs不支持DH：Destination Hashing；目标地址哈希，将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡；web 3000个请求 1000个活动链接 2000个处于非活动链接 就是连接还在 但是服务器没有请求任何资源 即空闲连接 对资源的依赖少得多 非活动连接 正常的叫做活动连接 所需要的资源量是非活动链接的256倍 预估数据 nginx维持100 0000个非活动连接只需要几兆内存 重量值很小很小所以计算负载值overhead动态方法：主要根据每RS当前的负载状态及调度算法进行调度；只有后端负载都一样才会考虑调度算法Overhead=LC：least connectionsOverhead=activeconns*256+inactiveconnsWLC：Weighted LCOverhead=(activeconns*256+inactiveconns)/weight lvs的默认算法 overhead一样的话该道理是顺寻轮询 但是应该让权重大的先执行 因为它更强SED：Shortest Expection DelayOverhead=(activeconns+1)*256/weight 解决了上个方法的问题 如果overhead计算出来一样 假设都是0 好计算 第一台权重为1 所以(0+1)/1=1 第二台权重为2 那么(0+1)/3=1/3 所以选择第二台服务器新的问题 假设权重比值很大 1：10 导致一直给第二台服务器NQ：Never Queue从不排队 按权重先排队 第一个先给权重大的 第二个给权重小的 第3456等都给权大的 至少让权重小的先负载一个增加算法复杂度 增加调度器负载 所以WLC较好LBLC：Locality-Based LC，动态的DH算法；基于ip 假设第一台代理服务器很多很多 第二个代理服务器没几个 所以考虑负载 当第一次访问Ip 新请求 不是轮询 首先去找负载小的LBLCR：LBLC with Replication，带复制功能的LBLC；很长时间 客户固定 80%都给了第一台 活跃连接占90%第二台闲死 假设缓存共享 第一台把一类请求先发给第二台服务器
只有通过调度算法才可以实现后端服务器之间真正意义上的均衡，缓解企业服务器的压力，提高用户的访问效率
DH：
LBLCR：两个基于缓存项共享
查看内核是否支持ipvs功能
ipvs：
~]# grep -i -C 10 "ipvs" /boot/config-VERSION-RELEASE.x86_64
可以看到ipvs功能编译了 而且编译为模块了
支持的协议
支持的调度算法
不需要监听任何服务
知道要执行的集群服务即可
ipvsadm书写规则
（1）轮询调度算法
轮询调度（Round Robin 简称’RR’）算法就是按依次循环的方式将请求调度到不同的服务器上
该算法最大的特点就是实现简单
轮询算法假设所有的服务器处理请求的能力都一样的，调度器会将所有的请求平均分配给每个真实服务器
俗话说：你一个，我一个（web1接收一个访问，web2接收一个访问，这样轮询）
（2）加权轮询调度算法
加权轮询（Weight Round Robin 简称’WRR’）算法主要是对轮询算法的一种优化与补充，LVS会考虑每台服务器的性能
并给每台服务器添加一个权值，如果服务器A的权值为1，服务器B的权值为2
则调度器调度到服务器B的请求会是服务器A的两倍，权值越高的服务器，处理的请求越多
俗话说：拿钱多的干的活就多（哪个服务器性能好哪个服务器就多接受客户的请求）
（3）.最小连接调度
最小连接调度（Least Connections 简称’LC’）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态的调度算法，它通过服务器当前活跃的连接数来估计服务器的情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中断或者超时，其连接数减1。
（集群系统的真实服务器具有相近的系统性能，采用最小连接调度算法可以比较好地均衡负载。)
（4）.加权最小连接调度
加权最少连接（Weight Least Connections 简称’WLC’）算法是最小连接调度的超集，各个服务器相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
（5.）基于局部的最少连接
基于局部的最少连接调度（Locality-Based Least Connections 简称’LBLC’）算法是针对请求报文的目标IP地址的 负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和Cache命中率，从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则使用’最少连接’的原则选出一个可用的服务器，将请求发送到服务器。
（6）.带复制的基于局部性的最少连接
带复制的基于局部性的最少连接（Locality-Based Least Connections with Replication 简称’LBLCR’）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统，它与LBLC算法不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。按’最小连接’原则从该服务器组中选出一一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按’最小连接’原则从整个集群中选出一台服务器，将该服务器加入到这个服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
（7）.目标地址散列调度
目标地址散列调度（Destination Hashing 简称’DH’）算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。
（8）.源地址散列调度U
源地址散列调度（Source Hashing 简称’SH’）算法先根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同，它的算法流程与目标地址散列调度算法的基本相似。
（9）.最短的期望的延迟
最短的期望的延迟调度（Shortest Expected Delay 简称’SED’）算法基于WLC算法。举个例子吧，ABC三台服务器的权重分别为1、2、3 。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用SED算法后会进行一个运算
A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把请求交给得出运算结果最小的服务器。
（10).最少队列调度
最少队列调度（Never Queue 简称’NQ’）算法，无需队列。如果有realserver的连接数等于0就直接分配过去，不需要在进行SED运算。
