3. 伸缩性
伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进面导致集群中大部分缓存数据都无法访问。需要改进缓存路由算法保证缓存数据的可访问性。
对于关系型数据库，虽然支持数据复制、主从热备等机制，从早但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
3.1 网站架构的伸缩性设计
3.1.1 不同功能进行物理分离实现伸缩
纵向分离（分层后分离）：将业务处理流程上的不同部分（网站具体产品、可复用业务模块、基础技术服务、数据库）分离部署
横向分离（业务分割后分离）：将不同的业务模块（如：网站前台、卖家后台、买家后台）分离部署
3.1.2 单一功能通过集群规模实现伸缩
3.2 应用服务器集群的伸缩性设计
3.2.1 HTTP重定向负载均衡
缺点：需要2次请求才能完成一次访问，性能较差; 重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限; 使用HTTP302响应码重定向，有可能使用搜索引擎判断为SEO作弊，降低搜索排名。 因此这种方案并不多见。
3.2.2 DNS域名解析负载均衡
优点：将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦; 许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样加快用户访问速度，改善性能。
缺点：DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的A记录，要使其生效也需要较长时间，此期间会导致访问失败;而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
3.2.3 反向代理负载均衡
缺点：反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。
通常总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部负载均衡服务器再进行负载均衡，将请求分发到真实的Web服务器上。
3.2.4 IP负载均衡 -- 在网络层通过修改请求目标地址进行负载均衡
3.2.5 数据链路层负载均衡 -- 是指在通信协议的数据链路层修改mac地址进行负载均衡
此方式是目前大型网站使用最广的一种负载均衡手段。在Linux平台上的开源产品是LVS（Linux Virtual Server）
3.2.6 负载均衡算法 -- 轮询、加权轮询、随机、最少连接、源地址散列
3.3 分布式缓存集群的伸缩性设计
3.3.1 Memcached
3.3.2 分布式缓存的一致性Hash算法
将一台缓存服务器虚拟成一组服务器节点（推荐分成150个），这样可以保证节点能均匀地分布于hash环，当加入一台新缓存服务器时，也能保证尽量分担多台缓存服务器的负载，而不会只分担某台缓存服务器的负载。
3.4 数据存储服务器集群的伸缩性设计
3.4.1 关系数据库集群的伸缩性设计
(1) 数据库主从复制
(2) 数据分库。不同库的表不能进行Join操作
(3) 对于数据量大的单表，还需进行分片，将一张拆开分别存储在多个数据库中。
目前比较成熟的支持数据分片的分布式关系数据库产品主要有开源的Amoeba和Cobar
3.4.2 NoSQL数据库的伸缩性设计