1. 如何解决网站的高并发访问？    高并发： 响应缓慢   服务卡顿  服务器宕机
   1. 思路： 找性能瓶颈  定位单点    （监控工具）
   2. 解决方案：  隔离  扩展
      • 动静分离
      • 拆分数据库
      • 缓存
      • 队列
      • 负载均衡
      • 逻辑隔离   // 虚拟化技术
        1. 硬件虚拟化 //VMware EXSI Ovirt
        2. 指令集虚拟化
        3. 运行库虚拟化 // 容器技术    容器编排工具  K8S
2. 网络资源的高并发
   1. web服务器的选择
      • apache + 补充模块   =  用来运行web应用的容器
        1. php 程序可以直接被apache运行
        2. apache 的事务处理模型虽然经过迭代，相对从前在面对高并发业务场景下有一定的改进，但是处理能力依旧不能满足当前的需求
           1. perfork
           2. event // 相对高效的处理模型
           3. work

• • • nginx // 反向代理
      1. php web应用程序在结合nginx 使用的情况下，php的请求通过nginx 反向代理交给php-fpm 等专门运行php程序的服务
      2. epoll 事件处理模型
         1. 技术前提，linux内核支持异步非阻塞事件处理   // 非阻塞相对于阻塞，系统运行效率更高
         2. io多路复用  
  • 负载均衡和应用网关
    • 负载均衡 架构设计
    • 应用网关  一开始主要由开发人员维护并设置对应的路由规则
      1. 将完整的网站功能拆分到不同的集群中     （微服务）
         1. 应用网关 （某种形式的负载均衡// 典型的七层负载均衡）
         2. 服务注册
  • 负载均衡     // 使用多个服务器响应客户端请求，同时还需要保证每一个服务器的工作负载较为均匀
    • 软件负载均衡 // 相对廉价，且维护成本低
      1. 软件层负载均衡典型软件  lvs    nginx   haproxy
      2. 保证负载均衡的稳定 引入keepalived  实现服务高可用
      3. pphc 这本书，从这一步开始进行的优化，就是从网络架构上进行的优化
         1. ospf+ecmp  实现不丢包和链路高可用
         2. 增加VIP对应的网卡数量，实现流量处理能力增强
         3. 设置两个入口网关
         4. 为每一个lvs节点增加一个新的VIP 进一步极高LVS的流量处理能力

• • • 硬件负载均衡 // 处理效率高效 相较软件负载均衡 面对高并发 性能表现更好 价格昂贵
      1. 四层的负载均衡
         1. 维护NAT表 和 两个五元组
         2. 对IP报文进行目标地址转换

keepalived 实验架构

keepalived 如何实现高可用？

基于vrrp协议实现高可用。

1. 选举
   1. 使用VRRP协议启动的实例，在启动时将为其配置对应的优先级，优先级的值越高，优先级越高，而优先级最高的实例将成为主节点（获得VIP的分配）其他节点自动成为备份节点
   2. 主节点获得VIP
2. 心跳线
   1. 选举完成，主节点将持续发送集群状态给剩余的vrrp实例，备份实例将持续收到来自主节点的vrrp状态报文，并比较状态报文与选举阶段形成的集群状态是否一致
3. 故障转移
   1. 如果心跳线失效之后，主要是主节点down 停止发送状态报文，或者主节点因为某些原因将优先级调低；
   2. 从节点将重新进行选举，从vrrp实例集群中选举新的主节点，剩余的从节点继续作为备份节点
   3. VIP 将随着重新选举的过程而分配给新的主节点，所以VIP也叫作漂移IP

实验要求：

1. 实现负载均衡器的高可用，提升负载均衡器在面对高并发时的稳定性

实验的延伸：

1. 增加一个VRRP实例配置，设置两个漂移VIP ，提升面对高并发时架构带宽
2. vip 一般对应每一个VRRP实例的网络接口，本次实验中将使用以太网接口实现配置，可以尝试将多个以太网卡接口配置链路聚合功能，进一步提升带宽

IP地址规划：

后端服务器将统一使用虚拟主机进行配置

192.168.110.33  （80-82）

负载均衡器： 192.168.110.11     192.168.110.22

vrr