元数据
构建高可用Linux服务器(第4版)
- 书名: 构建高可用Linux服务器(第4版)
- 作者: 余洪春
- 简介: 本书的内容是对实际工作经验的总结,涉及大量的知识点和专业术语,建议经验不足的读者一定从第1章读起,本章内容相对来说比较基础。大家在学习过程中根据第1章的讲解进行操作,定会达到事半功倍的效果。推荐系统管理员和运维工程师们通篇阅读本书,并重点关注第2章、第4章、第5章、第7章和第8章的内容,这些都与运维工作息息相关的,建议大家多花些精力和时间,抱着一切从线上环境去考虑的态度去学习。
- 出版时间 2018-01-01 00:00:00
- ISBN: 9787111582953
- 分类: 计算机-计算机综合
- 出版社: 机械工业出版社
高亮划线
1.1 网站架构设计相关
-
📌 主动关闭的一方在发送最后一个ACK后就会进入TIME_WAIT状态,并停留2MSL(报文最大生存)时间 ^920140-5-31145-31196
- ⏱ 2021-12-20 02:31:34
-
📌 主动关闭方发送的最后一个ACK(FIN)有可能会丢失 ^920140-5-31402-31428
- ⏱ 2021-12-20 10:01:16
5.1 负载均衡高可用核心概念及常用软件
-
📌 调度器是服务器集群系统的唯一入口点(Single Entry Point),它可以采用IP负载均衡技术、基于内容请求分发技术或将两者结合使用。在IP负载均衡技术中,需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时,调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器,将该请求转发到选出的服务器,并记录这个调度。当这个请求的其他报文到达时,也会被转发到前面选出的服务器。在基于内容请求分发技术中,服务器可以提供不同的服务,当客户请求到达时,调度器可根据请求的内容选择服务器执行请求。因为所有的操作都是在Linux操作系统核心空间中完成的,它的调度开销很小,所以它具有很高的吞吐率。 ^920140-13-4362-4665
- ⏱ 2021-12-20 16:30:19
-
📌 客户通过Virtual IP Address(虚拟服务的IP地址)访问网络服务时,请求报文到达调度器,调度器根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。同时,调度器在连接Hash表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时,调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口,再把报文发给用户。 ^920140-13-7769-8083
- ⏱ 2021-12-20 16:58:34
-
📌 通过NAT实现虚拟服务器(VS/NAT) ^920140-13-7128-7148
- ⏱ 2021-12-20 16:59:55
-
📌 通过直接路由实现虚拟服务器(VS/DR) ^920140-13-9154-9174
- ⏱ 2021-12-20 17:00:52
-
📌 VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外是不可见的,只是用于处理目标地址为VIP的网络请求。 ^920140-13-9494-9603
- ⏱ 2021-12-20 17:02:45
-
📌 VS/DR利用大多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户 ^920140-13-9215-9270
- ⏱ 2021-12-20 17:03:29
-
📌 VS/DR中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组相连的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。 ^920140-13-9692-9894
- ⏱ 2021-12-20 19:31:26
-
📌 eastconn建议用于长会话服务 ^920140-13-14016-14033
- ⏱ 2021-12-20 19:44:00
-
📌 局部性 ^920140-13-12561-12564
- ⏱ 2021-12-20 19:49:41
-
📌 找出该目标IP地址最近使用的服务器 ^920140-13-12619-12636
- ⏱ 2021-12-20 19:49:55
-
📌 为拒绝使用会话cookie的客户端提供最有效的粘连。 ^920140-13-14255-14281
- ⏱ 2021-12-20 19:55:12
-
📌 一致性Hash算法。它的具体做法是:将每个Server虚拟成N个节点并均匀分布到hash环上,每次请求都根据配置的参数计算出一个hash值,在hash环上查找离这个hash最近的虚拟节点,对应的server作为该次请求的后端机器,这样做的好处是如果是动态地增加机器或者发生某台Web机器发生Crash情况,会对整个集群的影响最小。 ^920140-13-16200-16365
- ⏱ 2021-12-21 13:41:23
-
📌 基于Cookie的Session共享 ^920140-13-23529-23547
- ⏱ 2021-12-21 14:03:32
-
📌 用户的Session信息加密,序列化后以Cookie的方式统一种植在根域名下(如:.host.com)。当浏览器访问该根域名下的所有二级域名站点时,将与域名相对应的所有Cookie内容的特性传递给它,从而实现用户的Cookie化Session在多服务间的共享访问。 ^920140-13-23612-23775
- ⏱ 2021-12-21 14:04:01
-
📌 基于数据库的Session共享 ^920140-13-24024-24039
- ⏱ 2021-12-21 14:05:09
-
📌 使用内存表 ^920140-13-24087-24092
- ⏱ 2021-12-21 14:10:00
-
📌 会话保持机制的目的是保证在一定时间内某一个用户与系统会话只交给同一台服务器处理 ^920140-13-25813-25852
- ⏱ 2021-12-21 14:14:28
-
📌 基于源IP地址的持续性保持。 ^920140-13-25931-25945
- ⏱ 2021-12-21 14:15:27
-
📌 基于Cookie数据的持续性保持。 ^920140-13-26066-26083
- ⏱ 2021-12-21 14:15:42
-
📌 基于HTTP报文头的持续性保持。 ^920140-13-26216-26232
- ⏱ 2021-12-21 14:17:53
-
📌 最好是选择带有硬件防火墙的BGP机房(可以帮忙防御部分DDos攻击) ^920140-13-108013-108047
- ⏱ 2021-12-21 14:49:33
-
📌 Keepalived的作用是检测Web服务器的状态,如果有一台Web服务器死机或工作出现故障,Keepalived将检测到并将有故障的Web服务器从系统中剔除,当Web服务器工作正常后,Keepalived会自动将Web服务器加入到服务器群中 ^920140-13-19332-19453
- ⏱ 2021-12-21 14:58:57
-
📌 单IP多线路,做到所有互联运营商的用户访问都很快速 ^920140-13-111982-112007
- ⏱ 2021-12-21 15:40:19
-
📌 硬件防火墙的主要作用是防止DDoS攻击和端口映射。 ^920140-13-112165-112190
- ⏱ 2021-12-21 15:40:38
-
📌 在遇到DDos攻击的时候,CDN会帮忙抗住大部分的流量,这里分摊到源站的流量就会非常少 ^920140-13-112672-112715
- ⏱ 2021-12-21 16:16:49
-
📌 Web缓存层可以使用Squid或Varnish。 ^920140-13-113807-113831
- ⏱ 2021-12-21 16:22:12
-
📌 用一台独立memcached或redis服务器来存储整个网站的Session数据,再通过改写PHP的Session处理函数来对memcached或redis服务器进行数据读写,然后解决各个服务器中Session不同步的问题。 ^920140-13-116457-116569
- ⏱ 2021-12-21 16:30:06
-
📌 Session复制的原理是通过组播的方式进行集群间的Session共享 ^920140-13-116694-116729
- ⏱ 2021-12-21 16:31:01
-
📌 redisNoSQL数据库作为数据库缓存非常理想,它们在减轻数据库读写压力方面效果显著。 ^920140-13-117001-117045
- ⏱ 2021-12-21 16:34:00
-
📌 更新用户相关缓存需要分布式存储,比如使用用户ID进行hash分组,把用户分布到不同的缓存中,这样一个缓存集合的总量不会很大,也不会影响查询效率。 ^920140-13-117285-117357
- ⏱ 2021-12-21 16:38:19
-
📌 像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务,前面提到的通用方案就无法支撑,并发的时候都是直接命中DB。设计这块业务的时候就会使用消息队列,可以将参与用户的信息添加到消息队列中,然后编写一个多线程程序去消耗队列,给队列中的用户发放红包。 ^920140-13-117814-117941
- ⏱ 2021-12-21 16:41:58
-
📌 一般习惯使用redis的List(列表)类型→当用户参与活动,将用户参与信息push到队列中→编写一个多线程程序去pop数据,进行发放红包的业务 ^920140-13-118234-118306
- ⏱ 2021-12-21 16:45:04
-
📌 数据库的压力 ^920140-13-118554-118560
- ⏱ 2021-12-21 17:11:51
-
📌 首先是增加数据库缓存,redis、memcached等NoSQL数据库作为数据库缓存都非常理想,它们在减轻数据库读写压力方面效果显著。 ^920140-13-118710-118777
- ⏱ 2021-12-21 17:12:12
-
📌 1)数据库架构可以采用一主多从,读写分离的方案,用LVS+Keepalived作为从数据库的负载均衡器,读写通过程序上实现分离,前后台业务逻辑分离,将针对后台的查询全部转到Slave机器上,这样就算查询的业务量很大也不会影响主要业务逻辑。 ^920140-13-119049-119168
- ⏱ 2021-12-21 17:19:01
-
📌 2)对网站的业务数据库进行分库,后面的业务都是一组数据库,如web、bbs、blog等,对主要业务数据库进行数据的水平切分或垂直切分也是非常有必要的。 ^920140-13-119197-119272
- ⏱ 2021-12-21 17:20:18
-
📌 LVS/DR四层负载均衡工作流程 ^920140-13-123145-123161
- ⏱ 2021-12-21 17:25:02
-
📌 后端的真实服务器发出响应,源地址为集群VIP地址,目的地址为客户端IP地址,不通过LVS负载均衡服务器(报文仍然要经过交换机)直接与客户机发生联系,回应客户机最初发出的HTTP请求。 ^920140-13-123563-123654
- ⏱ 2021-12-21 17:26:25
-
📌 七层负载均衡工作流程 ^920140-13-123999-124009
- ⏱ 2021-12-21 17:30:52
-
📌 四层负载均衡设备(如LVS/DR)的优势在于面对大流量的冲击时,报文只是单方面经过四层负载均衡设备,负载均衡设备负担很小,不易成为网站或系统瓶颈(特别适用于CDN场景) ^920140-13-124504-124588
- ⏱ 2021-12-21 17:38:57
-
📌 ;而七层负载均衡在分流过程中能够对应用层协议进行深度识别,带来更精细化均衡的可能,再加上HTTP协议应用广泛并且相对简单,所以七层负载均衡对HTTP请求进行负载均衡的商用能力最强。 ^920140-13-124588-124678
- ⏱ 2021-12-21 17:39:34
6.1 MySQL数据库的优化
-
📌 通常认为磁盘I/O是制约MySQL性能的最大因素之一。 ^920140-15-779-806
- ⏱ 2021-12-21 17:47:02
-
📌 主从复制 ^920140-15-57314-57318
- ⏱ 2021-12-23 13:44:10
-
📌 1)主服务器把数据更新记录到二进制日志中。2)从服务器把主服务器的二进制日志拷贝到自己的中继日志中,这个由从服务器的I/O线程负责。3)从服务器执行中继日志,把其更新应用到自己的数据库上,这个由从服务器的SQL线程负责。 ^920140-15-57459-57627
- ⏱ 2021-12-23 13:44:28
7.1 基础网络知识
- 📌 tables会根据不同的数据包处理功能使用不同的规则表。它包括如下三个表:filter、nat和mangle。 ^920140-17-9792-9847
- ⏱ 2021-12-23 14:28:39
