【干货分享】负载均衡之理论基础(一)

easthomeRT

现如今的业务场景下，我们对业务的可用性要求越来越高了，越来越难以接受系统的不在线，我们可以想象一样，我们作为用户，出现如下情形时会怎么样：

1、在电商网站买东西的时候，电商网站打不开；

2、网站可以打开，但是页面内容展示非常缓慢，难以忍受；

上面分别谈到了可用性和用户体验的问题，而且是以用户的角度，那么现在我们尝试着以业务提供方的角度分析一下，在出现以上情况时，可能会发生什么：

1、用户在购物时，网站无法打开，可能会造成用户访问中断，但是竞争对手的网站可以打开，此时用户将会在竞争对手的网站上成交，造成损失；

2、网站打开缓慢，造成用户无法忍受，这将会带来企业形象的损失；

现如今互联网世界中，用户的体验是第一位的，最基本的一点是在用户需要的时候，系统必须可用，通常的做法是讲网站或系统部署到多台服务器上，并且随着压力的升高，服务器的台数也在增多，也就是说，部署更多内容一致的服务器，将用户的访问在多台服务器之间分发，实现横向扩展，或者水平扩展，当然，还有7层的负载均衡，服务器中的内容是不一致的，通过header等转发规则进行处理，此时我们先讨论第一种。

Nginx 可以轻松实现上述所说的请求分发，让后端的服务器进行横向扩展，且Nginx可以实现的负载均衡类型也很多，例如场景的Http、TCP、UDP等，当然，在实现Nginx负载均衡之前，我们还必须注意到一件事，一件很重要的事就是在实现了Nginx负载均衡之后，客户端的访问入口会发生变化，客户端所有的请求会先访问到Nginx提供的IP地址上，然后由Nginx再次转发到后端的某一台服务器上，这里我们要注意，由于后端服务器众多，可能会出现以下事件：

1、同一用户在网页上刷新后，Nginx服务器把此用户的流量分发到了另一台后端服务器上，刚才用户在网页上做的所有操作不被新服务器承认，需要重复操作；

2、用户在访问的过程中，由于各种意外，正在被访问的服务器故障，此时用户的请求可能会重新转移，那么用户的会话，cookie等状态数据怎么办？

这个时候我们就要谈一下场景的业务类型了，我们场景的业务类型分为有状态业务和无状态业务，例如常见的Web体系架构就是无状态的，当然，Http的会话也是很重要的，但是我们可以仔细盘剥一下，网页归网页，会话归会话，网页本身是无状态的，所以我们只需要保证会话的可用性和可靠性即可，那么我们是不是可以把会话放入共享内存中或者数据库中？当然可以，这也是一种较为主流的方式，例如会话存入Redis数据库，所以Nginx的后端服务器完全可以把会话和网页本身实现解耦合，来实现横向扩展，且Nginx在将请求分发给后端服务器之前，必须先探测一下后端服务器是否工作正常，如果正常才会将请求分发过去，那么刚才的两个问题中的第二个问题是不是就迎刃而解了？至于第一个问题，也是我们将会重点讨论的，此时我们必须在Nginx上具备会话的持久性，也就是常说的会话保持功能，用户的请求到Nginx之后，Nginx将请求分发到后端服务器，且会在一定时间内，记住用户和后端服务器的映射关系，在一定时间内，此用户的所有请求都会有同一个服务器进行处理，这就是会话保持功能。

总结一下，负载均衡的出现使得以下情况得以缓解

1、单台服务器能力有限，用户体验差；

2、单台服务器的可预见风险大，在故障时，将会造成用户的体验中断；

总的来说，负载均衡通过将业务部署到多台服务器上，在业务服务器前端提供统一的放入点，来进行流量的再次分发的形式，来提升了系统的负载能力。

下一篇我们重点以实验的方式来实现HTTP负载均衡、TCP 负载均衡、UDP负载均衡，且探讨其中的技术原理。

Rockyw

路过了解一下！