架构 伸缩性

伸缩性指的是通过增加或减少机器的数量，来改变网站的处理能力。

负载均衡可以及时发现新上线或新下线的服务器，并向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。

 

应用服务器负载均衡

特点：应用服务器没有状态，访问哪一台都行

DNS负载均衡：   优点：不需要维护负载均衡服务器，有的DNS还支持基于地理位置的解析。

缺点：有缓存，下线某服务器后，即使修改了DNS，也需要一段时间才能生效，

功能较弱。

DNS通常作为第一级负载均衡，解析到负载均衡服务器上。

 

反向代理负载均衡：工作在应用层

缺点：性能可能成为瓶颈

 

IP负载均衡：工作在网络层，直接转发数据包

优点：在内核进程中转发，性能高

缺点：所有请求和响应都经过负载均衡服务器，性能成为瓶颈

 

数据链路层负载均衡：响应数据包不需要经过负载均衡服务器，可直接发给用户

是大型网站使用的最为广泛的负载均衡手段，

linux上最好的开源链路层负载均衡是LVS(Linux Virtual Server)

 

负载均衡算法

轮询（Round  Robin， RR）：依次分发，适用于所有服务器硬件都相同的场景。

加权轮询（WRR）：高性能的服务器分配的请求多。

随机：硬件配置不同，也可使用加权随机。

最少连接：记录服务器正在处理的连接数（请求数）。也可使用加权最少连接。

源地址散列：根据源IP进行Hash，可存储请求的上下文，实现会话粘滞。

 

缓存服务器

特点：新上线的服务器应尽量少的影响已存在的服务器

路由算法：

取余：服务器数量改变后，绝大部分请求都不会命中。

一致性哈希：一个长度为2^32的整数环(一致性hash环)，

节点名称和数据的key的哈希值都在0~2^32内，

将key存在顺时针最近的节点上。

优点：增加或删除一台服务器，只会影响另外一台服务器的命中情况。

缺点：负载可能会不均衡。解决办法：每个服务器虚拟为一组节点，

增加或删除一台服务器时，会均匀的影响到其他所有节点的一小部分数据。

一般虚拟为150.

 

数据服务器

关系型数据库的伸缩性设计：

主从读写分离，主库向从库复制

分库：不同业务的表部署在不同的集群上，不能进行join操作。

代理：根据规则，将sql分发到不同的数据库实例上执行

代理是无状态的，可以简单的使用负载均衡来实现集群伸缩

而mysql扩容后需要做数据迁移，具体迁移可以使用一致性hash算法。

迁移过程中会造成数据库的访问压力，以及一致性、可访问性等一系列问题。

迁移完成后，修改数据库代理的配置，即完成了mysql集群扩容。

代理不支持跨库join和跨库事务，程序应尽量避免join和事务操作。

 

关系型数据库设计约束强，海量数据处理能力差。