读书笔记（SRE：Google运维解密）：第19章 前端服务器的负载均衡

• 流量负载均衡（traffic load balancing）
   
• 理想情况下，用户流量应该最优地分布于多条网络链路上、多个数据中心中，以及多台服务器上。但是这里的“最优”是如何定义的呢？最优严重依赖于下列几个因素：
  （a）逻辑层级（是在全局还是在局部）。
  （b）技术层面（硬件层面与软件层面）。
  （c）用户流量的天然属性。

简化的场景：一个简单的搜索请求和一个视频上传请求。用户想要很快地获取搜索结果，所以对搜索请求来说最重要的变量是延迟（latency）。而对于视频上传请求来说，用户已经预期该请求将要花费一定的时间，但是同时希望该请求能够一次成功，所以这里最重要的变量是吞吐量（throughput）。两种请求用户的需求不同，是我们在全局层面决定“最优”分配方案的重要条件。

• 搜索请求将会被发往最近的、可用的数据中心—评价条件是数据包往返时间（RTT），因为我们想要最小化该请求的延迟。
• 视频上传流将会采取另外一条路径—也许是一条目前带宽没有占满的链路—来最大化吞吐量，同时也许会牺牲一定程度的延迟。
   

但是在局部层面，在一个数据中心内部，我们经常假设同一个物理建筑物内的所有物理服务器都在同一个网络中，对用户来说都是等距的。因此在这个层面上的“最优”分配往往关注于优化资源的利用率，避免某个服务器负载过高。

 

• DNS进行负载均衡

在某个客户端发送HTTP请求之前，经常需要先通过DNS查询IP地址。这就为我们第一层的负载均衡机制提供了一个良好基础：DNS负载均衡。最简单的方案是在DNS回复中提供多个A记录或者AAAA记录，由客户端任意选择一个IP地址使用。这种方案虽然看起来简单并且容易实现，但是存在很多问题。问题如下：

• 对客户端行为的约束力很弱：记录是随机选择的，也就是每条记录都会引来有基本相同数量的请求流量。
• 潜在问题是客户端无法