1. 时间点：这项技术是什么时候诞生的

   1. 2008

2. 在有这项技术之前，production上遇到的问题是什么？来自于什么样的场景？

   1. 负载均衡器的必要性：
      1. 在每个集群内部，必须将流量负载均匀分配到这些服务器，才能高效利用资源，避免任何一台服务器过载
   2. 专用硬件设备限制：
      1. 可扩展性：通常受单台设备最大容量的约束，无法跟上 Google 流量的增长；
      2. 可用性：它们无法满足 Google 对高可用性的要求。虽然通常会成对部署以避免单点故障，但也只能提供 1+1 冗余。
      3. 灵活性/可编程性：它们缺乏快速迭代所需的灵活性和可编程性，因为修改硬件负载均衡器通常非常困难，甚至不可能；
      4. **升级成本很高：**提升硬件负载均衡器的容量，通常既需要购买新硬件，也需要进行物理部署。

3. 你所描述的系统是如何解决这个问题的？它做到了哪些之前系统无法做到的事情？

   1. 分布式软件系统：
      1. 可扩展性：采用横向扩展模式解决可扩展性问题：通过增加系统中的机器数量提升负载均衡器容量，并通过 ECMP 转发将流量均匀分配到所有机器；
      2. 可用性：系统提供 N+1 冗余，从而增强可用性和可靠性；
      3. 灵活性：由于整个系统由我们自己掌控，我们能够快速增加、测试并部署新功能。
      4. 无需特殊机器：负载均衡器本身的部署也大大简化：系统只使用集群内部已有的服务器。
   2. 难点：
      1. 性能：
         1. 不使用linux内核网络协议栈、完全绕过内核（因为不需要完整协议栈，只需要找到合适后端）；
         2. steering→rx queue→packet rewriter→tx queue→muxing，并且不复制报文；
         3. 批处理、避免共享、独占cpu；
      2. 变更/故障的可靠性：如何在maglev机器上下线，后端服务上下线，的情况下同一个五元组的连接能够发给同一个后端？
         1. 后端上下线：（依赖ct表）
            1. 新型一致性hash，能够均匀分配流量；
            2. 选择结果记录本地连接跟踪表；
         2. maglev上下线/CT表有限：（依赖maglev一致性hash）
            1. 原有的一致性hash的问题：最小扰动优于负载均衡；
            2. 核心：
               1. 怎么用：提前生成一张“槽位→后端“的表，先用五元组算槽位，再查表选择后端；
               2. 怎么生成：
                  1. 给每个后端生成一个选座顺序permutation；
                  2. 轮流选一个空位，直到填满；

4. 它的原理是什么？

   1. 整体架构

      

   2. 转发器内部处理流程

      

5. 根据#2 描述的场景，找一个类似的system design案例，代入你研究的系统。解释它是怎么解决现实中的问题, e.g.

   1. 解决什么 workload
      1. 面向大规模互联网服务的入方向 TCP/UDP 流量，承担 VIP 到后端的四层分流；需要高效处理大量小包、新连接及已有连接报文，并尽量保持连接亲和性。
   2. 提供什么 consistency
      1. 同一条连接的报文，应尽量持续到达同一个后端；
   3. 故障如何恢复
      1. 转发节点故障，不必导致已有 TCP 连接断开。
   4. 规模上限在哪里
      • 单机：逐包 CPU 成本、内存访问、网卡包速率与带宽、队列处理能力。
      • 单 VIP／集群：ECMP 可用下一跳数量、网络容量、流量分配是否均匀。
      • 状态与配置：CT、各 VIP 的哈希表、后端配置及更新开销。

6. 该数据系统对应后续的roadmap是什么？ 在#5的 design中，能不能找到一个别的方案替代这个数据系统。代替的系统和原系统之间产生了哪些 trade-off ?

其他问题

1. maglev的健康检查怎么做的？

   1. 每个后端池根据具体要求，关联一种或多种健康检查方法，用以验证池中的所有后端；报文只会被转发给健康后端。由于同一台服务器可能出现在多个后端池中，健康检查会按 IP 地址去重，避免额外开销；（健康检查，检查的是后端服务的健康）
   2. 控制器定期检查转发器的健康状态，并根据检查结果决定通过 BGP 宣告还是撤销
      全部 VIP;

2. maglev的forwarder的设计有什么借鉴点？

   1. 把无关内容去除，转发面之包含核心功能；（比如不需要linux内核协议栈完整功能，只需要转发）；
   2. 这里其实和pipeline思想类似，steering module分流到rx，packet rewriter然后写完再被muxing分到tx

