新企业如何在国税网站上做套餐,东莞网络公司招聘信息,读书网站如何做,企业官网营销推广##################################################### #本文内容来自《老男孩linux运维实战培训》学生—郑东旭 #如有转载#xff0c;请务必保留本文链接及本版权信息。 #欢迎广大运维同仁一起交流linux/unix网站运维技术! #QQ:919953500#E-mail:weilandeshanhuhai126.com … ##################################################### #本文内容来自《老男孩linux运维实战培训》学生—郑东旭 #如有转载请务必保留本文链接及本版权信息。 #欢迎广大运维同仁一起交流linux/unix网站运维技术! #QQ:919953500 #E-mail:weilandeshanhuhai126.com 老男孩linux运维实战培训中心 咨询QQ: 70271111 357851641 咨询电话18911718229 网站地址 http://www.etiantian.org 老男孩博客: http://oldboy.blog.51cto.com 老男孩的QQ: 31333741 ##################################################### 本文说明 绿色为重点 红色为警告或注意蓝色为提示或说明黑色为正常输出 面试经验谈架构 1、四层七层负载均衡综合架构... 2 (1)、架构说明... 2 (2)、用户访问流程... 2 (3)、为什么要使用七层负载均衡... 3 (4)、CDN网络说明... 3 2、LB层... 3 (1)、LVS原理... 3 1)、NAT模式-网络地址转换... 3 2)、TUN模式-隧道模式... 3 3)、DR模式-直接路由... 4 4)、FullNAT模式... 4 (2)、DR模式的问题... 4 思考为什么要绑定VIP. 4 思考为什么要抑制ARP. 4 思考RS没有公网地址(dr模式)出站流量怎么走(这个问题有待考证). 4 (3)、LVS调度算法... 4 (4)、keepalived高可用两大功能... 5 1)、LVS directors failover功能... 5 2)、LVS cluster nodes healthchecks 功能未完成... 5 (5)、心跳和脑裂简单介绍... 6 3、Proxy层... 6 4、App层... 6 (1)、lamp lnmp. 6 (2)、Java. 6 (3)、MFS. 6 (4)、Gateway(网关服务器)6 5、Cache层... 6 (2)、memcache原理... 6 (2)、什么是Session. 7 (3)、Session共享方案... 7 6、DB层... 7 (1)、MySQL主从同步解决方案... 7 (2)、MySQL读写分离... 7 (3)、MySQL备份方案... 7 (4)、MySQL高可用... 7 (4)、MySQL高可用脑裂注意事项... 8 面试经验谈架构 把以前的知识复习一遍并连串起来 1、四层七层负载均衡综合架构 (1)、架构说明 绿色线条为正常数据走流红色线条为备用线路数据走流蓝色线为挂载存储CDN网络中红色为同步数据走流 (2)、用户访问流程 用户请求到达VIP地址(公网地址与域名绑定)由四层负载均衡LVS根据自身的算法将用户请求转发到七层负载均衡Proxy代理服务器代理服务器根据用户的请求(可判断head头部信息)判断用户请求的资源(如如果用户使用手机访问代理服务器将请求wap业务机如果用户使用电脑访问代理服务器将请求web业务机) (3)、为什么要使用七层负载均衡 有些公司会有如下的需求是四层负载均衡做不到的 (1)、代理服务器根据用户的请求(可判断head头部信息)判断用户请求的资源(如如果用户使用手机访问代理服务器将请求wap业务机如果用户使用电脑访问代理服务器将请求web业务机) (2)、如果内网服务器跑多个应用比如启动多个基于IP地址的虚拟主机代理服务器可将用户访问一个地址转发到不同的应用服务器 (3)、四层和七层负载均衡在中小企业首选七层负载均衡等以后架构扩展在前端添加四层负载均衡(原因七层负载均衡配置简单不像lvs需要对后端服务器配置操作并且七层负载均衡可以抵挡千万PV) (4)、CDN网络说明 当有西藏的用户访问电子商城如果直接访问北京机房的电子商城速度会非常缓慢大大减少用户访问速度 各地机房放两台CDN节点服务器(电信和联通) (1)、无CDN节点访问流程 西藏联通用户直接访问北京服务器(绿色线)延迟非常大有可能页面显示无法显示该页面 (2)、CND节点访问流程 1)、西藏联通用户请求到智能DNS解析域名 2)、通过智能DNS解析最近西藏机房域名后返回给用户用户请求到西藏机房 3)、如果西藏机房CDN中无用户请求资源CDN代替用户从上海或北京CDN节点请求用户资源应答给用户 4)、请求后的资源缓存到本地CDN节点 2、LB层 lvskeepalived四层负载均衡高可用 (1)、LVS原理 1)、NAT模式-网络地址转换 通过网络地址转换用户发送请求包到调度器(负载均衡器)的VIP地址调度器重写请求报文的目标地址根据预设的算法将请求分发给后端的真实服务器真实服务器响应报文通过调度器时调度器重写报文的源地址再返回给用户完成整个负载调度过程 应用范围由于LVS/NAT模式入站和出站的流量都经过LB大于处理的后端真实服务器是10-20台 2)、TUN模式-隧道模式 采用NAT模式时由于请求和响应报文都经过负载均衡器地址重写当客户端请求越来越来越多时调度器的处理能力将成为瓶颈为了解决这个问题调度器通过算法把请求的报文通过IP隧道(加密的相当于ipip或ipsec)分发至后端真实服务器后端真是服务器将响应直接发送给客户端这样调度器只处理请求的报文由于一般网络服务应答数据比请求报文大很多采用VS/TUN技术后集群系统的最大吞吐量可以提高10倍 说明LVS/TUN不改IP地址是通过隧道转发开启隧道会有系统开销并且响应报文不经过负载均衡器由真实服务器直接响应给用户 应用范围LVS/TUN在互联网中用的不多它可以处理局域网的请求也可处理广域网的请求 3)、DR模式-直接路由 LVS/DR模式通过修改请求报文的MAC地址将请发送发给后端真是服务器后端真是服务器将响应直接返回给用户和VS/TUN模式一样VS/DR模式可极大提高集群系统的伸缩性它没有IP隧道的开销集群系统对后端真是服务器也没有必须支持IP隧道协议的要求但是要求调度器和所有后端真是服务器都有一块网卡连在同一物理网段上(都在一个网段上)(最后一段话重要加颜色)因为他是通过数据链路层ARP协议实现的 1、客户端计算机CIP请求被发送到LVS调度器VIP 2、LVS调度器收到目标地址为VIP的请求包后将该数据包的目的MAC地址通过算法改成某一台RS的MAC地址并通过交换机发送个这台RS服务器(因为目的MAC地址是RS服务所以RS服务器可以接受该数据包)注意此时数据包的目标IP地址和源IP地址没有发生任何改变 3、RS服务器收到发来的数据报文请求后会从链路层上传到IP层此时IP层需要验证请求的目标IP地址因为包的目标IP地址(Director的VIP地址)并不像常规数据包那样为RS的本地IP而仅仅目的MAC地址是RS的 这个时候RS的IP层是验证不过的因为数据包的目的MAC地址是自己的数据包目的的IP地址却不是自己的那么这个时候网络层就不会把包上传到传输层来处理这个数据包 所以在RS上需要配置一个VIP的loopback device,因为loopback device是服务器本地使用的网络接口对外是不可见的与LVS的VIP不会冲突(会有一个ARP抑制问题)RS收到的数据包在自己的网络层验证不过所以要配置一个loopback device上绑定一个IP地址 4、RS处理数据包完成后将应答包直接返回给客户端CIP(此时数据包报文的源地址为客户端请求的目的地址VIP而目的地址为客户端的CIP)应答数据包不会在经过LVS调度器。因此如果是对外提供LVS负载均衡服务则RS需要连上互联网(公网IP或网关)才能将应答包返回给客户端生产环境中RS最好有带公网IP的服务器这样可以不经过网关直接回应客户端如果多个RS使用了同一个出口网关网关可能会成为LVS架构的瓶颈会大大降低LVS的性能 说明为什么RS能直接回应给客户端因为客户端的请求包报文的源地址和目的地址都没有被调度器在网络层改动所以根据以太网的协议回应数据包可以将请求的数据包的源IP当前目的IP把目标IP当前源IP 应用范围互联网公司常用的模式 4)、FullNAT模式 1、可以跨VLAN通信支持更多的后端RS 2、有防DDOS模块 应用范围淘宝新出的一种模式占未广泛使用 (2)、DR模式的问题 思考为什么要绑定VIP 过程原理当客户端的请求包到达路由器路由器会发出广播谁是VIP负载均衡器会响应负载均衡器收到请求包通过自身的算法选择一台RS(比如RS1)修改客户端请求包的目的MAC地址为RS1的MAC地址并发送给RS1这个时候RS1的数据链路层把请求包给网络层网络层需要验证请求包的目标IP地址不是自己就会丢掉此包(此时的数据包源IP是CIP目的IP是VIP)这个时候需要在RS节点上绑定VIP 思考为什么要抑制ARP 过程原理当客户端的请求包到达路由器路由器会发出广播谁是VIP这个时候拥有VIP的负载均衡器和RS真实服务器都会响应这个包导致无法正常工作所以还有对RS做ARP抑制 思考为什么VIP要绑定RS的lo网卡上 RS绑定VIP地址一般情况下是绑定到lo网卡上但我们也可以绑定到其他虚拟网卡比如eth0:10设置改网卡的ARP功能即可 思考RS没有公网地址(dr模式)出站流量怎么走(这个问题有待考证) 负载均衡为DR模式后端RS没有公网IP地址如何将用户请求直接返回给用户 答案 应答请求不走LB直接从路由器返回 (3)、LVS调度算法 算法 说明 rr 轮询调度(Round-Robin) 它将请求一次分配不同的RS也就是在RS中均摊请求算法简单但是只适合于RS处理性能相差不大的情况(多个服务器硬件配置差不多) wrr加权轮询调度(Weighted Round-Robin) 它根据RS不同的权值分配任务权值高的RS优先获得请求分配到的连接数将比权值低的RS更多权值相同的RS得到的连接数数目相同 wlc加权最小连接数调度(Weighted Least-Comnection) (WLC) 具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况并动态地调整其权值。 假设各台RS的权值一次为Wi(l 1..n),当前的TCP连接数依次为Ti(l1..n)一次选取Wi/Ti为最小的RS作为下一个分配的RS dh 目的地址哈希调度(Destination Hashing) 以目的地址为关键字查找一个静态hash表来获得需要的RS sh 源地址哈希调度(Source Hashing) 以源地址作为关键字查找一个静态hash表来获取需要的RS LBLC 基于局部性的最少链接Locality-Based Least Connections 针对目标IP地址的负载均衡目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器若该服务器是可用的且没有超载将请求发送到该服务器若服务器不存在或者该服务器超载且有服务器处于一半的工作负载则用“最少链接” 的原则选出一个可用的服务器将请求发送到该服务器。 LBLCR 带复制的基于局部性最少链接Locality-Based Least Connections with Replication 也是针对目标IP地址的负载均衡目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组按“最小连接”原则从服务器组中选出一台服务器若服务器没有超载将请求发送到该服务器若服务器超载则按“最小连接”原则从这个集群中选出一台服务器将该服务器加入到服务器组中将请求发送到该服务器。同时当该服务器组有一段时间没有被修改将最忙的服务器从服务器组中删除以降低复制的程度。 DH 目标地址散列Destination Hashing 根据请求的目标IP地址作为散列键Hash Key从静态分配的散列表找出对应的服务器若该服务器是可用的且未超载将请求发送到该服务器否则返回空。 SH 源地址散列Source Hashing 根据请求的源IP地址作为散列键Hash Key从静态分配的散列表找出对应的服务器若该服务器是可用的且未超载将请求发送到该服务器否则返回空。 SED 最短的期望的延迟Shortest Expected Delay Scheduling SED 基于wlc算法 ABC三台机器分别权重123 连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算 A(11)/1 B(12)/2 C(13)/3 根据运算结果把连接交给C 。 NQ 最少队列调度Never Queue Scheduling NQ 无需队列。如果有台realserver的连接数0就直接分配过去不需要在进行sed运算 提示现在大约有12中算法常用的有算法有rr,wrr,wlc (4)、keepalived高可用两大功能 1)、LVS directors failover功能 ha failover 功能实现LB Master主机和LB Backup主机之间故障转移和自动切换 这是针对有两个负载均衡器Director同时工作而采取的故障转移措施当主负载均衡器(Master)失效或出现故障时备份负载均衡器(Backup)将自动接管主负载均衡的所有工作一旦主负载均衡器(Master)的故障恢复Master又会接管原来处理的工作而备份负载均衡器(Backup)会释放Master失效时它接管的工作此时两者将恢复到各自最初的角色状态 2)、LVS cluster nodes healthchecks 功能 rs healthcheck功能负载均衡定时检查RS的可用性决定是否给分发请求 当虚拟服务器中的某一个甚至多个真实服务器同时发生故障无法提供服务时负载均衡器会自动将失效的RS服务器从转发列队中清除出去从而保证用户的访问不受影响当故障的RS服务器修复以后系统又会自动的将它们加入到转发列队中分发请求提供正常服务 (5)、心跳和脑裂简单介绍 心跳heartbeat主节点和备节点相互检测对方是否存活 脑裂split-brain两端都认为对端有问题备节点无法检测到主节点的心跳(一般是心跳线故障)各自都自动起VIP这种冲突的问题就叫裂脑 3、Proxy层 haprox/nginx/apache七层负载均衡 前文已经说过了“为什么要使用七层负载均衡” 4、App层 (1)、lamp lnmp 生产环境中web应用程序只用一种要么apache要么nginx图中只是作者在做实验时将两者混用了 (2)、Java 有些公司的页面是由java编写的而使用java容器场景的java容器有tomcat resin weblogic jboss跑java程序 前两者是免费的后两者是收费的 (3)、MFS 分布式文件系统解决nfs单点故障问题 1)、MFS读进程机制 1、客户端向元数据服务器发出读请求 2、元数据服务器吧所需数据存放的位置(Chunk Server的IP地址和chunk编号)告知客户端 3、客户端向已知的Chunk Server请求发送数据 4、Chunk Server向客户端发送数据 特点数据传输并不通过元数据服务器这样既减轻了元数据服务器的压力同时也增大了整个系统的吞吐能力在多个客户端读取数据时会被分散到不同的数据服务器请求 2)、MFS写进程机制 1、客户端向元数据服务器发送写请求 2、元数据服务器与Chunk Server进行交互(只有当所需的分块Chunks存在的时候才进行交互) (1)、元数据服务器只在某些服务器创建新的分块chunks (2)、Chunk Server告知元数据服务器步骤a已经操作成功 3、元数据服务器告知客户端你可以在哪个Chunk Server的哪些chunks写入数据 4、客户端向指定的Chunk Server写入数据 5、Chunk Server与其他的Chunk Server进行数据同步 6、Chunk Server之间同步成功 7、Chunk Server告知客户端数据写入成功 8、客户端告知元数据服务器本次写入完毕 (4)、Gateway(网关服务器) 有上网需求时内网服务器通过该网关服务器上网 5、Cache层 memcached应用非常广泛如数据库的查询请求、session同步、前端web用户请求 (2)、memcache原理 1.接到客户请求后首先查看请求的数据是否在mem中存在如果存在直接返回给用户 2.如果不存在就去查询数据库把从数据库中获得的数据返回给用户同时存在mem中一份以后再有用户需要这个数据就直接返回给用户 3.每次更新了数据库(增删改查)以后mem会同时更新数据保证memcache中的数据和数据库的数据一致 4.当分配给memcache内存空间用完后会使用LRU(Least Recently Used最近最少使用)策略加到期失效策略失效的数据首先被替换掉然后在替换掉最近未使用的数据 5.服务停止后缓存中的数据就会丢失 (2)、什么是Session 说明该图片由网友所画 存放用户登录信息 集群环境 一个用户访问请求被分配到服务器A并且在服务器A登录了并且在很短的时间这个用户又发出了一个请求如果没有会话保持功能的话这个用户的请求很有可能会被分配到服务器B去这个时候用户在服务器B上是没有登录的所以又要重新登录但是用户并不知道自己的请求被分配到了哪里用户的感觉就是登录了怎么又要登录用户体验很不好。 session文件 #ls /tmp sess_4tsn40hhhk4fjpc5nfqd7klla4 sess_eoej5vhddfnqulbjef24dqq926 sess_qjr829a27dhascevs36mg5c855 sess_53kcemteriqguf7q847nnsj4n3 (3)、Session共享方案 1).基于NFS的Session共享 2).基于数据库的Session共享 3).基于Cookie的Session共享 4).基于Memcache的Session共享(推荐) 6、DB层 (1)、MySQL主从同步原理 面试必问 (1)、当有数据写入到master执行的SQL语句会写入到binlog日志中(select查询语句不记录) (2)、Slave的IO线程会通过Master上授权的复制用户请求连接Master服务器请求从指定Binlog日志文件的指定位置之后的Binlog日志内容(日志文件和位置是在配置主从服务时执行change master命令时指定的) (3)、Master服务器接收到Slave服务器的IO线程请求后Master上负责复制的IO线程根据Slave上的IO线程请求的信息读取指定Binlog日志文件制定位置之后的Binlog日志内容然后返回给Slave端的IO线程返回的信息中还包括本次返回的binlog日志内容后在Master服务端的新的Binlog文件名称以及Binlog的位置点 (4)、Slave的IO线程获取到来自Master的IO线程发来的日志内容及日志文件及位置点后将新的binlog日志位置点存放到master-info中以便下次读取Master端新Binlog日志时能够告诉Master需要从新Binlog日志的那个文件那个位置开始请求新的Binlog日志内容。并将Binlog日志内容一次写入到Slave端自身的Relay Log(中继日志)文件的最末端(MySQL-relay-bin.xxxx) (5)、Slave端的SQL线程会实时的检测本地Relay Log新增加的日志内容然后及时的把Real Log文件的内容解析成在Master端曾经执行的SQL语句的内容并在自身Slave上按语句的顺序执行应用这些SQL语句 (6)、经过上面的过程就可以确保在Master端和Slave端执行了同样的SQL语句当复制状态正常情况下Master端和Slave端的数据完全一致 (2)、MySQL主从同步注意事项 1、主库和从库的版本要完全相同 2、主库和从库的server-id不能一样(一般为IP地址的最后一位) 3、主库需要开启binlog日志功能从库无需开启binlog日志功能除非做双主模式和级联复制模式 (3)、MySQL主从同步解决方案 方案一MySQL主从同步 方案二MySQL一主多从架构 方案三MySQL多实例主从同步(互为主从) 方案四MySQL双主架构 方案五MySQL多主(拆库拆表) 方案六MySQL级联复制 (4)、MySQL读写分离 由开发人员参与 (5)、MySQL备份方案 备份时从库停止SQL线程备份后开启SQL线程保证不丢失数据如果要求比较严格可以备份binlog日志 (6)、MySQL高可用 mysqlheartbeatdrbd mysqlheartbeatreplication mysqlheartbeat存储 说明也可以用keepalived做高可用软件 (7)、MySQL高可用脑裂注意事项 数据库脑裂非常危险会导致数据不一致 (8)、MySQL高可用脑裂解决方法 R710有四个网口一般无特殊情况只用其中两个剩下两个在插两根心跳线 转载于:https://blog.51cto.com/shanhu/1069909
