平时经常会把前端浏览器的几种缓存方式拿来作比较，
cookie
localStorage
sessionStorage
直接上一张图，一目了然
这次主要来说说cookie和session的区别
cookie
cookie可以在前后端进行用户的身份认证，标记用户。说到为什么要使用cookie，那得说到http。话说，http是一种无状态的协议，它的无状态可以用翻脸不认人（浏览器）来表示了；以至于服务器不会记得前一秒是哪个客户端向它发出了请求，这就会导致一种情况出现：小熊登录了淘宝；跳转一下页面，需要再登录；加入购物车，需要再登录；付款需要在登陆……想想真是太糟糕，用户体验极差，不能好好玩耍了。
在服务端的解决办法是：用session去管理cookie。
session
session为何物？
session是由cookie进行标记的。当需要记住用户时，比如前面说的登录，在服务端会设置一个响应头Set-Cookie，返回给客户端，例如：Set-Cookie:SESSIONID=12345678；客户端接收到这个响应后，此后发送的每一个请求浏览器都会自动带上Cookie请求头，对应内容是Cookie:SESSIONID=12345678。在服务端内存中存有session，将客户端发送的请求中的cookie值与内存中的session进行对比，就可以识别这个客户端了，也就能避免上图中那种尴尬的情况。
但是这又会引发新的问题。
如果用session在服务端进行存储，会出现的情况是，在一个处理淘宝业务的服务器集群中，不同的服务器被分配处理的业务不同，他们都处于淘宝这个大域名下，每台服务器的内存中都保留着一份同样的session，这就涉及到服务器之间session的复制。如若有100台服务器，每台服务器都有着同样的session，那么session所占用的内存之多可以想象。服务器既要处理业务，还得维护session的同步，如此一来，服务器无法通过增加业务的方式进行扩张，不易进行横向扩展。
解决办法：将有状态的服务转化为无状态的服务
（1）共享session
将session提取出来，集中存放（有点像开辟了一个session数据库的赶脚。。）
（2）token
服务是不需要进行存储，服务可以通过解析token里面的信息来判断是否登陆。token 里面是可以携带cookie解析出来的信息的。这种情况下，去掉了服务器存储的负担，只需要每次在服务端对token增加一个校验就可以了。
在学习session这块的同时，注意到，在高并发情况下，集群中服务器的分布是可以加以设计和优化的。就拿双十一的淘宝，同时那么多人访问，仍旧坚挺着，这是为什么？当业务量巨大的时候，同一个域名底下可以有一堆服务器处理大量复杂的业务，防止网站崩溃；这个时候就需要进行负载均衡的设计了
不学不知道，一学吓一跳。。。快快去看看负载均衡是个啥大人物，后续再总结咯。