本文主要是介绍[转发] 负载均衡的服务器集群上如何进行缓存和会话数据的管理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
会话数据管理方法1. 不存储Session
对于一些不需要记录用户状态的Web应用，采用这种Stateless方式是最恰当的方式。
2. 基于Cookie的Session共享
这种策略也被称为客户端Session，即不将Session信息存储于服务器端，而是存储于客户端。这同时，也会带来一定的安全问题，因为Cookie是存储于客户端中的，也就意味着客户端可以修改Cookie文件，来进行Session劫持操作。安全性问题是这种策略最大的问题。
缺点：只能够存储字符串、数值等基本类型的数据；Cookie大小存在限制；安全性；带宽及数据解压缩、网络传输性能问题。
优点：节省服务器内存。
3. 集中式Session存储策略
集中式Session，顾名思义，将集群中所有用户机的Session都保存在同一台机器上（Session服务器）。
此时Session存储有如下集中方式：
1. Key/ValueStorage
一般，大型Web系统会采用Key/ValueStorage的方式存储Session。在这种存储方式的选择中，大多数的大型Web系统会选择memcached。
这种方式的优点在于:
多数的Key/Value Storage支持Object作为它的Key或者Value
多数的Key/Value Storage提供非常友好的API；
Key/Valuestorage速度一般都远高于关系型数据库，非常适合Session这种存取非常频繁的情况，例如memcached支持全内存的工作方式，速度非常快；
多数的Key/Value Storage支持良好的备份与恢复机制；
多数的Key/Value Storage支持集群工作的方式，此时Session的总量也就不再局限于单Session服务器的内存大小。
这种方式的缺点在于：
Key/ValueStorage部署有一定的复杂；
多数Key/Value Storage对于CPU与内存的消耗较多；
在使用这种方式时，需要注意以下几点：
Key/ValueStorage对Object（对象）大小的限制。很多Key/ValueStorage会对所存储的对象的大小有所限制，比如memcached中，默认配置下单个对象的最大大小为 1MB；
当与Session服务器的连接断开或者Session服务器宕机时的异常处理。
2. 基于数据库的Session共享，实现分布式应用间Session共享
优点：实现简单
缺点：由于数据库服务器相对于应用服务器更难扩展且资源更为宝贵，在高并发的Web应用中，最大的性能瓶颈通常在于数据库服务器。因此如果将 Session存储到数据库表，频繁的增加、删除、查询操作很容易造成数据库表争用及加锁，最终影响业务。
3. 基于内存的Session存储
在使用这种方式时，可以直接使用HashTable。至于为什么使用HashTable而非HashMap，原因非常简单HashTable是线程安全的，而且HashTable不支持null作为key或者value。HashTable中key可以用户名/用户ID，value为这个用户的Session。
这种方式的优点在于:
实现简单；
速度快。这种方式无疑是这三种方式中最为快速的；
这种方式的缺点在于：
备份困难；
所有的数据都在同一台机器上，这台机器容易成为单点故障；
Session集合的总容量受到Session服务器的内存大小限制；
难以以集群的方式进行工作；
4. StickySession
采用这种策略时，某一个用户所有的请求都会映射到某一台应用服务器。无论这台服务器是否是非常空闲，还是非常繁忙，这台机器上的用户请求仍然会再次映射到这台机器上。
为了达到Session Sticky，有多种负载的策略：
1. IP Hash
IP Hash策略下，将所有的应用服务器列成一个Hash表，这个表中的每一个元素即是一台应用服务器。负载均衡器的负载策略是根据用户的IP，将用户的IP Hash到以上所谈及到Hash表中。一般而言，用户的IP不会有变化，Hash值也是不会变化的，因而用户的请求会一直映射到某一台应用服务器上。当用户的数量非常庞大的时候，一般用户的IP也比较分散，这种策略的效果也比较好。而且，这种方式的实现也非常简单，只需要对负载均衡器进行一定的配置便可，而不需要对业务系统做出任何的修改。
2. 用户名Hash
在现在Web系统中，一般都会有注册用户，而且只有注册用户才可以使用其发布的服务。用户名Hash，其原理、优缺点与IP Hash基本上是相同的，只是Hash函数的输入不再是用户的IP地址，而是用户的用户名。而用户名的提供主要有两种方式，一种是每一个请求URL都会带上自己的用户名，第二种是将用户名放在客户端的Cookie中。在第二种方法中，如果客户端不提供Cookie，那这种策略将会无法执行。
3. 首次登陆时间Hash
这种Hash策略的原理也非常容易想象，不再是用户的IP地址或者用户名，而根据用户登陆系统的时间来进行Hash。同样，首次登陆时间的提供主要有两种方式，一种是每一个请求URL都会带上自己的登陆时间，第二种是将登陆时间放在客户端的Cookie中。在第二种方法中，如果客户端不提供Cookie，那这种策略将会无法执行。
缓存管理
1. 采用服务的方式
这是一种最直接的方式。当然服务的方式可以多种多样，比较简单的方式是提供一个ClearCache.aspx的页面，当实体数据发生变更之后调用N多台Web应该的这个页面。
2. 采用File Dependency的策略
这种策略让缓存依赖于一个指定的文件，通过改变文件的更新日期来清除缓存。这种方式的缺点是，如果缓存的数据比较多，相关的依赖文件比较松散，对管理这些依赖文件有一定的麻烦。对于负载均衡环境下，还需要同时更新多台Web服务器下的缓存文件，如果多个Web应用中的缓存依赖于同一个共享的文件，可能会省掉这个麻烦，但是对Web应用中运行帐号的权限所限，终归不是那么简洁。
3. 采用SqlCacheDependency的策略
这种策略让缓存依赖与数据库中指定的数据（查询结果）。可以用Poll的方式主动调用，设定一个周期，循环调用查询语句，如果查询结果发生变化，就会清除缓存。也可以配合Sql Server 2005，采用Push的方式被动的被通知什么时候会清楚缓存。这种Push的方式是基于Sql Server 2005中Broker Service的订阅服务，SqlCacheDependency需要配合SqlDependency来实现这种方式。
文章原地址：http://www.douban.com/note/269093631/
这篇关于[转发] 负载均衡的服务器集群上如何进行缓存和会话数据的管理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
