6. 网站的伸缩性架构
网站伸缩性：不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
6.1 网站架构的伸缩性设计
网站的伸缩性设计：
- 根据功能进行物理分离实现伸缩（不同的服务器部署不同的服务）；
- 单一功能通过集群实现伸缩（集群内的多台服务器部署相同的服务）；
不同功能进行物理分离实现伸缩
纵向分离（分层后分离）：将业务处理流程上的不同部分分离部署。
横向分离（业务分割后分离）：将不同的业务模块分离部署。
单一功能通过集群规模实现伸缩
服务器集群：将相同服务部署在多台服务器上构成一个集群整体对外提供服务。
6.2 应用服务器集群的伸缩性设计
负载均衡，实现网站的伸缩性和可用性。
HTTP 重定向负载均衡
利用 HTTP 重定向协议实现负载均衡。
HTTP 重定向服务器：根据用户的 HTTP 请求计算一台真实的 Web 服务器地址，并将该 Web 服务器地址写入 HTTP 重定向响应中（响应状态码 302）返回给用户浏览器。
优点：部署简单。
缺点：
- 浏览器需要两次请求服务器才能完成一次访问，性能较差。
- 重定向服务器自身的处理能力成为瓶颈，集群的伸缩规模有限。
- 使用 HTTP302 响应状态码重定向，有可能使搜索引擎判断为 SEO 作弊，降低搜索排名。
DNS 域名解析负载均衡
利用 DNS 处理域名解析请求的同时进行负载均衡处理。
优点：将负载均衡的工作交给 DNS。
缺点：
- DNS 是多级解析，有缓存。
- DNS 负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
反向代理负载均衡
利用反向代理服务器实现负载均衡。
大多数反向代理服务器既提供资源缓存，又提供负载均衡功能，管理一组 Web 服务器，将请求根据负载均衡算法转发到不同的 Web 服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于Web服务器不直接对外提供访问，因此Web服务器不需要使用外部IP地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。
反向代理服务器转发请求在 HTTP 协议层面，因此也叫应用层负载均衡。
优点：部署简单。
缺点：反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。
IP 负载均衡
在网络层通过修改请求目标地址进行负载均衡。
用户请求的数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法计算得到一台真实 Web 服务器的 IP 地址，然后将数据目的 IP 地址修改为计算得到的 IP 地址，不需要通过用户进程处理。
真实 Web 服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。
真实物理 Web 服务器响应数据包如何返回给负载均衡服务器？
- 负载均衡服务器在修改目的 IP 地址的同时修改源地址，将数据包源地址设置为自身 IP。
- 将负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数据都会到达负载均衡服务器。
优点：IP 负载均衡在内核进程完成数据分发，较反向代理负载均衡有更好的处理性能。
缺点：所有请求响应都要经过负载均衡服务器，集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽。
数据链路层负载均衡
数据链路层负载均衡：在通信协议的数据链路层修改 mac 地址进行负载均衡。
这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改 IP 地址，只修改目的 mac 地址，通过配置真实物理服务器集群所有机器虚拟 IP 和负载均衡服务器 IP 地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器 IP 和数据请求目的 IP 一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。）这种负载均衡方式又称作直接路由方式（DR）。
使用三角传输模式的链路层负载均衡是目前大型网站使用最广泛的一种负载均衡手段。
在 Linux 平台上最好的链路层负载均衡开源产品是：LVS（Linux Virtual Server）。
：LVS 原理介绍
负载均衡算法
负载均衡服务器的实现可以分为两个部分：
- 根据负载均衡算法和 Web 服务器列表计算得到集群中一台 Web 服务器的地址。
- 将请求数据发送到该地址对应的 Web 服务器上。
6.3 分布式缓存集群的伸缩性设计
分布式缓存集群的伸缩性不能用简单的负载均衡手段来实现。
和所有服务器都部署相同应用的应用服务器集群不同，分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存任何数据，而已下线的缓存服务器还缓存着网站的许多热点数据。
必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标。
Memcached 分布式缓存集群
在 Memcached 分布式缓存系统中，对于服务器集群的管理，路由算法至关重要，和负载均衡算法一样，决定着究竟该访问集群中的哪台服务器。
简单的路由算法：余数 Hash。
在网站访问量最少的时候扩容缓存服务器集群，这时候对数据库的负载冲击最小。
分布式缓存的一致性 Hash 算法
一致性 Hash 算法通过一个叫作一致性性 Hash 环的数据结构实现 KEY 到缓存服务器的 Hash 映射。
参考：知乎：什么是一致性 Hash 算法
6.4 数据存储服务器集群的伸缩性设计
数据存储服务器集群的伸缩性对数据的持久性和可用性要求更高。
关系数据库集群的伸缩性设计
- 利用关系数据库的数据复制功能，可以实现简单的伸缩性。
- 数据库主从读写分离。
- 数据库业务分割，即数据分库。
- 数据分片：将一张表拆开分别存储在多个数据库中。
- 支持分片的分布式数据库产品：Amoeba、Cobar。
Cobar 的两种伸缩性：
- Cobar 服务器集群的伸缩；
- MySQL 服务器集群的伸缩；
NoSQL 数据库的伸缩性设计
NoSQL 主要是指非关系的、分布式的数据库设计模式。
NoSQL 数据库产品都放弃了关系型数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事务一致性保证（ACID）。而强化其他一些大型网站更关注的特性：高可用性和可伸缩性。
NoSQL 数据库产品:
| 临时性键值存储 | 永久性键值存储 | 面向文档的数据库 | 面向列的数据库 |
|---|---|---|---|
| Memcached | Tokyo Tyrant | MongoDB | Cassandra |
| Redis | Flare | CouchDB | HBase |
| ROMA | HyperTable | ||
| Redis |
参考：：NoSQL 还是 SQL ？这一篇讲清楚
高手定律
这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了。
救世主定律
遇到问题，分析问题，最后总能解决问题。