高性能负载均衡
分类及架构
高性能集群的复杂度主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法，负载均衡不只是为了计算单元的负载达到均衡状态
负载均衡分类
DNS负载均衡
是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡
优点
简单、成本低：负载均衡工作交给DNS服务器处理，无须自己开发或者维护负载均衡设备
就近访问，提升访问速度：DNS解析时可以根据请求来源IP，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能
缺点
更新不及时：DNS缓存的时间比较长，修改DNS配置后，由于缓存的原因，还有很多用户会继续访问修改前的IP，这样的访问会失败
分配策略比较简单：DNS负载均衡支持的算法少；不能区分服务器差异，也无法感知后端服务器的状态
硬件负载均衡
通过单独的硬件设备来实现负载均衡功能。业界典型设备有F5和A10
优点
功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡
性能强大：可以支持100万以上的并发（软件一般能支持到10万级）
稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用，稳定性高。
支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙，防DDoS攻击等安全功能
缺点
价格昂贵
扩张能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制
软件负载均衡
通过负载均衡软件来实现负载均衡功能，常见的有Nginx和LVS，其中Nginx软件的7层负载均衡，LVS是Linux内核的4层负载均衡。4层和7层的区别在于协议和灵活性，nginx支持HTTP、E-mail协议；而LVS是4层负载均衡，和协议无关，几乎所有应用都可以做，例如，聊天，数据库等
优点
简单：无论是部署还是维护都比较简单
便宜：只要买个Linux服务器，装上软件即可
灵活：
4层和7层负载均衡可以根据业务进行选择；也可以根据业务进行比较方便的扩展，例如可以通过Nginx的插件来实现业务的定制化功能
缺点
性能一般，功能没有硬件负载均衡那么强大
一般不具备防火墙和防DDoS攻击等安全功能
算法
算法期望达到的目的分类
任务平分类
负载均衡系统将收到的任务平均分配给服务器进行处理，平均可以是绝对数量的平均，也可以是比率或者权重上的平均
负载均衡类
负载均衡系统根据服务器的负载来进行分配。负载值系统当前的压力，可以是cpu负载、连接数、IO使用率，网卡吞吐量等
性能最优类
负载均和系统根据任务中的某些关键信息进行Hash运算，将相同Hash值的请求分配给响应最快的服务器
Hash类
负载均衡系统将任务中的的某些关键信息进行Hash运算，将相同Hash值的请求分配到同一台服务器。常见的又源地址Hash、目标地址Hash、session ID Hash、用户ID Hash等
轮询
负载均衡系统收到请求后，按照顺序轮流分配到服务器上。轮询是最简单的一个策略，无须关注服务器本身的状态。只要服务器在运行，运行状态是不关注的
加权轮询
负载均衡系统根据服务器权重进行任务分配，这里的权重一般是根据硬件配置进行静态配置的，采用动态的方式会更加契合业务，但是复杂度也会更高
主要目的是解决不同服务器处理能力有差异的问题，但同样存在无法根据服务器状态的差异进行任务分配的问题
负载最低优先
负载均衡系统将任务分配给当前负载最低的服务器，这里的负载根据不同任务类型和业务场景，可以有不同的指标来衡量
不同的指标衡量
LVS这种4层网络负载设备，可以以“连接数”来判断服务器的状态，服务器连接数越大，表明服务器压力越大
nginx这种7层网络负载系统，可以以“HTTP请求数”来判断服务器状态
负载最低优先的算法解决来轮询算法中无法感知服务器状态的问题，由此带来的代价是复杂度增加很多
最少连接数优先的算法邀请负载均衡系统统计每个服务器当前建立的连接，其应用场景仅限于负载均衡接收的任何连接请求都会转给服务器进行处理，否则如果负载均衡系统和服务器之间是固定的连接池方式，就不适合采取
CPU负载最低优先的算法邀请负载均衡系统以某种方式收集每个服务器的CPU负载，而且要确定以多少时间间隔为标准，时间间隔太短容易造成波动，太长可能造成峰值来临时响应缓慢
负载最低优先算法基本上能够比较完美地解决轮询算法的缺点，因为采用这种算法后负载均衡算法需要感知服务器当前运行状态。但其代价是复杂度大幅上升，如果算法本身没有设计好，算法本身可能成为系统瓶颈。所以负载最低优先算法虽然效果看起来美好但实际上真正应用的场景反而没有轮询那么多
性能最优类
负载最低优先类算法是站在服务端的角度来进行分配的，性能最优优先算法是站在客户端的角度来进行分配的，优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的
性能最优优先类算法本质上也是感知类服务器的状态，只是通过响应时间这个外部标准来衡量服务器状态
存在问题复杂度都很高
需要收集和分析每个服务器每个任务的响应时间，在大量任务处理的场景下，这种收集和统计本身也会消耗较多的性能
为降低性能可采取采样方式统计，但复杂度进一步提升，因为要确定合适的采样率，采用太低导致结果不准确，太高性能消耗较大
无论是全部统计还是采样统计，都需要选择合适的周期，但也是一件比较复杂的事情
Hash类
负载均衡系统根据任务中的某些关键信息进行Hash运算，将相同Hash值的请求分配到同一台服务器上
源地址Hash
将来源同一个源IP地址的任务分配给同一个服务器处理，适用于存在事务，会话的业务。例如；当我们通过浏览器登陆时会生成一个会话信息，这个会话是临时的，浏览器关掉后就失效，但需要保证用户在会话存在期间，每次都能访问到同一个服务器。
ID Hash
将某个ID标识的业务分配到同一个服务器中进行处理，这里的ID一般是临时性数据的ID（如sessionId）用户每次访问到同一台服务器的目的