负载均衡技术

用户请求发送给负载均衡机器，负载均衡机器再讲请求转发给实际的业务处理机器。

转发时涉及的问题是如何选择实际的业务处理机器：

1.随机选择：从地址列表中随机选择一台，在实际运行中，如业务处理机器在处理各种请求时所需消耗的资源相差不是特别大。

2.Hash选择：对应用层的请求信息做hash,从而分派到相应的机器上

典型的应用场景：静态图片的加载。对请求的图片url串做hash,这样可以保证每次请求的是同一台机器，命中缓存，提升性能。

由于要读网络协议应用层信息，又要做hash，因此消耗更多CPU资源并导致性能下降。

3.Round-Robin选择：根据地址列表按顺序选择。

4.按权重选择：根据每个地址的权重进行选择，分为静态权重和动态权重。

静态权重是指配置好集群中各个机器的权重，当集群中机器档次不同时，可以给配置高的机器分配更高的权重，更好利用机器性能。

对于权重相同的多台机器，通常支持随机或顺序选择。适用于仅按机器配置来分配机器承担的请求比例的业务场景。

动态权重是指根据处理机器的load,连接数等动态权重分配任务适用于根据运行状态分配承担请求比例的业务场景。

5.按负载选择：根据实际业务处理机器的负载来选择。选择负载相对较低的机器来进行处理，尽可能保证所有业务处理机器的负载时均衡的。这要求负载均衡机器每隔一段时间就向实际的业务处理机器搜集其负载情况，这种会给负载均衡机器增加负担，并且一旦搜集负载过程中出现较大延时或搜集不到时，很可能造成更严重的负载不均衡。

6.按连接数选择：根据实际业务处理机器的连接数多少进行选择，选择连接数较少的机器处理业务。

特别注意下面场景：若重启1台，瞬间大量请求会同时发到新启动的这台机器上，很可能造成宕机。

除了以上方式，还支持按Cookie信息绑定访问相同机器的方式。只用把相关用户信息缓存在各自机器上，避免引入分布式缓存技术。

出现的问题：一旦机器出现故障，在该机器上登录过的用户就要重新登录。

WEB站点负载均衡机器问题：如果webServer前面的请求处理缓慢，排在队列中的请求就要等待很久，但此时负载均衡设备仍然是根据顺序选址的话，就会造成有些请求被丢弃或超时。

使用UNICORN来解决。当用户访问twitter.com时，都在同一地方排队等待请求的执行，当Server的处理队列空闲时，请求将分派给该Server执行。

为了保证方位时跳过出问题的机器，通常采用的方法是负载均衡机器定时和实际业务处理机器进行心跳（ping,端口检测或是url侦测），发现心跳失败的机器从地址列表中移除，在心跳成功后再重新加入可用地址列表。

响应返回方式：

1.响应通过负载均衡机器返回：

主要问题：请求包和响应包都要经过负载均衡机器。随着需求量上涨，负载均衡机器所承受的压力会急速上升，尤其对于请求包小，响应包大的web应用。

基于NAT（Network Address Translation，网络地址转换）

流程：

请求-》负载均衡机器-》选择一台实际业务处理机器，将报文目标地址和端口改为实际处理机器的IP和端口-》发送实际机器-》响应返回到负载均衡机器-》将报文改为负载均衡机器的VIP地址和端口。

2.响应直接返回至请求发起方：

响应直接返回至请求发起方可将请求包和响应包分开处理，以分散负载均衡机器的压力，使负载均衡机器可支撑更大的请求量。

IP Tunneling：请求-》负载均衡-》请求的IP报文封装成另一个IP报文-》实际业务处理机器-》将报文解开获得目标地址为VIP的报文，根据路由表将响应直接返回至请求方。

要求负载均衡机器和实际业务处理机器的OS都支持IP Tunneling,并将VIP地址同时配置在实际业务处理机器的IP隧道设备上。

