SNA架构的几种实现方式

参考资料:
Shared Nothing Architecture与PHP的童话
Shared Nothing Architecture

   以往集群架构都采用Session共享模式进行设计，而后PHP等方面提出了SNA架构，主张Session不共享。SNA架构思想，无论对企业应用还是大型互联网站，极大提高了web应用的吞吐量和性能。
   一般SNA架构以集成分布式Cache例如 memcached 的方案居多，此处姑且称为 Cache模式。


   我结合公司电信项目的情况，以及思考，总结另一种方案，供参考。
   SNA思想的关键就是每个集群内web server实例不互相共享session，Cache模式主张session数据都放到分布式缓存中，意味着，逻辑上集群内还是要共享session信息；这种考虑源于负载均衡时，同一个IP发来的两个请求，可能走到不同的 Web Server上。

   因此，只要同一IP的两个请求转发到同一个 Web  server实例，那么就可以不需要全局的 session信息缓存。
   1) 我所在的移动项目下，采用 F5硬件负载均衡器，使用IP记忆机制实现了这一点。因此，各 web server实例的session无需共享，仍然保存在自己的session内存中，节省了网络开销和Cache命中查找时间。
   F5很贵，因此对于网站一般负担不起，但可以采用软件负载来做到这一点。

   切分模式的SNA架构：
   2) IP Memory(IP记忆)：负载服务器记录 客户端IP -> ServerID 的关系，模拟F5；
   3) (Dispatch by Rule)按规则转发：IP记忆需要维护一张路由table， 因此，需要消耗一定内存，以及映射关系查找的时间；
      我们将客户端的所有IP看作一个集合 IP Set，按固定规则将其平均分配集群的server实例上去，这样就可以节省路由table的开销。 关键是分配算法，可以考虑的有：
      2.1) 简单数值法： IP各节加总 = X, 假定集群实例个数为 N，编号1-N， 那么每次请求选择的目标server id = X mod N。
      2.2) hash值法： 有的系统可能想基于 userid 进行请求分配， 那么可以采用 X = hashCode(userid), serverID = X mod N;
      具体情况下， 可以灵活选择使用那个数据项判断请求分配的逻辑。这个思想参考了  memcached 的集群管理思想。
   

   4) stickySession方式。
      一般apache等采用这种方式做负载均衡。但必须结合 jvmRoute。 第一次被分配的 web server必须返回一个 jvmRoute在response中，并由 apache 送到客户端浏览器，第二次请求发起时，request信息中将包含 JSESSIONID 和 对应的 jvmRoute， apache根据次找到对应的 server，完成 stickySession机制。


结论： 切分模式的SNA架构，基于规则进行请求转发，可以省去分布式Cache的使用，更进一步的提升系统吞吐量和响应性。

最近一直研究这个。

在这里学习了

用memcached存session
touch session有什么思路?

"极大提高了web应用的吞吐量和性能。"
PHP不了解，以J2EE项目为例子，这能提升性能么？Session共享，Session是在本地的啊，访问本地对象多快啊，分布式缓存有网络延迟啊，这是为什么小规模项目用分布式缓存做SSO性能会很不好，只有项目很大，大到这点性能上的损失远远不如部署新应用带来的便利更重要的时候，用memchace才会觉得划算吧，本质上是减低耦合，增强扩展性，看不出和性能有什么关系。

但是如果某台WebServer宕机怎么办，如何保证HA呢

我有点疑问，
1.在本机用什么方式保存session？用文件系统吗？这样效率怎样？
如果采用共享session的方法，可以保存在memcached中。php只负责存取，gc交给memcached做，这样性能是不错的。
如果用文件系统保存，php需要随机gc，而且文件系统的性能是不能和内存比的，就算是本地保存session，我也认为应该在本机安装memcached。

2.分配算法，有没有比较好的方法，能平衡的分布。考虑最近n分钟内的分布情况，再影响分布。


如果我没记错的话，nginx支持ip hash负载均衡，现在nginx的wiki上不去，，不会被gfw了吧。。。

刚查了一下f5，真的好贵。。。。哈哈

“简单数值法”和“hash值法”，感觉就是求余法啊。。。原理一样的，应该不能算两种吧，可能我钻牛角尖了。。。

memcached的分布式算法有两种，名字我起的，哈哈，别见怪

1.求余法
crc32(key) % memcached服务器数量
这种算法，当有一台服务器当机，会导致大量cache失效，这个算法太依赖服务器数量了

2.临近节点算法
假如：
服务器数量 3台
网络节点 2^32 = 12 (方便计算，假如的)

把网络节点12分配给3台memcached服务器

假如网络节点这样分配了
1-4 memcached1
5-8 memcached2
9-12 memcache3

计算键的crc32值，然后找到该值的下一个节点，这个节点就是要保存的服务器

当某台服务器当机后，只会导致本服务器区域的cache失效



谢谢，我刚知道sna，一直我都是共享session的

就提升而言，用 cookie + 伪SNA 应该更好。

对于web，大部分是匿名访问，少量是登录的。匿名情况可以全部用cookie做标示；对于登录session，在cookie内做标示并存储在数据库中一份。当请求访问到某一台server的时候，如果是匿名的按照匿名处理，如果是登录的从本地读取session(如: request.getSession(false))，如果不存在按照cookie标示从数据库读取，然后加载到内存中，供以后使用。

IP记忆还是hash算法都会损失可用性，为了性能降低高可用性很多时候是划不来的。就像google可以慢点，但是google肯定不允许宕机。

基于IP的分发方式有它的缺陷，因为在一个session中客户IP可能会发生变化。IP发生变化的原因可能有：
1. 用户网络的出口采用了基于地址池的NAT或者是防火墙
2. 用户网络的出口可能采用双链路连接方式，配置的负载策略可能会导致IP发生变化
3. 用户可能采用多PROXY切换工具
4. ...

总而言之，用户端的情况及其复杂，使用基于IP的分发策略是一个有缺陷的SNA实现方式。

HA如何实现