负载均衡之理论基础(一)

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

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负载均衡，且探讨其中的技术原理。

注意：本文早由东方瑞通讲师李晓辉老师发表于东方瑞通官网讲师原创专区，转载请注明出处。更多讲师精彩文章，点此链接查看~