分布式session的几个问题
高并发下分布式Session需解决的问题：
透明处理存储介质的故障转移
动态增删节点，减小“缓存颠簸”问题
保证数据在各个节点的分布均衡
Session 序列化和反序列化
Sticky Sessions：粘性会话。即同一个会话中的请求必须被转发到同一个节点上，除非该节点宕机才转发到故障转移节点。一个节点宕机，所存储的 Sessions 完全丢失。通俗的话就是，将用户“粘”在某一个服务器节点上。
Non-Sticky Sessions：非粘性会话。每一次请求都可能转发到不同节点。
Replicated Sessions：把一个节点上的 Sessions 复制到集群的其他节点上，防止数据丢失，允许失效无缝转移。如node 0复制到node 5，node 1复制到node 6，以此类推。多数应用服务器（如 Tomcat ）都支持会话复制机制。
支持 sticky sessions 和 non-ticky sessions 模式。
没有单点故障。
能处理 tomcat 故障转移
能处理 memcache 故障转移
pluggable session serialization
允许异步存储 session，提高响应速度
sessions 只有真正被修改时，才会发给 memcache
三.保证“基本可用 Basically Available”的分布式Session方案：
Eric A. Brewer 在 1988 年提出的 BASE 策略，即 Basically Available、Soft state、和Eventually consistent。
互联网大多数应用更强调可用性，即牺牲高一致性，获得可用性或可靠性。
基本可用 Basically Available 的定义：
在分布式系统部分损坏的时候，允许部分内容不可用，但是其他部分仍旧可用。因此称这种系统为“基本可用”。比如，一个数据存储系统由五个节点构成。其中一个发生了损坏，这时只有20%的数据不能访问，其他80%数据仍然可用。那么就可以称这种系统为基本可用的。
基于 memcache 的 Hash取模算法（hash() mod n，hash() 取用户ID，n为节点数） 实现的分布式 Session 方案，就属于基本可用：
第一，如果节点发生故障，该节点上的所有用户 Session 丢失，系统无法自恢复。
第二，如果系统压力突然增大，需要临时增加机器节点。按照 Hash取模的算法，在增加机器节点的这一时刻，大量缓存无法命中（其实还都存在之前的节点上），导致大范围的缓存穿透，压力会直接打到数据库上。
第三，根据 LRU 缓存失效算法，memcache 里存储的 key/value 有可能被踢出，用户 Session 容易丢失。
针对 Hash取模 的改进办法是：
四.基于一致性哈希算法的 memcache 解决方案
1）一致性哈希帮我们解决的是，当机器节点减少时，缓存数据能进行最少重建。
2）还能解决 Session 数据的分布均衡问题。
3）当机器节点宕机，这部分数据必然丢失。由于节点数目变化，有可能对部分没有丢失的数据也要重建。
但上面的方案都解决不了“一个节点失败后，它所存储的 Session 如何由其他节点获取以便接替失效节点，实现集群的容错（Failover）”。
郑昀先介绍下面几个概念：
五.Sticky Session、Non-sticky Session和Replicated Sessions
当用户数量和集群数量达到一定规模后，Session 复制就可能成为性能瓶颈。于是人们提出了 从第三方缓存恢复失效节点数据 的方案，开源产品 Memcached-Session-Manager（下面简称MSM）就是基于这个思想。
六.MSM的工作原理
MSM 支持 Tomcat 6 和 7，即它主要解决的是 Tomcat 的高可用性。
它的特性为：
启帆信息
2024-11-19 广告
