前言
我们最开始学习的时候接触的集中式的系统
集中式很明显的优点就是开发测试运维会比较方便，不用为考虑复杂的分布式环境。但是随着client流量的激增,单Server的负载压力越来越大,最终就可能让整个服务瘫痪。
什么是负载均衡？
负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
给上述集中式系统简单拓展后的架构如下:
图中在client和server中添加一个load balancing组件，由该组件来负责将client的请求按一定规则分配到各个服务器，从而解决了单个server带来的性能瓶颈。
负载均衡的几种常用方式
接下来以Nginx为例来简单介绍一下七层（应用层）负载均衡
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
server 192.168.0.16；
}
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的
情况。
upstream backserver {
server 192.168.0.14 weight=3;
server 192.168.0.15 weight=5;
server 192.168.0.16 weight=2；
}
权重越大,被访问到的概率就越大,上面三台服务器分别占30%,50%,20%。
3、ip_hash
上述的方式存在一个问题就是说，无法保证同一个client两次访问server一定请求相同的机器，这样就会带来session丢失的问题，这样显然是不恰当的。（当然我们也可以采用共享内存的方式来解决session不一致的问题）
upstream backserver {
ip_hash;
server 192.168.0.14;
server 192.168.0.15;
server 192.168.0.16；
}
4、fair(第三方)
根据后端服务器的响应时间来分配请求，响应时间短的优先分配。但是该策略的均衡性也可能被复杂的网络环境所影响。
upstream backserver {
fair;
server 192.168.0.14;
server 192.168.0.15;
server 192.168.0.16；
}
5、url_hash(第三方)
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
server 192.168.0.16；
# consistent_hash $request_uri; 一致性哈希
hash $request_uri;
}
小结
在生产实践中如何选择合适的负载均衡算法就需要我们在下面三者间权衡
均衡性：是否能够将请求均匀的发送给后端
一致性：同一个key的请求，是否能落到同一台机器
容灾性：当部分后端机器挂掉时，是否能够正常工作