DirectRouting:请求-》负载均衡机器-》数据帧的MAC地址修改为业务处理机器的MAC地址-》实际业务处理机器-》获取IP报文，发现目标地址VIP配置在本地网络设备，根据路由表将响应报文直接返回给用户。

要求负载均衡机器和实际的业务处理机器在同一个物理网段，并且不响应ARP

软件负载均衡方案：

LVS+Keepalived实现负载均衡机器的自动接管

Keepalived基于VRRP协议实现，由一个master路由器和多个Backup的路由器构成VRRP虚拟路由器，Master会改变，Master的VRRP路由器每隔一段时间发送广播包，当BackUp路由器在连续三周期内收不到广播包，即认为MasterVRRP路由器出现问题或收到优先级为0的广播包，所有的备份路由器都发送VRRP广播声称自己是Master并将虚拟IP增加到当前机器上。

备份路由器先比较优先级，低的重置为Backup，若优先级相等，比较IP地址，IP值小的重置为BackUp.

问题：依靠广播信息来确认是否健康，如网络异常，可能出现多个master的现象。

避免故障传播的现象：配置多个不同的VIP方法，各个系统通过域名访问，通过DNS等方法使域名根据同的系统解析为不同的VIP。

对于不同功能消耗资源比重不同，

1.将获取和发布的系统拆分为两个系统，并分开部署

2.为两个功能配置两个VIP，可以配置路由策略，基于功能划分到不同VIP。

Cassandra基于Gossip实现无中心的NoSql数据库，无中间点后可以将路由策略放在访问端。

热备

真正对外服务的机器只有一台，其他机器处于standBy状态，通过心跳机制检查对外服务器的健康状况，当出现问题时，其中一台standBy机器进行接管，机器间的状态同步至其他standby机器或写入一个集中存储设备。

访问量及数据量不断上涨的应对策略：

拆分数据库按业务来进行，eBay将数据库拆分为用户，交易，商品，评价等，缺点是跨库操作比较麻烦

拆分表通常是对业务中数据量大的表按照一定规则来拆分，如按照时间，hash算法等，缺点是跨表操作麻烦

读写分离适用于读写比例高，对实时性要求不高的应用。技术上的挑战是如何快速地完成数据从写库复制到其他库。

垂直伸缩：通过升级或增加单台机器来撑访问量及数据量增长的问题。

1。增加CPU，问题：锁竞争激烈，用于支撑并发请求的线程数是固定的，单线程任务

2.增加内存：cache的集合大小是固定的，JVM堆内存是固定的

水平伸缩：通过增加机器来支撑

系统运行时通常存在一些状态，例如用户登录状态。业界一般采用NA体系来构建无状态应用。

SNA架构采用的方法：将所有状态的部分集中放入缓存或数据库中，通常数据库采用集中存储的方法。

1.广播同步：用户登录A后，广播到B和C。

方法：JGroups,Jetty和Tomcat的Http Session信息同步

2.分布式缓存：登录A后将用户信息存储到分布式缓存集群的某台机器上，当用户访问其他功能进入B机器，B机器从集群的机器中寻找用户登录信息。

最简单的方法：对用户ID进行hash，并用此hash值与缓存机器总数进行取模。

缺点：当分布式缓存集群的机器增减时可能会出现大量缓存失效的现象。

解决方法：一致hash

框架：memcached

缺点：每个key的数据在memcached集群中保存一份。

FaceBook采用的方法为构建多个memcached集群，将key进行冗余存储。

文件的水平伸缩方法：

1.直连式存储：各系统直接与一个集中的存储设备连接从而进行文件读取。

缺点：存储文件多性能下降，成本增加。

2。网络存储：NAS+SAN

3.分布式文件系统：GFS

应用水平伸缩的方法：

将功能拆分成各个子系统

问题：数据库连接池的增加

解决方法：

1.缓存：采用多种缓存尽可能的避免访问数据库。

页面静态化：新闻页面或网站的通告页面

页面片段缓存：ESI esi标签

数据缓存