负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。
什么是负载均衡
负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。
常见的负载均衡方案
常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到，每一个下游都有多个上游调用，只需要做到，每一个上游都均匀访问每一个下游，就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”。
【客户端层->反向代理层】的负载均衡
【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。
【反向代理层->站点层】的负载均衡
【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：
1)请求轮询：和DNS轮询类似，请求依次路由到各个web-server
2)最少连接路由：哪个web-server的连接少，路由到哪个web-server
3)ip哈希：按照访问用户的ip哈希值来路由web-server，只要用户的ip分布是均匀的，请求理论上也是均匀的，ip哈希均衡方法可以做到，同一个用户的请求固定落到同一台web-server上，此策略适合有状态服务，例如session(58沈剑备注：可以这么做，但强烈不建议这么做，站点层无状态是分布式架构设计的基本原则之一，session最好放到数据层存储)
4)…
【站点层->服务层】的负载均衡
【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。
上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。
上一篇文章《RPC-client实现细节》中有详细的负载均衡、故障转移、超时处理的细节描述，欢迎点击link查阅，此处不再展开。
【数据层】的负载均衡
在数据量很大的情况下，由于数据层(db，cache)涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。
数据的均衡是指：水平切分后的每个服务(db，cache)，数据量是差不多的。
请求的均衡是指：水平切分后的每个服务(db，cache)，请求量是差不多的。
业内常见的水平切分方式有这么几种：
一、按照range水平切分
每一个数据服务，存储一定范围的数据，上图为例：
user0服务，存储uid范围1-1kw
user1服务，存储uid范围1kw-2kw
这个方案的好处是：
(1)规则简单，service只需判断一下uid范围就能路由到对应的存储服务
(2)数据均衡性较好
(3)比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务
不足是：
(1)请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大
二、按照id哈希水平切分
每一个数据服务，存储某个key值hash后的部分数据，上图为例：
user0服务，存储偶数uid数据
user1服务，存储奇数uid数据
这个方案的好处是：
(1)规则简单，service只需对uid进行hash能路由到对应的存储服务
(2)数据均衡性较好
(3)请求均匀性较好
不足是：
(1)不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移
总结
负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。
(1)【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的
(2)【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的
(3)【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的
(4)【数据层】的负载均衡，要考虑“数据的均衡”与“请求的均衡”两个点，常见的方式有“按照范围水平切分”与“hash水平切分”
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
负载均衡算法介绍：
轮询调度
以轮询的方式依次请求调度不同的服务器；实现时，一般为服务器带上权重；这样有两个好处：
- 针对服务器的性能差异可分配不同的负载；
- 当需要将某个结点剔除时，只需要将其权重设置为0即可；
优点：实现简单、高效；易水平扩展；
缺点：请求到目的结点的不确定，造成其无法适用于有写的场景（缓存，数据库写）
应用场景：数据库或应用服务层中只有读的场景；
随机方式
请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；
优点：实现简单、易水平扩展；
缺点：同Round Robin，无法用于有写的场景；
应用场景：数据库负载均衡，也是只有读的场景；
哈希：
根据key来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上；
优点：相同key一定落在同一个结点上，这样就可用于有写有读的缓存场景；
缺点：在某个结点故障后，会导致哈希键重新分布，造成命中率大幅度下降；
解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来；
应用场景：缓存，有读有写；
一致性哈希：
在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率；
如twemproxy中的ketama方案；
生产实现中还可以规划指定子key哈希，从而保证局部相似特征的键能分布在同一个服务器上；
优点：结点故障后命中率下降有限；
应用场景：缓存；
根据键的范围来负载：
根据键的范围来负载，前1亿个键都存放到第一个服务器，1~2亿在第二个结点；
优点：水平扩展容易，存储不够用时，加服务器存放后续新增数据；
缺点：负载不均；数据库的分布不均衡；（数据有冷热区分，一般最近注册的用户更加活跃，这样造成后续的服务器非常繁忙，而前期的结点空闲很多）
适用场景：数据库分片负载均衡；
根据键对服务器结点数取模来负载：
根据键对服务器结点数取模来负载；比如有4台服务器，key取模为0的落在第一个结点，1落在第二个结点上。
优点：数据冷热分布均衡，数据库结点负载均衡分布；
缺点：水平扩展较难；
适用场景：数据库分片负载均衡；
纯动态结点负载均衡：
根据CPU、IO、网络的处理能力来决策接下来的请求如何调度；
优点：充分利用服务器的资源，保证个结点上负载处理均衡；
缺点：实现起来复杂，真实使用较少；
不用主动负载均衡：
使用消息队列转为异步模型，将负载均衡的问题消灭
负载均衡是一种推模型，一直向你发数据，那么，将所有的用户请求发到消息队列中，所有的下游结点谁空闲，谁上来取数据处理；转为拉模型之后，消息了负载的问题；
优点：通过消息队列的缓冲，保护后端系统，请求剧增时不会冲垮后端服务器；
水平扩展容易，加入新结点后，直接取queue即可；
缺点：不具有实时性；
应用场景：不需要实时返回的场景；
比如，12036下订单后，立刻返回提示信息：您的订单进去排队了…等处理完毕后，再异步通知；