■ 正文
网站的伸缩性是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。最重要的技术手段就是使用服务器集群，通过不断地向集群中添加服务器来增强整个集群的处理能力。这就是网站系统的伸缩性架构，只要技术上能做到向集群中加入服务器的数量和集群的处理能力成线性关系，那么网站就可以以此手段不断提升自己的规模，从一个服务几十人的小网站发展成服务几十亿人的大网站，从只能存储几个G图片的小网站发展成存储几百P图片的大网站。
1.1 网站架构的伸缩性设计
1) 网站的伸缩性设计可分成两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的功能；后者是集群内的多台服务器部署相同的服务，提供相同的功能。
2) 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车。
1.2 应用服务器集群的伸缩性设计
1) HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。
1.2.1 HTTP重定向负载均衡
1) HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览器。在图6.5中，浏览器请求访问域名www.mysite.com，DNS服务器解析得到IP地址是114.100.80.10，即HTTP重定向服务器的IP地址。然后浏览器通过IP地址 114.100.80.10访问HTTP重定向负载均衡服务器后，服务器根据某种负载均衡算法计算获得一台实际物理服务器的地址（114.100.80.3），构造一个包含该实际物理服务器地址的重定向响应返回给浏览器，浏览器自动重新请求实际物理服务器的IP地址114.100.80.3，完成访问。
2) 这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多见。
1.2.2 DNS域名解析负载均衡
1) 大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部负载均衡服务器再进行负载均衡，将请求分发到真实的Web服务器上。
1.2.3 反向代理负载均衡
1) 反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。其优点是和反向代理服务器功能集成在一起，部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。
1.2.4 IP负载均衡
1) 用户请求数据包到达负载均衡服务器114.100.80.10后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法计算得到一台真实Web服务器10.0.0.1，然后将数据目的IP地址修改为10.0.0.1，不需要通过用户进程处理。真实Web应用服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址（114.100.80.10）发送给用户浏览器。
2) 这里的关键在于真实物理Web服务器响应数据包如何返回给负载均衡服务器。一种方案是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址设为自身IP，即源地址转换（SNAT），这样Web服务器的响应会再回到负载均衡服务器；另一种方案是将负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数据都会到达负载均衡服务器。
1.2.5 数据链路层负载均衡
1) 这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称作直接路由方式（DR）。
2) 在下图中，用户请求到达负载均衡服务器114.100.80.10后，负载均衡服务器将请求数据的目的mac地址修改为00:0c:29:d2，并不修改数目包目标IP地址，由于Web服务器集群所有服务器的虚拟IP地址都和负载均服务器的IP地址相同，因此数据可以正常传输到达mac地址00:0c:29:d2对应的服务器，该服务器处理完成后发送响应数据到网站的网关服务器，网关服务器直接将该数据包发送到用户浏览器（通过互联网），响应数据不需要通过负载均衡服务器。
1.2.6 负载均衡算法
1) 负载均衡服务器的实现可以分成两个部分：
a) 根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址。
b) 将请求数据发送到该地址对应的Web服务器上。
2) 轮询（Round Robin，RR）：所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。
3) 加权轮询（Weighted Round Robin，WRR）：根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器能分配更多请求。
4) 随机（Random）：请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以使用加权随机算法。
5) 最少连接（Least Connections）：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。同样，最少连接算法也可以实现加权最少连接。
6) 源地址散列（Source Hashing）：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话黏滞。
1.3 分布式缓存集群的伸缩性设计
1) 和所有服务器都部署相同应用的应用服务器集群不同，分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存任何数据，而已下线的缓存服务器还缓存着网站的许多热点数据。
2) 必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标。
1.3.1 Memcached分布式缓存集群的访问模型
1) 应用程序通过Memcached客户端访问Memcached服务器集群，Memcached客户端主要由一组API、Memcached服务器集群路由算法、Memcached服务器集群列表及通信模块构成。
2) 其中路由算法负责根据应用程序输入的缓存数据KEY计算得到应该将数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器读数据（读缓存）。
3) 一个典的型缓存写操作如图6.10中箭头所示路径。应用程序输入需要写缓存的数据路<'BEIJING',DATA>，API将KEY（'BEIJING'）输入路由算法模块，路由算法根据KEY和Memcached集群服务器列表计算得到一台服务编号（NODE1），进而得到该机器的IP地址和端口（10.0.0.0:91000）。API调用通信模块和编号为NODE1的服务器通信，将数据的<'BEIJING',DATA>写入该服务器。完成一次分布式缓存的写操作。
4) 读缓存的过程和写缓存一样，由于使用同样的路由算法和服务器列表，只要读缓存的过程和写缓存一样，由于使用同样的路由算法和服务器列表，只要应用程序提供相同的KEY（'BEIJING'），Memcached客户端总是访问相同的服务器（NODE1）去读取数据。只要服务器还缓存着该数据，就能保证缓存命中。
1.3.2 Memcached分布式缓存集群的伸缩性挑战
1) 简单的路由算法可以使用余数Hash：用服务器数目除以缓存数据KEY的Hash值，余数为服务器列表下标编号。假设图6.10中'BEIJING'的Hash值是490806430（Java中的HashCode（）返回值），用服务器数目3除以该值，得到余数1，对应节点NODE1。由于HashCode具有随机性，因此使用余数Hash路由算法可保证缓存数据在整个Memcached服务器集群中比较均衡地分布。
2) 对余数Hash路由算法稍加改进，就可以实现和负载均衡算法中加权负载均衡一样的加权路由。事实上，如果不需要考虑缓存服务器集群伸缩性，余数Hash几乎可以满足绝大多数的缓存路由需求。
3) 但是，当分布式缓存集群需要扩容的时候，事情就变得棘手了。假设由于业务发展，网站需要将3台缓存服务器扩容至4台。更改服务器列表，仍旧使用余数Hash，用4除以'BEIJING'的Hash值49080643，余数为2，对应服务器NODE2。由于数据。<'BEIJING',DATA>缓存在NODE1，对NODE2的读缓存操作失败，缓存没有命中。
4) 很容易就可以计算出，3台服务器扩容至4台服务器，大约有75％（3/4）被缓存了的数据不能正确命中，随着服务器集群规模的增大，这个比例线性上升。当100台服务器的集群中加入一台新服务器，不能命中的概率是99％（N /（N ＋1））。
1.3.3 分布式缓存的一致性Hash算法
1) 一致性Hash算法通过一个叫作一致性Hash环的数据结构实现KEY到缓存服务器的Hash映射，具体算法过程为：先构造一个长度为0~232 的整数环（这个环被称作一致性Hash环），根据节点名称的Hash值（其分布范围同样为0~232 ）将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的KEY值计算得到其Hash值（其分布范围也同样为0~232 ），然后在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找。
2) 假设NODE1的Hash值为3,594,963,423，NODE2的Hash值为1,845,328,979，而KEY0的Hash值为2,534,256,785，那么KEY0在环上顺时针查找，找到的最近的节点就是NODE1。
3) 当缓存服务器集群需要扩容的时候，只需要将新加入的节点名称（NODE3）的Hash值放入一致性Hash环中，由于KEY是顺时针查找距离其最近的节点，因此新加入的节点只影响整个环中的一小段
4) 假设NODE3的Hash值是2,790,324,235，那么加入NODE3后，KEY0（Hash值2,534，256,785）顺时针查找得到的节点就是NODE3。
5) 加入新节点NODE3后，原来的KEY大部分还能继续计算到原来的节点，只有KEY3、KEY0从原来的NODE1重新计算到NODE3。这样就能保证大部分被缓存的数据还可以继续命中。3台服务器扩容至4台服务器，可以继续命中原有缓存数据的概率是75％，远高于余数Hash的25％，而且随着集群规模越大，继续命中原有缓存数据的概率也逐渐增大，100台服务器扩容增加1台服务器，继续命中的概率是99％。虽然仍有小部分数据缓存在服务器中不能被读到，但是这个比例足够小，通过访问数据库获取也不会对数据库造成致命的负载压力。
6) 具体应用中，这个长度为2^32 的一致性Hash环通常使用二叉查找树实现，Hash查找过程实际上是在二叉查找树中查找不小于查找数的最小数值。当然这个二叉树的最右边叶子节点和最左边的叶子节点相连接，构成环。
7) 
1.4 数据存储服务器集群的伸缩性设计
1) 数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性。因此缓存服务器集群的伸缩性架构方案不能直接适用于数据库等存储服务器。存储服务器集群的伸缩性设计相对更复杂一些，具体说来，又可分为关系数据库集群的伸缩性设计和NoSQL数据库的伸缩性设计。
1.4.1 关系数据库集群的伸缩性设计
1) 主从模式：
a) 在这种架构中，虽然多台服务器部署MySQL实例，但是它们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。
b) 除了数据库主从读写分离，前面提到的业务分割模式也可以用在数据库，不同业务数据表部署在不同的数据库集群上，即俗称的数据分库。这种方式的制约条件是跨库的表不能进行Join操作。
c) 在大型网站的实际应用中，即使进行了分库和主从复制，对一些单表数据仍然很大的表，比如Facebook的用户数据库，淘宝的商品数据库，还需要进行分片，将一张表拆开分别存储在多个数据库中。
d) 
2) 集群模式：
a) Cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间（Cobar也支持非独立部署，以lib的方式和应用程序部署在一起）。应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行（每个MySQL实例都部署为主/从结构，保证数据高可用）。
b) 
1.4.2 NoSQL数据库的伸缩性设计
1) 大型网站遇到了关系数据库难以克服的缺陷——糟糕的海量数据处理能力及僵硬的设计约束，局面才有所改善。为了解决上述问题，NoSQL这一概念被提了出来，以弥补关系数据库的不足。
2) HBase：为可伸缩海量数据储存而设计，实现面向在线业务的实时数据访问延迟。HBase的伸缩性主要依赖其可分裂的HRegion及可伸缩的分布式文件系统HDFS实现。
1.5 小结
1) 一个具有良好伸缩性架构设计的网站，其设计总是走在业务发展的前面，在业务需要处理更多访问和服务之前，就已经做好充足准备，当业务需要时，只需要购买或者租用服务器简单部署实施就可以了，技术团队亦可高枕无忧。反之，设计和技术走在业务的后面，采购来的机器根本就没办法加入集群，勉强加了进去，却发现瓶颈不在这里，系统整体处理能力依然上不去。技术团队每天加班，却总是拖公司发展的后腿。架构师对网站伸缩性的把握，一线之间，天堂和地狱。
2) 高手定律：这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了。所以百度有很多广告搜索的高手，淘宝有很多海量数据的高手，QQ有很多高并发业务的高手，原因大抵如此。一个100万用户的网站，不会遇到1亿用户同时在线的问题；一个拥有100万件商品网站的工程师，可能无法理解一个拥有10亿件商品网站的架构。
3) 救世主定律：遇到问题，分析问题，最后总能解决问题。如果遇到问题就急匆匆地从外面挖一个高手，然后指望高手如探囊取物般轻松搞定，最后怕是只有彼此抱怨和伤害。许多问题只是看起来一样，具体问题总是要具体对待的，没有银弹，没有救世主。所以这个定律准确地说应该是“没有救世主定律”。