载均衡的服务器集群上如何进行缓存和会话数据的管理
会话数据管理方法
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来实现这种方式。
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来实现这种方式。
