这里对负载均衡概念和nginx负载均衡实现方式做一个总结：
先说一下负载均衡的概念：
Load Balance负载均衡是用于解决一台机器(一个进程)无法解决所有请求而产生的一种算法。
我们知道单台服务器的性能是有上限的，当流量很大时，就需要使用多台服务器来共同提供服务，这就是所谓的集群。
负载均衡服务器，就是用来把经过它的流量，按照某种方法，分配到集群中的各台服务器上。
这样一来不仅可以承担更大的流量、降低服务的延迟，还可以避免单点故障造成服务不可用。
一般的反向代理服务器，都具备负载均衡的功能。负载均衡功能可以由硬件来提供，比如以前的F5设备。
也可以由软件来提供，LVS可以提供四层的负载均衡(利用IP和端口)，Haproxy和Nginx可以提供七层的负载均衡(利用应用层信息)。
像nginx可以使用负载均衡分配流量，ribbon为客户端提供负载均衡，dubbo服务调用里的负载均衡等等，很多地方都使用到了负载均衡。
使用负载均衡带来的好处很明显：
当集群里的1台或者多台服务器down的时候，剩余的没有down的服务器可以保证服务的继续使用
使用了更多的机器保证了机器的良性使用，不会由于某一高峰时刻导致系统cpu急剧上升
负载均衡有好几种实现策略，常见的有：
随机 (Random)
轮询 (RoundRobin)
一致性哈希 (ConsistentHash)
哈希 (Hash)
加权（Weighted）
Nginx目前提供的负载均衡模块：
ngx_http_upstream_round_robin，加权轮询，可均分请求，是默认的HTTP负载均衡算法，集成在框架中。
ngx_http_upstream_ip_hash_module，IP哈希，可保持会话。
ngx_http_upstream_least_conn_module，最少连接数，可均分连接。
ngx_http_upstream_hash_module，一致性哈希，可减少缓存数据的失效。
1、轮询
轮询即Round Robin，根据Nginx配置文件中的顺序，依次把客户端的Web请求分发到不同的后端服务器。
配置的例子如下：
http{
upstream sampleapp {
server <<dns entry or IP Address(optional with port)>>;
server <<another dns entry or IP Address(optional with port)>>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
}
}
上面只有1个DNS入口被插入到upstream节，即sampleapp，同样也在后面的proxy_pass节重新提到。
实例：
http {
upstream myservers{
server 134.56.56.4:8001;
server 134.56.56.4:8002;
server 134.56.52.4:8011;
server 134.56.52.4:8012;
}
server {
listen 80;
location / {
proxy_pass http://myservers;
}
}
}
2、最少连接
Web请求会被转发到连接数最少的服务器上。
们知道轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同。
这有个前提，就是每个请求所占用的后端时间要差不多，如果有些请求占用的时间很长，会导致其所在的后端
负载较高。在这种场景下，把请求转发给连接数较少的后端，能够达到更好的负载均衡效果，这就是least_conn算法。
least_conn算法很简单，首选遍历后端集群，比较每个后端的conns/weight，选取该值最小的后端。
如果有多个后端的conns/weight值同为最小的，那么对它们采用加权轮询算法。
配置的例子如下：
http{
upstream sampleapp {
least_conn;
server <<dns entry or IP Address(optional with port)>>;
server <<another dns entry or IP Address(optional with port)>>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
}
}
上面的例子只是在upstream节添加了least_conn配置。其它的配置同轮询配置。
3、IP地址哈希
前述的两种负载均衡方案中，同一客户端连续的Web请求可能会被分发到不同的后端服务器进行处理，因此如果涉及到会话Session，那么会话会比较复杂。
常见的是基于数据库的会话持久化。
要克服上面的难题，可以使用基于IP地址哈希的负载均衡方案。
这样的话，同一客户端连续的Web请求都会被分发到同一服务器进行处理。
ip_hash算法的原理很简单，根据请求所属的客户端IP计算得到一个数值，然后把请求发往该数值对应的后端。
所以同一个客户端的请求，都会发往同一台后端，除非该后端不可用了。ip_hash能够达到保持会话的效果。
ip_hash是基于round robin的，判断后端是否可用的方法是一样的。
第一步，根据客户端IP计算得到一个数值。
hash1 = (hash0 * 113 + addr[0]) % 6271;
hash2 = (hash1 * 113 + addr[1]) % 6271;
hash3 = (hash2 * 113 + addr[2]) % 6271;
hash3就是计算所得的数值，它只和初始数值hash0以及客户端的IP有关。
第二步，根据计算所得数值，找到对应的后端。
w = hash3 % total_weight;
while (w >= peer->weight) {
w -= peer->weight;
peer = peer->next;
p++;
}
total_weight为所有后端权重之和。遍历后端链表时，依次减去每个后端的权重，直到w小于某个后端的权重。
选定的后端在链表中的序号为p。因为total_weight和每个后端的weight都是固定的，所以如果hash3值相同，
则找到的后端相同。
配置的例子如下：
http{
upstream sampleapp {
ip_hash;
server <<dns entry or IP Address(optional with port)>>;
server <<another dns entry or IP Address(optional with port)>>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
}
}
上面的例子只是在upstream节添加了ip_hash配置。其它的配置同轮询配置。
4、基于权重的负载均衡
基于权重的负载均衡即Weighted Load Balancing，这种方式下，我们可以配置Nginx把请求更多地分发到高配置的后端服务器上，把相对较少的请求分发到低配服务器。
这就是所谓的加权轮询，看起来很简单，但是最早使用的加权轮询算法有个问题，就是7个请求对应的
后端序列是这样的：{ c, b, a, a, a, a, a }，会有5个连续的请求落在后端a上，分布不太均匀。
目前使用的加权轮询叫做平滑的加权轮询（smooth weighted round-robin balancing），它和前者的区别是：
每7个请求对应的后端序列为 { a, a, b, a, c, a, a }，转发给后端a的5个请求现在分散开来，不再是连续的。
配置的例子如下：
http{
upstream sampleapp {
server <<dns entry or IP Address(optional with port)>> weight=2;
server <<another dns entry or IP Address(optional with port)>>;
}
....
server{
listen 80;
...
location / {
proxy_pass http://sampleapp;
}
}
上面的例子在服务器地址和端口后weight=2的配置，这意味着，每接收到3个请求，前2个请求会被分发到第一个服务器，第3个请求会分发到第二个服务器，其它的配置同轮询配置。
还要说明一点，基于权重的负载均衡和基于IP地址哈希的负载均衡可以组合在一起使用。
关于多节点集群部署带来的session问题，我使用了缓存技术，缓存可以使用memcached，也可以使用redis。
由于srping-session 和spring-data-redis由很好的支持，所以我采用了redis解决session共享问题。