wordpress添加中文语言网站建设优化汕头

wordpress添加中文语言,网站建设优化汕头,域名注册信息,银川网站建设redu情景导入当电商平台大促时#xff0c;几十万用户同时涌入抢单#xff0c;有的服务器忙到崩溃、有的却闲着没事#xff0c;用户要么页面卡半天刷不出来#xff0c;要么付完款订单却没生成#xff0c;甚至某台服务器突然宕机导致一批用户直接无法操作#xff0c;怎么才能让…情景导入当电商平台大促时几十万用户同时涌入抢单有的服务器忙到崩溃、有的却闲着没事用户要么页面卡半天刷不出来要么付完款订单却没生成甚至某台服务器突然宕机导致一批用户直接无法操作怎么才能让所有请求被合理分配、服务器不偏科过载LB集群Load Balance ClusterLB负载均衡集群用来将用户请求通过调度器使用调度策略负载均衡算法调度到不同的节点上让整个集群内机器的性能处于一个相对平衡的状态虚拟服务器LVSLinux Virtual Sever可作为LB集群的典型代表。虚拟服务器LVS虚拟服务器LVS作为 Linux 内核级的四层传输层负载均衡解决方案使用的是netfilter框架。LVS通过IP_VS内核模块直接干预数据包转发流程通过修改数据包的关键网络字段IP、MAC、端口或隧道头实现将客户端请求分发到后端真实服务器RS。LVS全程不涉及应用层数据解析仅依赖 TCP/IP 协议栈的传输层及以下信息IP 地址、端口号因此性能极高。LVS数据包修改逻辑与工作模式深度绑定核心原理可结合三种经典模式NAT、DR、TUN的数据包流转过程详解。LVS在企业IT架构中的位置如图下所示:LVS 集群组成前端负载均衡层由一台或多台负载调度器构成中间服务器群组层由一组实际运行应用服务的服务器组成底端数据共享存储层提供共享存储空间的存储区域LVS术语VIP 浮动IP —— 业务IP(提供给用户访问的IP地址)DIPLVS上访问真实服务器的接口IPRIP业务服务器真实服务器的IP地址CIP 客户端IP地址RS 真实服务器DS LVS的负载调度器LVS的架构用户态管理程序ipvsadm————用来管理lvs集群工具内核态数据包模块IP_VS————通过netfiler的网络子系统来修改数据包达到数据转发的目的LVS的安装yum install ipvsadm -yLVS的管理方式ipvsadm的工具来进行管理唯一的集群配置文件在/etc/sysconfig/ipvsadm中保存如果启动ipvsadm的服务将会自动加载该配置文件ipvsadm --help 查询选项LVS的工作模式和调度算法一共有四种工作模式十二种调度算法LVS 的三种工作模式LVS/NATLVS/DRLVS/TUNLVS 的十二种调度算法RR、WRR、SH、DH、LC、WLC、SED、NQ、LBLC、LBLCR、FD、OVFLVS的调度算法的分类静态算法 就是根据规则进行调度根据算法本身进行调度动态算法 就是根据业务的承载进行调度静态算法分类RR轮询算法调度器将收到的请求按顺序轮流分配到集群中的RS。均匀地分配请求不考虑服务器连接数和负载情况WRR加权轮询算法根据RS的处理能力给予不同的权重为性能好的服务器分配更多的请求性能一般的分配较少的请求SH源地址哈希算法根据请求的源IP地址作为哈希键从静态分配的哈希表中找出对应的服务器。同一个IP地址的请求始终发往第一次调度的RS可实现会话绑定DH目的地址哈希算法根据请求的目标IP地址作为哈希键从静态分配的哈希表中找出对应的服务器。发往同一个目标地址的请求始终转发到第一次调度的RS可用于实现正向代理缓存场景中的负载均衡八种 动态算法LC最少连接算法动态地将网络请求调度到连接数最少的RS上。当集群中的服务器性能相近时这种算法可以进行较好的均衡负载。适用于长链接应用。其负载计算公式为overhead 活动连接数*256非活动连接数WLC加权最少连接算法相对于LC当集群中服务器性能有差异时建议使用本算法可以使性能较好的服务器承接较大比例的活动连接。此算法是LVS的默认调度算法负载公式为overhead 活动连接数*256非活动连接数/权重值SED最短期望延迟算法当使用WLC时如果RS的连接数和权重比例正好一样时下个请求将可能分配给任意一个RS而不是性能最好的RSSED可避免这种情况保证了高权重优先NQ最少队列算法使用该算法时第一轮请求会均匀的分配给所有RS后续再使用SED算法这样可以避免某些服务器可能用于得不到处理请求的机会LBLC基于局部的最少连接算法根据请求的目标IP找出该目标IP最近使用的服务器若该服务器可用且没超载就将请求发给它若服务器不存在或者超载且有服务器处于一半的工作负载则用最少连接原则将请求发给一个可用服务器。是针对目标IP地址的负载均衡算法可以看作动态的DH算法。可根据负载情况实现正向代理、web缓存等LBLCR加权最少连接算法该算法维护从一个目标IP地址到一组服务器的映射(lblc维护的是一个目标IP地址到一台服务器的映射)。根据请求的目标IP找出该目标IP对应的服务器组按最少连接原则从组内选出一台没有超载的服务器将请求发给它若该服务器超载则最少连接原则从该集群中选出一台服务器加入到服务器组中将请求发给该服务器。如果服务器组在一段时间没有修改将最忙的服务器从组内剔除以降低复制程度。这个算法也是针对目标IP地址的负载均衡算法解决lblc负载不均衡的问题从负载重的RS复制到负载轻的RS。可根据负载情况实现正向代理、web缓存等FOWeighted Fail Over算法该算法会遍历lvs关联的RS链表找到未过载(未设置IP_VS_DEST_F_OVERLOAD标识)且权重最高的RS进行调度OVFOverflow-connection基于RS的活动连接数和权重值来实现。它会将新连接调度到权重值最高的RS直到其活动连接数超过它的权重值之后调度到下一个权重值最高的RS。该算法会遍历lvs关联的RS链表找到权重值最高的可用RS。可用RS需要满足以下条件LBLCR加权最少连接算法未过载(未设置IP_VS_DEST_F_OVERLOAD标识)RS当前活动连接数小于其权重值权重值不为0mh 动态调度算法LVS/NAT模式LVS/NAT模式的特点:1. 集群和LVS的节点要在同一个网络之中并且LVS的DIP要充当RS的网关地址2.LVS要在客户端和真实服务器端进行数据转发也就是DS的服务器需要支持ip转发3.RS的服务器可以是任意的操作系统就是单纯的业务节点无需做任何集群相关的配置4. LVS 支持端口映射给后端服务器5.因为所有的流量都需要通过LVS进行转发,就会导致LVS成为 集群瓶颈在NAT模式下单台一般承载10 -15 台真实服务器原因是大量用户请求的数据包很小但多台服务器返回的资源很大而导致LVS有巨大压力LVS/NAT 模式的完整请求—响应流程:请求发起阶段客户端通过自身 IPCIP向 LVS 集群对外暴露的虚拟服务 IPVIP发起业务请求此时数据包的源地址为 CIP、目的地址为 VIP。LVS 调度与地址转换请求到达 LVS 调度器后内核的ip_vs模块会依据预设的调度算法如轮询、加权轮询从后端真实服务器池Real Server中选定一台目标服务器对应 RIP随后 LVS 会对数据包执行目的地址转换DNAT保持源地址CIP不变将目的地址从 VIP 修改为选中的 RIP再将数据包转发至该 RIP 服务器。后端服务器处理请求RIP 服务器接收到数据包后识别到目的地址是自身 IP便正常处理业务请求如提供 Web 服务、执行接口逻辑。响应回传阶段RIP 处理完请求后生成的响应数据包源地址为自身 RIP、目的地址为客户端 CIP但由于 RIP 通常处于内网网段与 LVS 的内网 IPDIP同属私有网络无法直接与公网的 CIP 通信网络不可达因此 RIP 会将响应包发送至自身配置的网关 —— 而该网关正是 LVS 的 DIP。LVS 二次地址转换与回包LVS 收到 RIP 的响应包后会执行源地址转换SNAT将数据包的源地址从 RIP 修改为 LVS 的 VIP目的地址保持 CIP 不变此时 LVS 需开启内核的IP_forwardIP 转发功能相当于一台具备 NAT 能力的路由器最终将修改后的响应包转发至公网送达客户端。LVS/NAT实验架构:实验需求:client访问http://192.168.31.99依次调度到192.168.1.12和192.168.1.13上基础环境准备:在两台作为RS的主机上安装并配置Nginx用于测试配置RS的IP地址和网关配置RS的网关一定要指向DIP在LVS上配置IP地址修改内核参数开启内核转发功能配置LVS负载均衡集群yum安装LVS在LVS上添加虚拟服务器和真实服务器ipvsadm -A -t 192.168.31.99:80 -s rr 创建集群服务并指定调度算法为rr,默认是wlc加权轮询ipvsadm -a -t 192.168.31.99:80 -r 192. 168.1.12 -m 向集群内添加真实服务器并指定工作模式为natipvsadm -a -t 192.168.31.99:80 -r 192. 168.1.13 -m进行访问测试可以看到调度成功补充:NAT模式下利用LVS实现端口映射LVS/NAT 的端口映射是靠内核ip_vs模块的 “双向地址 端口转换”“连接跟踪表” 实现的客户端请求CIP:CPort→VIP:VPort到 LVS 后ip_vs选后端 RIP把 “目的 IP: 端口” 改成 “RIP:RPort”DNAT同时记录 “CIP:CPort↔VIP:VPort↔RIP:RPort” 的对应关系后端响应RIP:RPort→CIP:CPort到 LVS 后ip_vs查连接表把 “源 IP: 端口” 改回 “VIP:VPort”SNAT再发给客户端。这里用实验进行验证将DS192.168.31.99的8888端口映射至RS192.168.1.13的22端口通过ssh访问进行测试ssh连接192.168.31.99:8888登录至192.168.1.13端口映射成功LVS/DR模式LVS/DR模式的特点1. DIP与RIP之间必须在同一个局域网络中2. 每一台RS节点都必须有自己真实的网关且网关不能指向DIP3.RIP可以不是私网地址可以真正的访问网络4. DR模式下无法实现端口映射5.RS节点所在的操作系统必须支持屏蔽ARP通常是LINUX通过Linux的内核参数来屏蔽ARP6.负载的能力更强DR模式下LVS只有下行流量上行流量由真实的服务器直接回应客户端因此业务的承载量通常是nat的数十倍这是 LVS/DR 模式的请求—响应流程1.ARP 屏蔽与 VIP 独占准备LVS 调度器DS提前通过 ARP 协议获取集群内所有后端真实服务器RS的 RIP 与 MAC 地址同时在 RS 上配置 ARP 屏蔽规则如禁用 VIP 的 ARP 广播、限制 ARP 响应避免集群内多台设备LVSRS同时响应 VIP 的 ARP 请求 —— 确保仅 LVS 的 VIP 对外响应 ARP使客户端请求的数据包能准确发往 LVS。2.请求转发阶段客户端向 VIP 发起请求数据包的目的 MAC 为 LVS 的 MAC由 ARP 响应确定请求到达 LVS 后LVS 不修改数据包的 IP源为 CIP、目的为 VIP仅修改二层 MAC 地址将数据包的源 MAC 改为自身 MAC目的 MAC 改为选定 RS 的 MAC随后通过二层网络直接转发给该 RS因 LVS 与 RS 处于同一物理网段无需路由。3.响应回包阶段RS 收到数据包后因自身 lo 接口已绑定 VIP仅用于接收目的 IP 为 VIP 的包不对外广播可正常处理请求处理完成后RS 生成响应包源 IP 为 VIP、源 MAC 为自身 MAC目的 IP 为 CIP、目的 MAC 为客户端的 MACRS 通过 ARP 获取直接将响应包发往客户端 —— 无需经过 LVS大幅减轻了 LVS 的回包负载压力。Nginx 这类 7 层负载均衡属于 “代理模式”所有请求与响应都需经过 Nginx 转发无法实现 “回包绕开调度器”因此 LVS/DR 的负载压力远低于前者。LINUX系统模拟路由器的配置1. 给路由器增加两张网卡 分别使用net8和net12. 在路由器上开启ip_forward转发内核参数3. 在路由器的防火墙上开启地址伪装NATLVS集群的配置在eth0上添加IP地址作为VIP也可以和真实服务器一样添加在环回接口上修改内核参数开启IP转发配置LVS集群RS的配置将VIP地址配置在dummy类型的换回口上(由于添加的是相同的IP地址所以不能直接添加在物理网卡上否则会引起IP地址冲突。 因此只能配置在由系统模拟出来的lo网卡dummy 接口是 Linux 系统为弥补 loopback 接口数量)限制而推出的模拟环回类接口)nmcli connection add type dummy ifname dummy1 con-name dummy1 ipv4.method manual ipv4.addresses 192.168.31.100/32 autoconnect yes配置RS(Nginx1、Nginx2)禁止响应ARPnet.ipv4.conf.dummy2.arp_ignore1net.ipv4.conf.all.arp_ignore1默认值00 表示任意的接口收到ARP就会响应1 仅目标IP在本机上才响应ARPLVS DR 模式的关键是所有真实服务器和调度器共享同一个 VIP但只有调度器能对外响应 VIP 的 ARP 请求告诉网络 “VIP 的 MAC 地址是我”。如果真实服务器也响应 ARP 请求会导致网络中多个设备声称自己拥有 VIP 的 MAC 地址引发 ARP 冲突、请求分发混乱最终负载均衡失效。两段配置为什么要一起配置?1. 只配置 net.ipv4.conf.all.arp_ignore1仅全局规则表面效果看似可行因为all是 Linux 内核中对所有网络接口的 “全局兜底规则”理论上会覆盖 dummy2、物理网卡如 eth0、lo 等所有接口的arp_ignore值让所有接口都遵循 “仅目标 IP 在接收接口上才响应 ARP” 的规则。潜在致命风险Linux 的接口参数优先级是 “局部接口配置 all 全局配置”。如果后续有人误操作比如为 dummy2、eth0 单独配置arp_ignore0或者系统升级 / 其他脚本修改了某接口的局部参数全局的all.arp_ignore1会被覆盖导致真实服务器重新响应 VIP 的 ARP 请求引发 MAC 地址冲突LVS DR 负载均衡直接失效。2. 只配置 net.ipv4.conf.dummy2.arp_ignore1仅 VIP 所在接口直接失效这是完全错误的配置方式。ARP 请求是发送到真实服务器的物理网卡如 eth0的而非 dummy2 接口而你仅配置了 dummy2 接口的arp_ignore1物理网卡的arp_ignore仍为默认值 0。此时物理网卡收到针对 VIP 的 ARP 请求时会因为 “本机 dummy2 接口配置了 VIP”默认值 0 的逻辑而响应 ARP直接导致网络中多个设备LVS 调度器 真实服务器同时响应 VIP 的 MAC 查询引发 ARP 冲突LVS DR 模式彻底无法工作。3. 两段配置同时配置的效果net.ipv4.conf.all.arp_ignore1全局规则确保所有接口物理网卡、dummy2、lo 等默认遵循 “不响应非本接口 IP 的 ARP 请求”从根本上杜绝物理网卡响应 VIP 的 ARP 请求net.ipv4.conf.dummy2.arp_ignore1局部精准规则针对 VIP 所在的 dummy2 接口锁定规则防止后续局部配置覆盖全局规则。配置RS(Nginx1、Nginx2) ARP的通告级别net.ipv4.conf.all.arp_announce2net.ipv4.conf.dummy2.arp_announce2默认值 00 表示向每个接口通告ARP2 表示避免向非本网络进行通告这样配置是为了使RS在回包时VIP所在接口不进行ARP通告,只让RIP进行通告防止引发ARP冲突测试结果查看调度的数据包保存配置方式(将配置到处至指定的文件后,启动ipvsadm服务时可读配置)LVS/TUN模式—解决DIP和RIP不在同一个局域网内的问题隧道模式:就是在原有的IP报文基础上封装一层IP报文LVS的隧道模式实现方式在DR模式的基础上封装一层IP报文该IP报文源IP是LVS的DIP目的IP是LVS根据负载均衡的调度算法选择出来的RIP当请求达到RIP以后此时RS根据IP隧道解封装然后由RS直接处理客户端的响应特点1. DIP和RIP不再需要在同一个局域网内但是DIP和RIP以及VIP都要是公网地址2. RS的真实服务器必须要支持IP隧道协议ipip隧道、gre隧道、gue隧道默认使用的是IPIP协议一般的LINUX都可以支持3. ip隧道模式也不支持端口映射4. 支持RS的数量非常多但是需要更多的公网IP地址补充FULL-NAT: 全NAT模式同时修改请求的源IP和目的IP进行地址转发因此可以在多个vlan之间进行NAT转发1. VIP必须是公网地址RIP和DIP都只能私网地址并且RIP和DIP通常不应该在一个局域网内且有多个vlan的环境所以RIP的网关也不会指向DIP2. RS收到请求的源地址是来自DIP因此RIP虽然不指向DIP但是必须将数据包发给DIP也就是要响应DIP最终的所有流量都要通过LVS发送给客户端