分布式web架构中对session同步的经常使用处理方法以及优缺点

写在前面

最近在读一原本自淘宝技术团队大牛的书，名字叫《大型网站系统与Java中间件实践》。开篇的章节详细地介绍了一个网站架构由小变大不断演进的过程，其中从单机架构升级到集群架构的过程当中着重介绍了关于session同步问题， 这也是不少人在聊到分布式时绕不过去的话题。下面就整理下书中的内容，也算是作个读书笔记，方便之后参考。

问题从哪来

作web开发的同窗应该对session再熟悉不过，它是服务器分配给客户端的会话标识，浏览器每次请求会带上这个标识来告诉服务器我是谁，服务器会在内存中存储这些不一样的会话信息，由此来分辨请求来自哪一个会话。在单机部署的环境总，由于web服务器和session都是在同一台机器上，因此必然能找到对应的会话数据。但若是有2台web服务器（A和B）提供服务，假如第一次请求落到A上并建立了session，那么如何保证下次落到B的请求能读到session数据？

解决方案

有如下4中常见的解决方案。

一、Session Sticky

这是最简单粗暴的 方法，核心思路就是让同一会话的请求都落地到同一台服务器上，这样处理起来就和单机同样了，咱们能够在负载均衡上作一些身份识别并控制转发来达到这个目的。这样作的优点是能像单机同样简化对session处理，也方便作本地缓存，但缺点也是很明显的：

• 若是这台服务器宕机或重启了，那么因此的会话数据都会丢失，失去了分布式集群带来的高可用特性。

• 增长了负载均衡器的负担，使它变得有状态了，并且资源消耗会更大，容易成为性能瓶颈。

二、Session Replication

顾名思义，这是一种session复制的方案，核心思路就是经过在服务器之间增长session同步机制来保证数据一致。

看起来比第一种简单了不少，也没有第一种带来的缺陷，但在某些应用场景下仍是会有比较严重的问题：

• 服务器之间的数据同步带来了额外的网络消耗，随着机器数量和数据量的上升，网络带宽将会有很大的压力，也必然会带来延时问题。

• 每台服务器上都要存储全部的会话数据，若是会话数量很大会占用服务器大部份内存空间。

目前不少应用容器都支持这种同步方式，因此在集群规模和数据量比较小的时候仍是一种很好的解决方案。

三、Session集中存储

这种方式的思路就是把全部的会话数据统一存储和管理，全部应用服务器须要对session进行读写都要经过session服务器来操做：

这种方案的好处是独立了session的管理，职责单一化，session服务器采用什么方式存储（内存、数据库、文档、NoSql等等），什么方式对外提供服务都是透明的。不会给应用系统和负载均衡带来额外的开销，不须要进行数据同步就能保证一致性，看起来应该是很是完美了，不过也有本身的一些小缺陷：

• 对session读写须要网络操做，相比较session直接存储在web服务器的时候增长了时延和不稳定性，好在session服务器和web服务器通常是部署在局域网中，能够最大化减小这个问题。

• session服务器出现问题将影响全部web服务，若是采用多机部署同时也会带来数据一致性问题。

每种方案带有它独特的优点，同时也会带来相应的新问题，正所谓没有十全十美，只有适合才是最好的。整体来讲，这种方案在应用服务器和会话数据量都很大的时候仍是很是有优点的。

四、Cookie Base

 这种方案是基于cookie的传输来实现的，核心思想很简单，就是把完整的会话数据通过处理后写入到客户端cookie，之后客户端每次请求都带上这个cookie，而后服务端经过解析cookie数据来获取会话信息，以下图所示：

这种方案简单明了，也没有前面几种方案带来的问题，但劣势也很是明显：

• 首先经过cookie来传递关键数据确定是不安全的，即使是采用了特殊的加密手段。

• 若是客户端禁用了cookie，将直接致使服务不可用。

• cookie的数据是有大小限制的，若是传递的数据超出限制大小，将会致使数据异常。

• 在http请求中携带大量的数据进行传输会增长网络负担，一样，服务端响应大量数据会致使请求变慢，并发量大的时候会很是可怕。

总结

以上4种方案都是可行的方案，正如前面所说，每种方案各有优劣，不会十全十美，实际应用中要根据需求作权衡和取舍。这些都是属于比较通用的方案，我相信在真正的实践和落地过程当中还会有其余问题出现，有经验的过来人或许会有一些另辟蹊径的“套路”，欢迎讨论交流。