3. 介绍一下maglev hash？

   1. 提前生成一张“槽位 → 后端”的表；报文到来时，用连接的五元组算出槽位，再查表选择后端。
   2. 核心问题：这张表怎么生成，才能既分得均匀，又在后端增减时尽量少改变原来的分配。
   3. 方法：
      1. 建表：后端按各自固定的偏好顺序，轮流填一个空槽。
      2. 查表：连接五元组哈希到槽位，槽位指向后端。
      3. 变更：保持表长和剩余后端的偏好顺序，重新建表，尽量减少映射变化。

4. vip匹配是什么，为什么需要vip匹配这个功能？

   1. 本集群无法继续服务时（或者其他调度策略），把流量转给其他集群；

5. maglev如何处理分片报文的？

   1. 首片也会按三元组重新选择一台 Maglev，并转发过去。不是首片留在原地、只有后续分片被转发。

   2. 由于没有五元组需要前一个分片的信息，所以需要和前一个分片到达同一个maglev机器，这里通过首分片和第二个分片都通过三元组hash到同一台机器来实现

      1 2 3 4 5

      F0 → 路由器 → Maglev A ──按三元组选 C──┐ │ F1 → 路由器 → Maglev B ──按三元组选 C──┼→ Maglev C │ F2 → 路由器 → Maglev B ──按三元组选 C──┘

6. 还有这里的分片，就是有可能tcp连接过程中，刚开始传递的小包不需要分片，后续才需要分片，这种情况后端怎么选择呢？

   1. 依赖maglev hash；

7. 对比maglev在变更时的表现，和TGW在变更时的表现，他们依赖什么实现节点变更找到同一个后端？

   1. maglev：maglev hash；
   2. tgw：状态同步；
   3. 一致性哈希路线强调“答案可以重新算出来”；状态同步路线强调“把已经选好的答案保存并传过去”。后者允许更自由地选择调度算法，前者减少了同步依赖，但故障接管与后端变更叠加时有亲和性边界。

8. 这里怎么评估这里的负载到底是否“均衡“？我看不懂这几个值是什么意思，以及他们为什么能够用来评价负载“均衡”？

   1. Average：平均值；Stdev：标准差；Overprovision：冗余配置系数
   2. 评价指标
      1. Average：大家平均承受多少负载。
      2. Stdev：各台机器偏离平均水平有多大。
      3. Overprovision：最忙的机器，是平均水平的多少倍。
   3. 还有变异系数cv：
      1. 平均负载相同时，标准差越小，分配越均匀；
      2. 平均负载不同是，CV越小，分配越均匀；

9. maglev怎么评估性能的？

   1. 小包 Mpps 测试能更直接地暴露逐包处理能力，而不是让网卡带宽过早掩盖软件瓶颈。

   2. 这里有三种负载

      1. 纯syn；
      2. 正常报文；
      3. 固定五元组；

   3. 其实还有其他评价指标

      指标	回答的问题
      Mpps	每秒能处理多少包？尤其是小包
      Gbps	每秒能转发多少数据？大包、混合包长表现如何？
      CPS	每秒能创建多少条新连接映射？
      并发连接容量	同时能维护多少条连接状态？内存够不够？
      延迟及 p99/p99.9	报文经过网关增加多少延迟？高负载时尾延迟是否恶化？
      丢包率、微突发承受能力	持续压力和短时间突发下，是否丢包？
      资源效率、扩展性	每核 Mpps、每包 CPU 周期、增加核心后吞吐提升多少？

10. 负载均衡算法都有哪些类型的，分别处于什么目的？

    类别	选择依据	常见方法	主要目标
    轮询类	后端顺序、配置权重	RR、WRR、SWRR	按比例分配
    随机类	随机数、配置权重	Random、Weighted Random	简单、分散选择
    负载感知类	当前连接数、在途请求、响应时间等	Least Connections、Least Request、Least Time、P2C	尽量避开忙的后端
    键亲和类	客户端或请求的某个稳定 key	普通哈希、哈希环、HRW、Maglev	同一个 key 尽量去同一个后端
    显式路由／持久化类	已记录或携带的后端身份	Cookie、会话表、可路由 QUIC CID	沿用已经确定的后端

11. 这里的话，那连接状态怎么维护呢？如果轮训，下一个包怎么找到？连接状态不会在线程间共享。

    1 2 3 4 5 6

    分流模块使用五元组哈希而不是轮询调度，原因有二。首先，不同报文线程处理速度不同可能导致同一连接内的报文乱序， 而五元组哈希有助于降低这种概率。 其次，借助连接跟踪，转发器只需为每个连接执行一次后端选择，从而节省时钟周期，并消除因后端健康状态更新的竞态条件而导致后端选择结果不一致的可能性。 极少数情况下，某个接收队列会被填满；此时分流模块回退到轮询调度，将报文分散到其他可用队列。 这种回退机制在处理大量具有相同五元组的洪泛报文时尤其有效。

    这里下一个包找到rs还是依赖maglev hash；

