什么是负载均衡中的Sticky会话？它是如何工作的？

什么是会话保持（粘滞会话）

会话保持，有时又称粘滞会话（Sticky Sessions），是负载均衡领域设计需要着力解决的重要问题之一，会话保持是指在负载均衡器上的一种机制，在完成负载均衡任务的同时，还负责一系列相关联的访问请求会被分配到一台服务器上，当用户向服务器发起请求，服务器创建一个session，并把session id以cookie的形式写回给客户，只要客户的浏览器不关，再去访问服务器时，访问请求会自动附上session id去，服务器端检测到这个session id后，就会使用内存中维持的与这个id对应的session为客户端服务。

会话保持的使用场景

电子商务网站：从完成用户身份认证到浏览店铺、选择心仪商品加入购物车，一直到最后下单完成支付，需要经过很多次和服务器的交互过程才能完成整个交易，由于这几次交互过程从顺序上和逻辑上是密切相关的，服务器在进行这些交互过程的某一个交互步骤时需要一个上下文(Context)，即上一次交互过程的输出，因此要求这些相关的交互过程都由一台服务器完成。

在线系统：如银行系统、医疗系统等，用户在使用过程中需要保持登录状态，并且后续的操作都需要在前一次操作的基础上进行。

实现会话保持的方法

基于Cookie的会话保持

原理：负载均衡器负责插入Cookie，后端服务器无需作出任何修改，当客户端进行第一次请求时，客户端的HTTP Request（不带Cookie）进入负载均衡器，CLB根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器；后端服务器的HTTP Response（不带Cookie）被发回给负载均衡器，接下来负载均衡器将向该后端服务器插入Cookie并将HTTP Response返回到客户端，当客户端请求再次发生的时候，客户HTTP Request（带有上次负载均衡器插入的Cookie）进入CLB，然后CLB读出Cookie里的会话保持数值，将HTTP Request（带有与上面同样的Cookie）发到指定的服务器，后端服务器进行请求回复；由于服务器并不写入Cookie，HTTP Response将不带Cookie，该HTTP Response再次经过进入CLB时，将写入更新后的会话保持Cook。

优点：实现简单，只需要根据数据包的三四层的信息就可以实现，效率比较高。

缺点：如果客户端禁用了Cookie，则此方法无效；如果用户删除了Cookie，也会导致无法保持会话。

基于源地址的会话保持

原理：负载均衡器在做负载均衡的时候根据访问请求的源地址（IP地址）作为判断关联会话的依据，对来自同一IP地址的所有访问请求在做负载均衡的时候都会被转发到同一台服务器上去。

优点：实现简单，只需要根据数据包的三四层的信息就可以实现，效率比较高。

缺点：当多个客户端通过代理或地址转换的方式访问服务器时，由于来源地址一样，请求都被分配到同一台服务器上，就会导致服务器之间的负载严重失衡；同一个客户端上产生大量并发，要求分配到多个服务器上处理的同时进行会话保持，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。

共享会话的会话保持

数据库存放：Session信息存储到数据库表，以此来实现不同应该服务器之间Session信息的共享，这种方法适用于数据库访问量不大的网站，优点是实现简单，缺点是高并发性能差。

文件系统存放：通过文件系统（比如NFS）来实现各台服务器间的Session共享，此种方式适合并发量不大的网站，优点是各台服务器只需要mount存储Session的磁盘即可，实现较为简单，缺点是NFS对高并发读写的性能并不高，在磁盘I/O性能和网络带宽上存在较大瓶颈，尤其是对于Session这样的小文件的频繁读写操作。

内存存放：利用Memcached来存放Session数据，直接通过内存的方式读取，优点是效率高，在读写速度上会比存放在文件系统或数据库时快甚多，而且多个服务器公用Session也更加方便，将这些服务器都配置成使用同一组Memcached服务器就可以，减少了额外的工作量，缺点是一旦宕机，内存中的数据就会丢失，但是对Session数据来说并不是特别严重的问题，如果网站的访问量太大，Session太多的时候Memcached将会将不常用的部分删除，但是如果用户隔离了一段时间之后又重新使用，将会发生读取失败的问题，当然也可以使用Redis做Sesion的共享。

会话保持是负载均衡中的一个重要概念，旨在确保来自同一客户端的请求被转发到同一台服务器处理，以解决因负载均衡导致的会话丢失问题，根据应用环境的特点，我们可以选择适当的会话保持机制。

以上内容就是解答有关“负载均衡sticky”的详细内容了，我相信这篇文章可以为您解决一些疑惑，有任何问题欢迎留言反馈，谢谢阅读。