负载均衡

一般设计大体上是这样子的：

每一个下游都有多个上游调用

第一层：客户端层到反向代理层

一个域名，可以同时解析到多个IP上面，“DNS轮询”技术方案。

那怎么实现高可用呢？

如果这个时候某台nginx 坏掉了，那到这台的请求，就会都连接不上了

这个时候就用lvs+keepalived

 

lvs做负载均衡，keepalived做热起动（动主机挂掉时，备机顶上）

nginx用来做http的反向代理，能够upsteam实现http请求的多种方式的均衡转发。由于采用的是异步转发可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止。这可以最大程度的提高系统的请求成功率。

lvs采用的是同步请求转发的策略。这里说一下同步转发和异步转发的区别。同步转发是在lvs服务器接收到请求之后，立即redirect到一个后端服务器，由客户端直接和后端服务器建立连接。异步转发是nginx在保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果后，由nginx返回给客户端。

进一步来说：当做为负载均衡服务器的nginx和lvs处理相同的请求时，所有的请求和响应流量都会经过nginx；但是使用lvs时，仅请求流量经过lvs的网络，响应流量由后端服务器的网络返回。

也就是，当作为后端的服务器规模庞大时，nginx的网络带宽就成了一个巨大的瓶颈。

所有一般会用lvs+keepalived+nginx做负载均衡。

第二层：反向代理层到站点层

 

以php为例：nginx配置文件可以设置成：

upstream php {                               #定义定义php服务器池，权重都为1，相当于访问模式是轮询
        server 192.168.58.132:9000 weight=1;
        server 192.168.58.130:9000 weight=1;
       }
    server {
        listen       80;
        server_name  localhost;

        location ~ \.php$ {
            root           /var/www/html/webphp;   
            fastcgi_pass   php;                     #这里要修改为php服务器池，而不是单个服务器
            fastcgi_index  index.php;
            include        fastcgi.conf;
        }

　

修改nginx.conf，可以实现多种均衡策略：

(1) 请求轮询：和DNS轮询类似，请求依次路由到各个web-server；还可以配制权重，好的机器，权重配高一些，让更多的请求落在好的机器上面。

(2) 最少连接路由：哪个web-server的连接少，路由到哪个web-server；

(3) ip哈希：按照访问用户的ip哈希值来路由web-server，只要用户的ip分布是均匀的，请求理论上也是均匀的，ip哈希均衡方法可以做到，同一个用户的请求固定落到同一台web-server上，此策略可以解决session问题。

站点层一般要设计成无状态的，所以session最好放到数据层存储。

第三层：站点层到服务层

 

服务层，根据实际情况，有用时，才用。

上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。除了负载均衡，服务连接池还能够实现故障转移、超时处理、限流限速、ID串行化等诸多功能。

连接池的好处是：可以节约，创建连接和销毁连接的时间、和资源开销。

比如，大型团队、大项目，根据业务实际情况，会把相关的业务折分出来，举例：微信，可能会折分成：朋友圈服务、我的好友服务、消息服务，等，这样相当于业务解耦，各司其职，朋友圈的程序员就只要管朋友圈的业务。

比如调用数据库方面，DB层，可能会加cache，会有分库分表，这种情况，实现DB服务层，业务方通过RPC访问数据，就像调用一个本地函数一样，非常之爽，比如：User = UserService::GetUserById(uid);而不用管缓存、分库分表等非业务逻辑。

第四层：访问数据层

 

　　

 数据的均衡：水平切分

1、每一个数据服务，存储一定范围的数据：

• user0服务：存储uid范围1-1kw

• user1服务：存储uid范围1kw-2kw

这个方案的好处是：

• 规则简单，service只需判断一下uid范围就能路由到对应的存储服务

• 数据均衡性较好

• 比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务

请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大

2、按照id哈希水平切分

每一个数据服务，存储某个key值hash后的部分数据：

• user0服务：存储偶数uid数据

• user1服务：存储奇数uid数据

这个方案的好处是：

• 规则简单，service只需对uid进行hash能路由到对应的存储服务

• 数据均衡性较好

• 请求均匀性较好

不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移

前面一部分是一个整体

软件负载均衡：

1.TCP 层：LVS，HaProxy，Nginx

2.基于 HTTP 协议：Haproxy，Nginx，ATS（Apache Traffic Server），squid，varnish

3.基于 MySQL 协议：mysql-proxy