12. 为什么转发型 LB 保留端到端连接，而代理型 LB 有两侧连接？

    这里的区别是是否终止 TCP。NGINX/HAProxy 在 TCP 代理模式下也会终止连接，不能仅按四层或七层区分。

    1 2 3 4 5 6 7

    Client ↓ 四层转发集群：把连接稳定送到某台七层代理 ↓ 七层代理集群：终止连接、解析 HTTP、按请求调度 ↓ 业务服务器

    四层的目标是让入口转发高效、可扩展，并减少转发节点变化对连接的影响；七层的目标是提供业务感知和请求级控制。

13. tgw回包经过他自己，和maglev回包不经过，分别有什么目的吗？各自有什么优点，以及有什么限制？

    1. dsr：处理流量更少，性能更高、省钱；

    2. dsr缺点

       你的约束或目标	为什么可能倾向回经网关
       不能改后端，后端只认识私网地址	在网关集中完成地址适配
       希望明确控制回程路径	通过 NAT／代理等方式把响应引回
       双向策略必须在网关执行	网关必须看得到两个方向
       要处理 HTTP 响应或终止 TLS	响应必须经过相应代理
       可以接受更多网关资源，优先降低接入复杂度	用集中处理换后端接入便利

14. 为了构建大规模集群，我们希望避免要求 Maglev 机器与路由器处于同一二层广播域。因此，我们在路由器后部署硬件封装器，由它们通过隧道将报文从路由器发送给 Maglev 机器。

    1. 正常情况下：

       1 2 3 4 5 6

       入口路由器 │ 一个共同的二层网络 ├─ Maglev A ├─ Maglev B └─ 大量其他 Maglev

    2. 隧道：关键是把服务地址和具体机器的位置地址分开

15. Maglev 通过 hash、TGW 通过会话同步在集群节点变化时尽可能找到同一个 RS，Katran、GitHub GLB、NGINX、HAProxy 怎么做的高可用？

    1. Katran / GitHub GLB：类似 Maglev，用 hash 的方法。

    2. Proxy 模型 vs Director 模型：NGINX/HAProxy 与 Maglev/TGW/Katran/GitHub GLB 不同，Maglev 等都是 Director，始终维护的是一条 TCP 流；NGINX 和 HAProxy 是 Proxy，维护了到 client 和 server 的两个 TCP 流。

    3. 这里是由于他们的职责不一样：

       1. NGINX/HAProxy（Proxy）：
          1. HTTP 模式下，按域名、URL、Header 对请求做不同处理，终止 TLS，集中管理证书和安全策略等应用层操作。关注应用层的细分处理，是应用层路由，实际上是业务的一部分，只是作为 infra service，能够简化业务 service 的实现。
       2. Maglev/Katran/TGW/GLB（Director）：
          1. 数据中心入口网关，通常是做 NAT/tunnel/DSR，然后转发数据包，还是一条 TCP 流，提供负载均衡，控制到不同 RS（一般是业务 service，可能前端有个 NGINX）的负载。功能上来说，业务把它视为一个有负载均衡功能的交换机就可以，和他们本身的七层业务无关。

    4. 这里有两个关注点：连接连续性以及服务可用性。

       服务可用性：对于 Proxy/Director 来说，他们是网络组件，只是做转发，和存储不同，不用存放业务视角的“业务状态”。这里分为两个高可用：

       • 业务高可用：关注的是应用层状态，核心就是用户信息（购物车、打车记录等内容），业务数据高可用由业务 service 本身维护。
       • 连接高可用：由 Proxy/Director 维护，他们关注的是“连接状态”。连接高可用性通过冗余部署以及故障检测、流量切换、正确的配置和足够的接管容量实现，能够在单台机器 down 之后用户还能继续访问。难的是连接的连续性，以及用户重连的代价。

       连接连续性：

       1. Proxy：由于 Proxy 就是 TCP 的 endpoint，本身维护了完整的连接状态。完整的 TCP 状态包括接收到了哪些字节、ack 号、seq 号、window、缓冲区等，无法接受状态延迟同步，此时同步难度比较大，突然 down 之后只能重连。
       2. Director：对于 Director 来说，他只是做中间转发，只需要知道某个连接对应的 RS 信息，就可以通过 hash/会话同步，维护统一的连接 → RS 映射状态。