图10
什么鬼，裤子我都脱了，你就给我看这个?普通用户可能不会觉得有什么问题，重新登陆一次就是了。但小明作为一只严谨的程序猿，他想弄明白其中到底发生了什么。
经过仔细的查阅资料分析，小明得出了以下结论：
发生以上故障，小明以为自己下单的那台服务挂机了，请求被分发到另一台服务上，但为什么会跳到登陆页面呢?作为一名程序员，小明清楚的知道服务分为有状态和无状态的，尽管我们平时的HTTP请求是无状态的，但是一般会通过cookie或者session来确定用户状态。
到这里，各位看官应该明白到底是个什么鬼了吧。就拿我们比较熟悉的Tomcat来说，我们的用户信息一般存储在session中，而session存储在Tomcat内存中。浏览器通过cookie中的JSESSIONID来与服务器进行认证。
然而服务器挂了，下单请求被分发到另一台服务，自然小明再也找不到他的session了。
小明同学把问题反馈给了TT猫，小马哥一看这还得了，集群都做了还差这点，于是赶紧叫工程师们拿出解决方案。
工程师最终提出了两种方案：
服务器用户状态复制(成本大，需要软硬件支持，有延迟，存在失败的风险)
统一存储用户状态(我不说话，我就笑笑)
图11
最终，工程师们采用第二种方案，使用Redis存储用户状态数据。
知识补充
最近接触并使用了阿里云的负载均衡SLB ，大体了解了一下TT猫的负载均衡实现，以下架构实现源于TT猫。
负载均衡采用集群部署，可实现会话同步，以消除服务器单点故障，提升冗余，保证服务的稳定性。阿里云当前提供四层(TCP协议和UDP协议)和七层(HTTP和HTTPS协议)的负载均衡服务。
四层采用开源软件LVS(Linux Virtual Server) keepalived的方式实现负载均衡。
七层采用Tengine实现负载均衡。
图12
如下图所示，各个地域的四层负载均衡实际上是由多台LVS机器部署成一个LVS集群来运行的。采用集群部署模式极大地保证了异常情况下负载均衡服务的可用性、稳定性与可扩展性。
图13
LVS集群内的每台LVS都会进行会话，通过组播报文同步到该集群内的其它LVS机器上，从而实现LVS集群内各台机器间的会话同步。如下图所示，当客户端向服务端传输三个数据包后，在LVS1上建立的会话A开始同步到其它LVS机器上。图中实线表示现有的连接，图中虚线表示当LVS1出现故障或进行维护时，这部分流量会走到一台可以正常运行的机器LVS2上。因而负载均衡集群支持热升级，并且在机器故障和集群维护时最大程度对用户透明，不影响用户业务。
