从银行柜台小姐姐聊负载均衡中的会话粘滞
上回我们讲到了开盲盒，这次我们来处理一下昨天的遗留问题，关于最后提到的服务器优化，不知道你是否想到一些东西呢？如果没想到也没关系，我们先来聊聊银行业务员小姐姐那些事～
负载均衡 - 会话粘滞
同一个客户端的所有请求都路由到同一个服务器上，也就是会话粘滞（session sticky）的负载均衡算法。这玩意就像你去银行办理业务，银行柜台有一堆业务员小姐姐，她们都像是一个个的服务器，你来银行办理业务，表达自己的需求，你就是那个发送请求的客服端，有时候还不止办理一种业务，这时候就存在多个请求。刚开始那会银行业务不多，给每个小姐姐分配了一批客户，这时候你来银行办业务，只要去找那个给你分配好的小姐姐就可以了，是不是感觉还挺方便的。这就是保持映射关系。
放在系统中，最简单的方法就是在数据库创建一张映射表，维护会话ID和服务器的映射关系，客户端发出的每次请求，都要在映射表中查找需要路由的服务器编号，然后通过把请求发给对应编号的服务器上面，方法实现比较简单。
但是有两个问题：
- 维护映射表需要额外的空间，随着会话ID的越来越多，占用的空间也会越来越多；
- 服务器的下线和上线都会对映射表产生影响，这时候需要重新维护映射表的，维护成本比较大。你想啊，有一天，有个小姐姐突然回家结婚去了，这就会有一堆客户就失去了业务员，这时候为了提高客户的满意度，就要立马修复这个问题，免不了要重新调整一下客户和业务员的关系。
这时候是不是有什么更优雅的办法解决问题呢？
有一天银行，发现这样搞下去不行啊，于是引进了一台可以取号的机器，每个用户在处理业务之前，先去取个号，这个编号就是对应柜台业务员的编号，来了银行先取号，在你所有的业务处理完之前这个号码都是有效的。
这时候如果有业务员小姐姐暂停服务，处理起来就很简单了，让客户取不到这个号码就可以了，不再需要重新维护客户的业务员之间的关系。
系统中可以通过哈希算法，对客户端地址或者会话ID 计算哈希值，将取得的哈希值和服务器列表的数量进行取模运算，最终得到的值（也就是取号机发放的号码）就是应该被路由到的服务器编号。这样也可以保证同一个客户端过来的所有请求路由到同一个后端服务器上。
