Load Balancer 将传入的请求分发到应用服务器和数据库等计算资源。无论哪种情况，负载均衡器将来自计算资源的响应，返回给恰当的客户端。负载均衡器的效用在于:
负载均衡器可以通过硬件（昂贵）或 HAProxy 等软件来实现。 增加的好处包括：
X.509）；cookie 并将特定客户端的请求，路由到同一实例。Domain Name System（DNS）将 www.example.com 等域名转换成 IP 地址：
域名系统是分层次的，一些 DNS 服务器位于顶层。当查询（域名）IP 时，路由或 ISP 提供连接 DNS 服务器的信息。较底层的 DNS 服务器缓存映射，它可能会因为 DNS 传播延时而失效。DNS 结果可以缓存在浏览器或操作系统中一段时间，时间长短取决于 TTL（Time To Live）：
Keep in mind that everything is a trade-off.
Next, we’ll look at high-level trade-offs:
如果服务性能的增长与资源的增加是成比例的，服务就是可扩展的。通常，提高性能意味着服务于更多的工作单元，另一方面，当数据集增长时，同样也可以处理更大的工作单位。
另一个角度来看待性能与可扩展性:
延迟是执行操作或运算结果所花费的时间。吞吐量是单位时间内（执行）此类操作或运算的数量。通常，你应该以可接受级延迟下最大化吞吐量为目标。
在一个分布式计算系统中，只能同时满足下列的两点:
网络并不可靠，所以你应要支持分区容错性，并需要在软件一致性和可用性间做出取舍。
等待分区节点的响应可能会导致延时错误。如果你的业务需求需要原子读写，CP 是一个不错的选择。
响应节点上可用数据的最近版本可能并不是最新的。当分区解析完后，写入（操作）可能需要一些时间来传播。如果业务需求允许最终一致性，或当有外部故障时要求系统继续运行，AP 是一个不错的选择。
有同一份数据的多份副本，我们面临着怎样同步它们的选择，以便让客户端有一致的显示数据。回想 CAP 理论中的一致性定义 – 每次访问都能获得最新数据但可能会收到错误响应。
在写入之后，访问可能看到，也可能看不到（写入数据）。尽力优化它，让其能访问最新数据。这种方式可以在 Memcached 等系统中看到。弱一致性在 VoIP，视频聊天和实时多人游戏等真实用例中表现不错。例如：如果你在通话中丢失信号几秒钟时间，当重新连接时，你是听不到这几秒钟所说的话的。
在写入后，访问立即可见，数据被同步复制。文件系统和 RDBMS 使用的是此种方式。强一致性在需要记录的系统中运作良好。
在写入后，访问最终能看到写入数据，数据被异步复制。DNS 和 Email 等系统使用的是此种方式。最终一致性在 HA 系统中效果不错。
有两种支持高可用性的模式：failover 和 replication。
主从切换；主主切换；故障转移的缺陷：
主从复制和主主复制
Availability is often quantified by uptime (or downtime) as a percentage of time the service is available. Availability is generally measured in number of 9s – a service with 99.99% availability is described as having four 9s.
99.9% availability – three 9s:
| Duration | Acceptable downtime |
|---|---|
| Downtime per year | 8h 45min 57s |
| Downtime per month | 43m 49.7s |
| Downtime per week | 10m 4.8s |
| Downtime per day | 1m 26.4s |
99.99% availability – four 9s:
| Duration | Acceptable downtime |
|---|---|
| Downtime per year | 52min 35.7s |
| Downtime per month | 4m 23s |
| Downtime per week | 1m 5s |
| Downtime per day | 8.6s |
If a service consists of multiple components prone to failure, the service’s overall availability depends on whether the components are in sequence or in parallel:
Availability(Total) = Availability(Foo) * Availability(Bar)
Availability(Total) = 1 - (1 - Availability(Foo)) * (1 - Availability(Bar))
Just recently I was asked what it would take to make a web service massively scalable. My answer was lengthy and maybe it is also for other people interesting. So I share it with you here in my blog and split it into parts to make it easier to read. New parts are released on a regular basis. Have fun and your comments are always welcomed!
Public servers of a scalable web service are hidden behind a load balancer. This load balancer evenly distributes load (requests from your users) onto your group/cluster of application servers. That means that if, for example, user Steve interacts with your service, he may be served at his first request by server 2, then with his second request by server 9 and then maybe again by server 2 on his third request.
Steve should always get the same results of his request back, independent what server he “landed on”. That leads to the first golden rule for scalability: every server contains exactly the same codebase and does not store any user-related data, like sessions or profile pictures, on local disc or memory.
Sessions need to be stored in a centralized data store which is accessible to all your application servers. It can be an external database or an external persistent cache, like Redis. An external persistent cache will have better performance than an external database. By external I mean that the data store does not reside on the application servers. Instead, it is somewhere in or near the data center of your application servers.
Get more RAM, processors, disks for one machine, but you will exhaust the financial resources/state.
Plural number of machines, use multiple servers to build the topology.