一、高并发下分布式Session需解决的问题:
1.透明处理存储介质的故障转移
2.动态增删节点,减小“缓存颠簸”问题
3.保证数据在各个节点的分布均衡
4.Session 序列化和反序列化
二、保证“基本可用 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 方案,就属于基本可用:
1.如果节点发生故障,该节点上的所有用户 Session 丢失,系统无法自恢复。
2.如果系统压力突然增大,需要临时增加机器节点。按照 Hash取模的算法,在增加机器节点的这一时刻,大量缓存无法命中(其实还都存在之前的节点上),导致大范围的缓存穿透,压力会直接打到数据库上。
3.根据 LRU 缓存失效算法,memcache 里存储的 key/value 有可能被踢出,用户 Session 容易丢失。
针对 Memcache的Hash取模 的改进办法是:
三、基于一致性哈希算法的Memcache解决方案
1.一致性哈希帮我们解决的是,当机器节点减少时,缓存数据能进行最少重建。
2.还能解决 Session 数据的分布均衡问题。
3.当机器节点宕机,这部分数据必然丢失。由于节点数目变化,有可能对部分没有丢失的数据也要重建。
但上面的方案都解决不了“一个节点失败后,它所存储的 Session 如何由其他节点获取以便接替失效节点,实现集群的容错(Failover)”。
先介绍下面几个概念:
四、Sticky Session、Non-sticky Session和Replicated Sessions
Sticky Sessions:粘性会话。即同一个会话中的请求必须被转发到同一个节点上,除非该节点宕机才转发到故障转移节点。一个节点宕机,所存储的 Sessions 完全丢失。通俗的话就是,将用户“粘”在某一个服务器节点上。
Non-Sticky Sessions:非粘性会话。每一次请求都可能转发到不同节点。
Replicated Sessions:把一个节点上的 Sessions 复制到集群的其他节点上,防止数据丢失,允许失效无缝转移。如node 0复制到node 5,node 1复制到node 6,以此类推。多数应用服务器(如 Tomcat )都支持会话复制机制。
解决session共享问题大体上有以下几种处理方式:
1、session复制,这种方式在大访问量下tomcat会挂掉
2、使用tomcat6以上自带的tcp组广播方式的集群,这种方式在我使用过程中发现有时会丢失session
3、使用数据库、缓存方式实现。
下一篇文章将介绍使用memcached存取Session的解决方案。