一、问题的提出

1、为什么需要Cookie和Session？

用户使用网站的服务，需要使用浏览器与Web服务器进行多次交互。大家都知道，HTTP协议是无状态的，无状态啥意思？举个栗子

夏洛：大爷，楼上322住的是马冬梅家吧？
大爷：马都什么？
夏洛：马冬梅。
大爷：什么都没啊？
夏洛：马冬梅啊。
大爷：马什么没？
夏洛：行，大爷你先凉快着吧。

HTTP协议无状态导致的后果：服务器无法分辨是谁浏览了网页。

但是随着网络的发展，比如登陆、购物车等需求必须识别用户的身份才能进行下一步操作，先后出现了四种技术，分别是隐藏表单域、URL重写、cookie、session。

2、什么是cookie?

Cookie是浏览器保存在用户电脑上的一小段文本，用来保存用户在网站上的必要的信息。Web页面或服务器告诉浏览器按照一定的规范存储这些信息，并且在以后的所有请求中，这些信息就会自动加在http请求头中发送给服务器，服务器根据这些信息判断不同的用户。

Cookie和Session的工作原理以及分布式Session实现方案_分布式session

Cookie相当于服务器给每个客户端都贴上了一个小纸条，上面记录了服务器给我们返回的一些信息，然后服务器看到这张小纸条就知道我们是谁了。

 Cookie属性

Cookie和Session的工作原理以及分布式Session实现方案_分布式session_02

Cookie的产生

<?php
$value = 'sungeniubi';
setcookie("TestCookie", $value, time()+3600);  /* 1 小时过期  */
setcookie("TestCookie", $value, time()+3600, "/swh/", "example.com", 1);
?> 
//好大夫封装类HdfCookie
$cookie = new HdfCookie("haodf.com");                                    
$cookie->set("twiceVerityInfo[info]", "twice_".$this->userId, $liveTime);

cookie作用

Cookie主要用途：在客户端设置一些信息用于后续验证用户的登录状态。

Cookie和Session的工作原理以及分布式Session实现方案_分布式session_03

3、 什么是Session？

用户使用网站的服务，需要使用浏览器与Web服务器进行多次交互。HTTP协议本身是无状态的，需要基于HTTP协议支持会话状态（Session State）的机制。具体的实现方式是：在会话开始时，分配一个 唯一的会话标识（SessionID），并通过Cookie将这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识SessionID来告诉Web服务器这个请求是属于哪个会话的。在Web服务器上，各个会话都有独立的存储，保存不同会话的信息。如果遇到禁用Cookie的情况，一般的做法就是把这个会话标识放到URL的参数中。

Cookie和Session的工作原理以及分布式Session实现方案_一致性hash_04

5、 什么是Session一致性问题？

当Web服务器从一台变为多台时，就会出现Session一致性问题。

Cookie和Session的工作原理以及分布式Session实现方案_一致性hash_05

当一个带有会话标识的HTTP请求到了Web服务器后，需要在HTTP请求的处理过程中找到对应的会话数据（Session）。但是，现在存在的问题就是：如果我第一次访问网站时请求落到了左边的服务器，那么我的Session就创建在左边的服务器上了，如果我们不做处理，就不能保证接下来的请求每次都落在同一边的服务器上了。这就是Session一致性问题。

二、Session一致性解决方案

1、Session Stiky

在单机的情况下，会话保存在单机上，请求也是由这个机器处理，因此不会有问题。当Web服务器变为多台以后，如果保证同一个会话的请求都在同一个Web服务器上处理，则对该会话来说，与之前单机的情况是一样的。

如果要做到这样，就需要负载均衡器能够根据每次请求的会话标识SessionID来进行请求转发，如下图所示。这种方式称之为Session Stiky方式。

Cookie和Session的工作原理以及分布式Session实现方案_工作原理_06

该方案本身非常简单，对于Web服务器来说，该方案和单机的情况是一样的，只是我们在负载均衡器上做了手脚。这个方案可以让同样Session的请求每次都发送到同一个Web服务器来处理，非常利于针对Session进行服务端本地的缓存。

反向代理层让同一个用户的请求保证落在一台server上呢？

  • 方法一：四层代理hash。反向代理层使用用户ip来做hash，以保证同一个ip的请求落在同一个server上（更推荐，保证传输层不引入业务层的逻辑）

  • 方法二：七层代理hash。反向代理使用http协议中的某些业务属性来做hash，例如sid，city_id，user_id等，能够更加灵活的实施hash策略，以保证同一个浏览器用户的请求落在同一个server上

