转载地址：http://toutiao.com/a6294758409293086977/  博主还是希望大家去原文地址看，博主下面写的也都在原文中有解释，嘿嘿，看人家比看我清晰多了

A、文件方式：这种方式，将文件作为一个map，当新增一个数据的时候，就在文件中增加类似这样的一条数据：angOwberup =>data={“user”:{“id”:1,”nickname”:”老王”}};expiry=”2016-10-0100:00:00″(当然，具体实现的时候有可能是用的二进制方式，而不是字符串)这种方式的好处，就是能够存储大量的用户session，使得这个session有效期可以比较长（比如：三个月用户不用登录）。不过这个方式也有对应的问题，就是文件操作比较麻烦。比如，有一个用户的session过期了，需要删掉这条记录，那这个文件就需要挪动或重写。

B、cache方式：有好多web端的逻辑服务器都采用这种方式。这种方式好处非常明显，就是实现起来非常简单。将所有数据放入到内存cache中。如果有失效，直接内存删除就可以了。不过带来的问题也很明显，当服务器重启以后，所有session都丢失了。或者当有大量用户登录（也有可能是遭受攻击），就会很快让cache被充满，然后大量session被LRU算法淘汰，造成session的大量失效，使得用户需要反复登录等操作。

C、cookie方式：这种方式是最偷懒的方式。就是我服务器任何数据都不存，我把你们所有的客户端当做我的存储器，我就需要做一个加密和解密操作。当然这种方式最大的好处就是实现极其简单（还有其他的好处，稍后再说），不过问题也是很明显的，就是客户端要记录大量信息，同时还要保证加密信息的安全。如果session里要存放大数据，这种方式就不是很适合了。除了上述说到的优缺点以外，A、B两种方式还有另外一个问题，就是当我有不止一台服务器的时候，不同服务器间的session数据共享就成问题了。一招制胜—详解分布式系统里session同步比如，最初我只有一台服务器1，他的session里记录了user-1和user-2的数据。这个时候，我需要增加一台服务器2。当nginx把用户的请求转发到服务器2的时候，他就傻眼了：用户带了一个jsession_id=angOwberup这个的cookie过来，而在他的session管理器里却找不到这样一个session数据。那该怎么办？！（苦！恼！啊！）因此，就出现了我们文章一开始提到的问题：在分布式系统里，用户session如何才能实现同步？3、session的同步有了上面的情况，我们就必须要去考虑，如何在多个服务器之间实现session同步这个操作。

常见的做法有以下几种，我们逐个来看看：

             A、进程间通信传递session数据。这是最容易想到的一个方法。我们在不同的server服务里开一个socket，然后用socket来将相互拥有的session数据进行传递。我记得多年以前tomcat就是采用这样的方式来做的（已经很久没用过tomcat了，不知道现在是否还在这样使用）。这种方式的好处很明显，就是原理简单明了；坏处也很明显，就是同步合并过程复杂，还容易造成同步延迟。比如，某个用户在server-1登录了，server-1存储了这个用户的session，当正准备将数据同步给server-2的时候，由于用户访问实在是太快（飞一般的速度），server-2还没收到server-1传来的session数据，用户访问就已经来了。这个时候，server-2就不能识别这个用户，造成用户需要再次登录。而且，当有成千上万台服务器的时候，session同步就是一个噩梦：每一个服务器都要将自己拥有的session广播给其他所有机器，而且还要随时进行，不能停歇…… （最后这些机器估计都是累死的）

            B、cookie存储方式。我们在上面讲到了一个很偷懒的方式，就是把session数据做加密，然后存储到cookie中。用户请求到了，就直接从cookie读取，然后做解密。这种方式真是把分布式思想发挥到了一个相当的高度。他把用户也当做分布式的一员，你要访问数据，那你就自己携带着他，每次到服务器的时候，我们的服务器就只负责解密……对于session里只存放小数据，并且加密做的比较好（防止碰撞做暴力破解）的系统来讲，这是一个比较好的选择。他实现超级简单，而且不用考虑数据的同步。不过如果要往session里存放大数据的情况就不是太好处理。或者安全性要求很高的系统，也不是太好的一个方式（数据有被破解的风险）。

C、cache集群或者数据库做session管理。我们也可以采用另外一种架构来解决session同步问题，那就是引入统一session接入点。一招制胜—详解分布式系统里session同步我们session放入到cache集群或者数据库中，每次请求的时候，都从他们中来获取。这样，所有的机器都能获取到最新的session数据。这种方案也是很多中大型网站采用的解决方案。他实现起来相对简单（利用cache集群或者主从数据库自身的管理来实现多机的互备），而且效率很高，安全性也不错。

            D、还有一种方式是从上面这种方式延展出来的，就是提供session服务。这个服务负责管理session，其他服务器每次从这个服务处获取session数据，从而达到数据的共享。一招制胜—详解分布式系统里session同步大家如果仔细观察一下baidu或者google，你做登录的时候，他们可能会让你跳到passport.baidu.com 或者accounts.google.com这两个域名之下。这两个就是他们用来做用户登录和类似session管理的一个地方（由于之前只呆过baidu，所以google并不是非常清楚）。当一个访问请求来的时候，server就从cookie里取类似session_id的东东，然后用这个东东去passport服务去请求用户的session数据。

           这种方式的好处就在于：A、可以非常方便的扩展用户登录的数量以及存储数据的大小。当时在x度的时候，N亿用户的session都在这个系统里进行管理；B、方便做性能优化。如果用cache集群的方案，如果cache有机器坏掉，那么就会造成一部分用户session失效；如果用数据库方案，如果量太大，有可能会出现性能问题。而这种方案在实现的时候，可以用cache和数据库结合的实现方式，保证高效和稳定。同时，针对一些接口，可以做性能的优化，提升查询效率；C、对外封闭，保证数据安全。这种方式还有一个好处，就是可以将加密算法、密钥等封闭在系统内部，对外只暴露接口，使得数据安全性更有保障。（涉及到用户信息的，都是隐私！）不过，这种方式也有自己的问题，就是运维相对更复杂，有可能需要专门的团队去管理这些系统。当然，除了上述的一些方式以外，还有其他的手段（比如，在入口nginx处对用户cookie做一致Hash，将某一用户分配到固定机器）。鉴于老王知识有限，且码字速度有限，就先介绍这些了，不知道你是否看懂了呢？总结一下：关于session同步，其实方案有很多，没有哪个方案是最好的，只有某一种方案是最适合你现在架构的。

原文链接：http://toutiao.com/a6294758409293086977/