- 如何解决网站的高并发访问？ 高并发： 响应缓慢 服务卡顿 服务器宕机
- 思路： 找性能瓶颈 定位单点 （监控工具）
- 解决方案： 隔离 扩展
- 动静分离
- 拆分数据库
- 缓存
- 队列
- 负载均衡
- 逻辑隔离 // 虚拟化技术
- 硬件虚拟化 //VMware EXSI Ovirt
- 指令集虚拟化
- 运行库虚拟化 // 容器技术 容器编排工具 K8S
- 网络资源的高并发
- web服务器的选择
- apache + 补充模块 = 用来运行web应用的容器
- php 程序可以直接被apache运行
- apache 的事务处理模型虽然经过迭代，相对从前在面对高并发业务场景下有一定的改进，但是处理能力依旧不能满足当前的需求
- perfork
- event // 相对高效的处理模型
- work
- apache + 补充模块 = 用来运行web应用的容器
- web服务器的选择
-
-
- nginx // 反向代理
- php web应用程序在结合nginx 使用的情况下，php的请求通过nginx 反向代理交给php-fpm 等专门运行php程序的服务
- epoll 事件处理模型
- 技术前提，linux内核支持异步非阻塞事件处理 // 非阻塞相对于阻塞，系统运行效率更高
- io多路复用
- nginx // 反向代理
- 负载均衡和应用网关
- 负载均衡 架构设计
- 应用网关 一开始主要由开发人员维护并设置对应的路由规则
- 将完整的网站功能拆分到不同的集群中 （微服务）
- 应用网关 （某种形式的负载均衡// 典型的七层负载均衡）
- 服务注册
- 将完整的网站功能拆分到不同的集群中 （微服务）
- 负载均衡 // 使用多个服务器响应客户端请求，同时还需要保证每一个服务器的工作负载较为均匀
- 软件负载均衡 // 相对廉价，且维护成本低
- 软件层负载均衡典型软件 lvs nginx haproxy
- 保证负载均衡的稳定 引入keepalived 实现服务高可用
- pphc 这本书，从这一步开始进行的优化，就是从网络架构上进行的优化
- ospf+ecmp 实现不丢包和链路高可用
- 增加VIP对应的网卡数量，实现流量处理能力增强
- 设置两个入口网关
- 为每一个lvs节点增加一个新的VIP 进一步极高LVS的流量处理能力
- 软件负载均衡 // 相对廉价，且维护成本低
-
-
-
- 硬件负载均衡 // 处理效率高效 相较软件负载均衡 面对高并发 性能表现更好 价格昂贵
- 四层的负载均衡
- 维护NAT表 和 两个五元组
- 对IP报文进行目标地址转换
- 四层的负载均衡
- 硬件负载均衡 // 处理效率高效 相较软件负载均衡 面对高并发 性能表现更好 价格昂贵
-
keepalived 实验架构
keepalived 如何实现高可用？
基于vrrp协议实现高可用。
- 选举
- 使用VRRP协议启动的实例，在启动时将为其配置对应的优先级，优先级的值越高，优先级越高，而优先级最高的实例将成为主节点（获得VIP的分配）其他节点自动成为备份节点
- 主节点获得VIP
- 心跳线
- 选举完成，主节点将持续发送集群状态给剩余的vrrp实例，备份实例将持续收到来自主节点的vrrp状态报文，并比较状态报文与选举阶段形成的集群状态是否一致
- 故障转移
- 如果心跳线失效之后，主要是主节点down 停止发送状态报文，或者主节点因为某些原因将优先级调低；
- 从节点将重新进行选举，从vrrp实例集群中选举新的主节点，剩余的从节点继续作为备份节点
- VIP 将随着重新选举的过程而分配给新的主节点，所以VIP也叫作漂移IP
实验要求：
- 实现负载均衡器的高可用，提升负载均衡器在面对高并发时的稳定性
实验的延伸：
- 增加一个VRRP实例配置，设置两个漂移VIP ，提升面对高并发时架构带宽
- vip 一般对应每一个VRRP实例的网络接口，本次实验中将使用以太网接口实现配置，可以尝试将多个以太网卡接口配置链路聚合功能，进一步提升带宽
IP地址规划：
后端服务器将统一使用虚拟主机进行配置
192.168.110.33 （80-82）
负载均衡器： 192.168.110.11 192.168.110.22
vrr