其所存在的问题包括：

  • 如果有一台Web服务器宕机或者重启，则该机器上的会话数据就会丢失。如果会话中有登录状态数据，则用户需要重新登陆。

  • 会话标识是应用层的信息，则负载均衡器要将同一个会话的请求都保存到同一个Web服务器上的话，就需要进行应用层（七层）的解析，这个开销比第四层的交换要大。

  • 负载均衡器变为了一个有状态的节点，要将会话保存到具体Web服务器的映射，因此内存消耗会更大，容灾会更麻烦。

打个比方来说，对于Session Stiky，如果说Web服务器是我们每次吃饭的饭店，会话数据就是我们吃饭用的碗筷。要保证每次吃饭都用自己的碗筷，我就把餐具存在某一家，并且每次都去这家店吃，这是个不错的主意。

2. Session Replication

如果我们继续以去饭店吃饭类比，那么除了前面的方式之外，如果我在每个店都存放一套自己的餐具，就可以更加自由地选择饭店。Session Replication就是这样一种方式，如下图所示。

Cookie和Session的工作原理以及分布式Session实现方案_工作原理_07

可以看到，在Session Replication方中，不再要求负载均衡器来保证同一个会话地多次请求必须到同一个Web服务器上了。而我们的Web服务器之间则增加了会话数据的同步。通过同步就保证了不同Web服务器之间的Session数据的一致。

但是，Session Replication方案也存在一些问题，包括：

  • 同步Session数据造成了网络带宽的开销。只要Session数据有变化，就需要将数据同步到其他所有机器上，机器数越多，同步带来的网络带宽开销就越大。

  • 每台Web服务器都要保存所有的Session数据，如果整个集群的Session数很多的话，每台机器用于保存Session数据的内容占用会很严重。

这就是Session Replication方案。这个方案是靠应用容器来完成Session的复制从而使得应用解决Session问题的，应用本身并不关心这个事情。不过，这个方案并不适合集群机器数多的场景。如果只有几台机器，用该方案是可以的。

3. Session数据集中存储

同样是希望同一个会话的请求可以发到不同的Web服务器上，前面的Session Replication是一种方案，还有一种方案就是把Session数据集中存储起来，然后不同Web服务器从同样的地方来获取Session。其大概的结构如下图所示：

Cookie和Session的工作原理以及分布式Session实现方案_一致性hash_08

可以看到，与Session Replication方案一样的部分是，会话请求经过负载均衡器后，不会被固定在同样的Web服务器上。不同的地方是，Web服务器之间没有Session数据复制，并且Session数据也不是保存在本机了，而是放在了另一个集中存储的地方。这样，无论是哪台Web服务器，也无论修改的是哪个Session的数据，最终的修改都发生在这个集中存储的地方，而Web服务器使用Session数据时，也是从这个集中存储Session数据的地方来读取。对于Session数据存储的具体方式，可以使用数据库，也可以使用其他分布式存储系统。这个方案解决了Session Replication方案中内存的问题，而对于网络带宽，该方案也比Session Replication要好。

不过，该方案仍存在一些问题，包括：

  • 读写Session数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，不过由于通信基本发生在内网，问题不大。

  • 如果集中存储Session的机器或者集群存在问题，这就会影响我们的应用。

相对于Session Replication，当Web服务器数量比较大时、Session数比较多的时候，集中存储方案的优势是非常明显的。

4. Cookie Based

对于Cookie Based方案，它对同一个会话的不同请求也是不限制具体处理机器的。与Session Replication和Session数据集中管理的方案不同，这个方案是通过Cookie来传递Session数据的。具体如下图所示。

Cookie和Session的工作原理以及分布式Session实现方案_一致性hash_09

可以看出，我们的Session数据存放在Cookie中，然后在Web服务器上从Cookie中生成对应的Session数据。这就好比我每次都把自己的碗筷带在身上，这样我去哪家饭店吃饭就可以随意选择了。相对于前面的集中存储，这个方案不会依赖外部的一个存储系统，也就不存在从外部系统获取、写入Session数据的网络时延和不稳定性了。

不过，该方案依然存在不足，包括：

  • Cookie长度限制。由于Cookie是有长度限制的，这也会限制Session数据的长度。

  • 安全性。Session数据本来都是服务器端数据，而这个方案是让这些服务端数据到了外部外部网络及客户端，因此存在安全性的问题。

  • 带宽消耗。这里指的不是内部Web服务器之间的带宽的消耗，而是我们数据中心的整体外部贷款的消耗。

  • 性能消耗。每次HTTP请求和响应都带有Session数据，对Web服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求就会越多。

三、总结

Cookie主要存储在客户端用于验证用户身份和登录信息。

web层、service层无状态是大规模分布式系统设计原则之一，session属于状态，不宜放在web层

让专业的软件做专业的事情，web-server存session？还是让cache去做这样的事情吧。

综合而言，上述所有方案都是解决session问题的方案，对于大型网站来说，Session Sticky和Session集中管理是比较好的方案。