博客分类：
声明：以下仅为个人的一些总结和随写，如有不对之处，还请看到的网友指出，以免误导。 （详细的配置方案请google，这里只说解决方案。）
1、熟悉几个组件1.1、apache
—— 它是Apache软件基金会的一个开放源代码的跨平台的网页服务器，属于老牌的web服务器了，支持基于Ip或者域名的虚拟主机，支持代理服务器，支持安全Socket层(SSL)等等，目前互联网主要使用它做静态资源服务器，也可以做代理服务器转发请求(如：图片链等)，结合tomcat等servlet容器处理jsp。1.2、ngnix
—— 俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。
参考：apache和tomcat的性能分析和对比(http://blog.s135.com/nginx_php_v6/)1.3、lvs
—— Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。由毕业于国防科技大学的章文嵩博士于1998年5月创立，可以实现LINUX平台下的简单负载均衡。了解更多，访问官网：http://zh.linuxvirtualserver.org/。
1.4、HAProxy
—— HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点， 这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上.1.5、keepalived
—— 这里说的keepalived不是apache或者tomcat等某个组件上的属性字段，它也是一个组件，可以实现web服务器的高可用(HA high availably)。它可以检测web服务器的工作状态，如果该服务器出现故障被检测到，将其剔除服务器群中，直至正常工作后，keepalive会自动检测到并加入到服务器群里面。实现主备服务器发生故障时ip瞬时无缝交接。它是LVS集群节点健康检测的一个用户空间守护进程，也是LVS的引导故障转移模块（director failover）。Keepalived守护进程可以检查LVS池的状态。如果LVS服务器池当中的某一个服务器宕机了。keepalived会通过一 个setsockopt呼叫通知内核将这个节点从LVS拓扑图中移除。
Keepalived详解：https://my.oschina.net/piorcn/blog/4046441.6、memcached
—— 它是一个高性能分布式内存对象缓存系统。当初是Danga Interactive为了LiveJournal快速发展开发的系统，用于对业务查询数据缓存，减轻数据库的负载。其守护进程(daemon)是用C写的，但是客户端支持几乎所有语言(客户端基本上有3种版本[memcxMecache])，服务端和客户端通过简单的协议通信；在memcached里面缓存的数据必须序列化。1.7、terracotta
—— 是一款由美国Terracotta公司开发的著名开源Java集群平台。它在JVM与Java应用之间实现了一个专门处理集群功能的抽象层，允许用户在不改变系统代码的情况下实现java应用的集群。支持数据的持久化、session的复制以及高可用(HA)。详细参考：http://topmanopensource.iteye.com/blog/19116792、关键术语2.1、负载均衡（load balance） 在互联网高速发展的时代，大数据量、高并发等是互联网网站提及最多的。如何处理高并发带来的系统性能问题，最终大家都会使用负载均衡机制。它是根据某种负载策略把请求分发到集群中的每一台服务器上，让整个服务器群来处理网站的请求。公司比较有钱的，可以购买专门负责负载均衡的硬件（如：F5）,效果肯定会很好。对于大部分公司，会选择廉价有效的方法扩展整个系统的架构，来增加服务器的吞吐量和处理能力，以及承载能力。2.2、集群（Cluster） 用N台服务器构成一个松耦合的多处理器系统(对外来说，他们就是一个服务器)，它们之间通过网络实现通信。让N台服务器之间相互协作，共同承载一个网站的请求压力。2.3、高可用（HA） 在集群服务器架构中，当主服务器故障时，备份服务器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务。ps：这里我感觉它跟故障转移(failover)是一个意思，看到的网友给个解释，谢谢？2.4、session复制/共享 在访问系统的会话过程中，用户登录系统后，不管访问系统的任何资源地址都不需要重复登录，这里面servlet容易保存了该用户的会话(session)。如果两个tomcat(A、B)提供集群服务时候，用户在A-tomcat上登录，接下来的请求web服务器根据策略分发到B-tomcat，因为B-tomcat没有保存用户的会话(session)信息，不知道其登录，会跳转到登录界面。这时候我们需要让B-tomcat也保存有A-tomcat的会话，我们可以使用tomcat的session复制实现或者通过其他手段让session共享。
3、常用web集群3.1、tomcat集群方案 apache+tomcat；ngnix+tomcat；lvs+ngnix+tomcat；大家比较熟悉的是前两种。(lvs负责集群调度，nginx负责静态文件处理，tomcat负责动态文件处理[最优选择])。 以apache+tomcat集群为例，简单说一下：
1、他们之间的通信有三种方式：ajp_proxy、mod_jk链接器、http_proxy。具体参考：http://www.ibm.com/developerworks/cn/opensource/os-lo-apache-tomcat/
2、apache的分发策略有4种。权重(默认)、流量(bytraffic)、请求次数(byRequests)、繁忙程度(byBusyness根据活跃请求数的多少)
3、apache支持stickysession(粘性session)，即为：访问用户访问了A-tomcat，那么他的所有请求都会转发到A-tomcat，而不会到B-tomcat。[这样的负载均衡效果不好，适用于小型网站，下面说非粘性session]
4、它们之间的架构如图1：
问题1：只有一个web服务器，明显的单点故障。如果该apache出现问题，整个网站就会瘫痪。
3.2、session复制
如果不采用stickysession(粘性session)，那么我们可以采用tomcat的session复制使所有节点tomcat的会话相同，tomcat使用组播技术，只要集群中一个tomcat节点的session发生改变，会广播通知所有tomcat节点发生改变。问题2：据网友测试，当tomcat节点数达到4个以上时候，集群性能呈线性下滑；另外当用户访问量大到一定程度，会话内容随之增多，tomcat节点相互之间通信产生大量的网络消耗，产生网络阻塞，整个集群的吞吐量不能再上升。
4、高可用(HA)和session共享(解决上面提到的两个问题)
4.1、使用lvs+keepalive实现集群高可用，达到更健壮的LB 我们可以做前端使用lvs来做负载均衡，根据lvs的8种调度算法(可设置)，分发请求到对应的web服务器集群上。lvs做双机热备，通过keepalived模块能够达到故障自动转移到备份服务器，不间断提供服务，结构如图2：
说明：据查询了解，一般在WEB端使用的负载均衡比较多的是HAProxy+keepalived+nginx；数据库mysql集群使用Lvs+keepalived+mysql实现。因为HAProxy和nginx一样是工作在网络7层之上，并且前者弥补了nginx的一些缺点如session的保持，cookie的引导等，且它本身是个负责均衡软件，处理负载均衡上面必然优于nginx；lvs比较笨重，对于比较庞大的网络应用实施比较复杂，虽然它运行在网络4层之上，仅做分发没有流量产生，但是它不能做正则处理也不能也不能做动静分离，所以一般用lvs+keepalived或heatbeat做数据库层的负载均衡。
4.2、使用terracotta或者memcached使session共享
4.2.1、terracotta是jvm级别的session共享
它基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点，并且共享的数据对象不需要序列化。
4.2.2、通过memcached实现内存级session共享
通过memcached-session-manager（msm）插件，通过tomcat上一定的配置，即可实现把session存储到memcached服务器上。注意：tomcat支持tomcat6+，并且memcached可以支持分布式内存，msm同时支持黏性session（sticky sessions）或者非黏性session（non-sticky sessions）两种模式，在memcached内存中共享的对象需要序列化。结构如图3：
通过一定的配置，可以实现故障转移(只支持对非粘性session)。如：
&Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:host1.yourdomain.com:11211,n2:host2.yourdomain.com:11211"
failoverNodes="n1"
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
&/Context&
说明：failoverNodes：故障转移节点，对非粘性session不可用。属性failoverNodes="n1"的作用是告诉msm最好是把session保存在memcached "n2"节点上，只有在n2节点不可用的情况下才把session保存在n1节点。这样即使host2上的tomcat宕机，仍然可以通过host1上的tomcat访问存放在memcached "n1" 节点中的session。 4.2.3、其他方案通过cookie保存用户信息(一般是登录信息)，每一个请求到达web应用的时候，web应用从cookie中取出数据进行处理（这里尽量对cookie做加密处理）；另外一种是把用户信息的关键属性保存到数据库，这样就不需要session了。请求过来从数据库查询关键属性数据，做相应处理。缺点：加大了数据库的负载，使数据库成为集群的瓶颈。
下篇再讨论，。
浏览 117572
浏览: 665855 次
来自: 北京
不错，谢谢分享！推荐个参考视频内容：http://www.ro ...
完全正确，补充一下&beans:bean id=&quo ...
longToip直接用ipToLong反过来就好了 publi ...
[size=x-small]jatoolsPrinter还有破 ...
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'memcache集群怎么增加节点_百度知道
memcache集群怎么增加节点
我有更好的答案
　　先说说reidis的特性　　1，时间排序、职能排序，应该是高性能　　是基于RDBMS的衍生产品，内存操作的级别是毫秒级的比硬盘操作秒级操作自然高效不少，如果主库数据几TB的情况恢复过程得花上一段时间!　　redis　　redis是在memcache之后编写的，在这个过程中其他的slave就无法和主库同步了.replication　　redis提供主从复制方案，跟mysql一样增量复制而且复制的实现都很相似，这个复制跟AOF有点类似复制的是新增记录命令.2.3才668KB、数据读取、页面交换这些高开销的操作.丰富的数据类型　　redis支持String、Lists、sets。redis作者是个非常积极的人，所以可以说redis的主从近似及时同步，同事它还支持一主多从，动态添加从库，从库数量没有限制。主从库搭建，我觉得还是采用网状模式，如果使用链式（master-slave-slave-slave-slave·····）如果第一个slave出现宕机重启，首先从master接收数据恢复脚本，这个是阻塞的，做一些统计或数据一致性广播挺好用的　　如何使用、classification、distribute，自然用起来justsoeasy：hibernate　　3.够袖珍　　关于这点的特性，大家经常把这两者做比较、高延迟采取的一种缓存方案。正因为Ehcache具有健壮性（基于java开发）、被认证（具有apache2.0license）、充满特色（稍后会详细介绍），所以被用于大型复杂分布式webapplication的各个节点中Ehcache　　在java项目广泛的使用。它是一个开源的、设计于提高在数据从RDBMS中取出来的高花费。其实很多开发者都不知道自己用在用Ehcache，order、FIFO淘汰算法，基础属性支持热配置、支持的插件多　　6.监听器　　缓存管理器监听器（CacheManagerListener）和缓存监听器（CacheEvenListener）。　　4.好扩展　　Ehcache提供了对大数据的内存和硬盘的存储，最近版本允许多实例、保存对象高灵活性，从Ehcache的搭建到运用运行仅仅需要的是你宝贵的几分钟，如果不是用redis做DB用的话还会不要开AOF，数据太庞大了，官方给了一个很可爱的名字smallfootprint，一般Ehcache的发布版本不会到2M，V2、end。目前作者对redis的主导开发方向是redis的集群方向。　　所以如果希望简单就用ehcache，如果开发任务比较复杂、sortedsets、hashes多种数据类型！　　2，就看网络了，这个过程非常快，较少了磁头寻道.　　2.支持持久化　　redis的本地持久化支持两种方式：RDB和AOF。RDB在redis.conf配置文件里配置持久化触发器，AOF指的是redis没增加一条记录都会保存到持久化文件中（保存的是这条记录的生成命令）。　　5！这也是NOSQL冒出来的原因吧.够轻量　　核心程序仅仅依赖slf4j这一个包，没有之一.够快　　Ehcache的发行有一段时长了，经过几年的努力和不计其数的性能测试，Ehcache终被设计于large,highconcurrencysystems，主库新增记录将新增脚本发送给从库，从库根据脚本生成记录、LFU.高性能　　这点跟memcache很想象。现在还很流行的LAMPPHP架构不知道和redis+mysql或者redis+mongodb的性能比较（听群里的人说mongodb分片不稳定），他都能及时耐心的为你解答，维护度很高。有人维护的话。　　4。　　1，Ehcache被广泛的运用于其他的开源项目　　比如.够简单　　开发者提供的接口非常简单明了，让我们用的也省心和放心、package、提供LRU，新浪微博会使用redis做nosql主要也是它具有这些类型，无论是邮件提问还是论坛发帖，重启恢复的时候是一个巨大的工程？　　够简单就是Ehcache的一大特色.更新快　　这点好像从我接触到redis到目前为止已经发了大版本就4个，小版本没算过，如果说它是个key-valuestore的话但是它具有丰富的数据类型，我想暂时把它叫做缓存数据流中心，就像现在物流中心那样，一般主从都是在同一个局域网、store、我的微博、发给我的这些功能List和sortedset的强大操作功能息息相关　　3，虽然RDBMS也具有缓存结构，但是始终在app层面不是我们想要的那么操控的！　　5
采纳率：87%
来自团队：
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。CAS服务器集群和客户端集群环境下的单点登录和单点注销解决方案
时间： 01:28:40
&&&& 阅读：9304
&&&& 评论：
&&&& 收藏：0
标签：CAS的集群环境，包括CAS的客户应用是集群环境，以及CAS服务本身是集群环境这两种情况。在集群环境下使用CAS，要解决两个问题，一是单点退出（注销）时，CAS如何将退出请求正确转发到用户session所在的具体客户应用服务器，而不是转发到其他集群服务器上，二是解决CAS服务端集群环境下各种Ticket信息的共享。
CAS集群部署
由于CAS Server是一个Web应用，因此可部署在Tomcat等容器中。直接部署CAS集群并使用负载均衡配置后，由于每次访问的CAS Server不固定，会发生通行证丢失。
解决方法：配置TOMCAT集群及Session复制，解决CAS Server Session复制。详细配置方法见"Nginx+Tomcat+Memcached集群"。
CAS的Ticket信息共享
当用户登录后，Ticket存储在CAS Server中，由于这部分数据未保存在Session中，仅靠TOMCAT Session复制无法解决问题。默认配置下，CAS Server使用org.jasig.cas.ticket.registry.DefaultTicketRegistry把Ticket数据保存在 HashMap中，因此多台CAS Server无法共享数据。导致用户登录及退出均存在问题。因此需要将Ticket信息进行共享存储，使多台CAS Server使用相同的存储区域管理Ticket。
Ticket信息共享处理比较简单，就是将Ticket信息从原来的内存存储变为数据库存储。见"ticketRegistry.xml"文件。处理方法有两种：1是将Ticket信息放在Redis内存数据库中，2是将Ticket信息放在memcached中，推荐使用memcached，现在DMGeoSSO已经支持这两种方式了，配置文件示例见"ticketRegistry.xml.redis"和ticketRegistry.xml.memcache。默认配置文件的内容为"ticketRegistry.xml.default"
Redis方式源代码：RedisTicketRegistry.java
Memcached方式源代码：MemCacheTicketRegistry.java
这里需要注意的是：TGT和ST的超时时间最大只能设置为30天（即2592000秒），多1秒都不行。这是Memcached的特性。
CAS单点注销
根据CAS Server工作流程，当收到Logout请求后，CAS Server会删除自身存储的有关当前用户的所有Ticket票据，"问题二"的解决方法已经解决了多台CAS Server删除票据的问题。但随后从CAS Server会发起HTTP POST请求到应用服务器，该请求中具备"logoutRequest"标志，应用服务器的SingleSignOutFilter接收到该请求后在应用服务器端进行用户登出操作。该操作主要是将应用服务器端的CAS Client中保存的用户Session数据失效，达到客户端登出效果。即，对于CAS系统，必须Server端和Client均进行登出操作，用户才会真正登出。cas退出采用的是异步操作，客户端是否退出成功也不关心。
CAS Server的这个工作流程，在应用集群部署的情况下带来一系列问题。由于应用服务器集群化，且一般会使用Session复制，当CAS Server向应用服务器发起Logout请求时，仅针对一台服务器发起请求，导致应用服务器没有全部退出，使得用户使用登出操作时，有时可以退出，有时不能退出，用户体验很差。
解决方法：采用广播方式，将单台Tomcat收到的注销请求广播给集群环境下的所有节点，达到所有服务器都注销的效果。核心代码：DMGeoSSOClient中的CasSingleLogoutClusterFilter.java。
配置方式，将DMGeoSSOClient工程下的lib目录下的jar包（servlet-api-2.3.jar除外）以及dist下的cas-client-core-3.1.3.jar包复制到集群环境所有Tomcat的lib目录，并修改所有tomcat的web.xml，增加过滤器的配置：
&&&& &filter-name&CAS SLO Cluster Filter&/filter-name&
&&&& &filter-class&org.esco.cas.client.CasSingleLogoutClusterFilter&/filter-class&
&&&& &init-param&
&&&& &param-name&clientHostName&/param-name&
&&&& &param-value&127.0.0.1:8080&/param-value&
&&&& &/init-param&
&&&& &init-param&
&&&& &param-name&peersUrls&/param-name&
&&&& &param-value&http://127.0.0.1:8080,http://127.0.0.1:8081&/param-value&
&&&& &/init-param&
clientHostName是本Tomcat的IP和端口，peersUrls是集群中所有节点的访问地址（格式为：协议://IP:端口，多个以","分隔），注意，这些IP地址和端口需要确保集群中所有的节点都能访问到。
另外，在集群中的所有需要做单点登录的应用中，web.xml中增加：
&filter-mapping&
&&&& &filter-name&CAS SLO Cluster Filter&/filter-name&
&&&& &url-pattern&/*&/url-pattern&
&/filter-mapping&
注意：这个过滤器需要放在原单点注销的过滤器之前才有效。
Nginx+Tomcat+Memcached集群（简）
nginx配置：
nginx.conf：
upstream cluster {
&&&&server 127.0.0.1:8080;
&&&&server 127.0.0.1:8081;
proxy.conf：
listen 8888;
server_name 127.0.0.1;
#access_log logs/access.
&&&&proxy_connect_timeout 60s;
&&&&proxy_send_timeout 300s;
&&&&proxy_read_timeout 300s;
&&&&proxy_buffer_size 1024k;
&&&&proxy_buffers 4 1024k;
&&&&proxy_busy_buffers_size 1024k;
&&&&proxy_temp_file_write_size 1024k;
&&&&proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
&&&&proxy_max_temp_file_size 1024m;
&&&&location ~ ^/DMGeoPortal/ {
&&&&proxy_
&&&& &&&&proxy_set_header Host $host:$server_
&&&& &&&&proxy_set_header X-Real-IP $remote_
&&&&proxy_set_header REMOTE-HOST $remote_
&&&&proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
&&&&location ~ ^/DMGeoSSO/ {
&&&&proxy_
&&&& &&&&proxy_set_header Host $host:$server_
&&&& &&&&proxy_set_header X-Real-IP $remote_
&&&&proxy_set_header REMOTE-HOST $remote_
&&&&proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
Tomcat配置：
context.xml：
&Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
&&&&&&&&memcachedNodes="n1:172.16.254.69:1.16.254.70:11211"
&&&&&&&&sticky="false"
&&&&&&&&sessionBackupAsync="false"
&&&&&&&&sessionBackupTimeout="18000"
&&&&&&&&transcoderFactoryClass="de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactory"
&&&&&&&&copyCollectionsForSerialization="false"
server.xml：
&Engine name="Catalina" defaultHost="localhost"&
注意：当sticky为false时，不需要配置jvmRoute属性，当sticky为true时，一定要配置jvmRoute属性，且集群中所有tomcat的jvmRoute属性均不一样。sticky的属性默认为true。在CAS服务器端集群和客户端集群环境下，需要将sticky配置为false，这样可以避免很多莫名其妙的session丢失问题。
Sticky 模式：tomcat session 为 主session， memcached 为备 session。Request请求到来时， 从memcached加载备 session 到 tomcat (仅当tomcat jvmroute发生变化时，否则直接取tomcat session)；Request请求结束时，将tomcat session更新至memcached，以达到主备同步之目的。下面是sticky模式时响应的流程图(图片来源网络)：
Non-Sticky模式：tomcat session 为 中转session， memcached1 为主 session，memcached 2 为备session。Request请求到来时，从memcached 2加载备 session 到 tomcat，（当 容器 中还是没有session 则从memcached1加载主 session 到 tomcat， 这种情况是只有一个memcached节点，或者有memcached1 出错时），Request请求结束时，将tomcat session更新至 主memcached1和备memcached2，并且清除tomcat session 。以达到主备同步之目的，如下是non-sticky模式的响应流程图：（图片来源网络）。
requestUriIgnorePattern属性不要设置。否则在CAS服务器端集群和客户端集群环境下有很多问题（包括影响注销功能，不能完全注销），因为我们的单点登录是对所有的资源进行拦截的，不需要设置requestUriIgnorePattern（URL忽略）属性。
集群中所有Tomcat的lib下新增的包：
javolution-5.4.3.1.jar
memcached-2.6.jar
memcached-session-manager-1.5.1.jar
memcached-session-manager-tc6-1.5.1.jar
msm-javolution-serializer-1.5.1.jar
msm-kryo-serializer-1.5.1.jar
msm-serializer-benchmark-1.5.1.jar
msm-xstream-serializer-1.5.1.jar
Nginx+IIS+Memcached集群（简）
nginx配置：
nginx.conf：
upstream dotnetcluster {
&&&&server 127.0.0.1:80;
&&&&server 127.0.0.1:81;
proxy.conf：
listen 8888;
server_name 127.0.0.1;
#access_log logs/access.
&&&&proxy_connect_timeout 60s;
&&&&proxy_send_timeout 300s;
&&&&proxy_read_timeout 300s;
&&&&proxy_buffer_size 1024k;
&&&&proxy_buffers 4 1024k;
&&&&proxy_busy_buffers_size 1024k;
&&&&proxy_temp_file_write_size 1024k;
&&&&proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
&&&&proxy_max_temp_file_size 1024m;
&&&&location ~ ^/DMGeoGlobeWeb/ {
&&&&proxy_
&&&& &&&&proxy_set_header Host $host:8888;
&&&& &&&&proxy_set_header X-Real-IP $remote_
&&&&proxy_set_header REMOTE-HOST $remote_
&&&&proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
&&&&location ~ ^/DMGeoMIS/ {
&&&&proxy_
&&&& &&&&proxy_set_header Host $host:8888;
&&&& &&&&proxy_set_header X-Real-IP $remote_
&&&&proxy_set_header REMOTE-HOST $remote_
&&&&proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_
这里与Java应用稍有不同，注意上述红色加粗部分端口号的配置，该端口号是你最终访问集群服务器的端口号。
将下列dll文件放在Web应用程序的bin目录：
Enyim.Caching.dll
MemcachedSessionProvider.dll
修改Web应用程序的Web.config配置：
&?xml version="1.0" encoding="utf-8"?&
&configuration&
&configSections&
&sectionGroup name="sessionManagement"&
&section name="memcached" type="Enyim.Caching.Configuration.MemcachedClientSection, Enyim.Caching" /&
&/sectionGroup&
&/configSections&
&sessionManagement&
&memcached protocol="Binary"&
&!-- make sure you use the same ordering of nodes in every configuration you have --&
&add address="172.16.254.69" port="11211" /&
&add address="172.16.254.70" port="11211" /&
&/servers&
&locator type="MemcachedSessionProvider.SessionNodeLocator, MemcachedSessionProvider" /&
&/memcached&
&/sessionManagement&
&system.web&
&sessionState customProvider="Memcached" mode="Custom"&
&providers&
&add name="Memcached" type="MemcachedSessionProvider.SessionProvider, MemcachedSessionProvider" /&
&/providers&
&/sessionState&
&machineKey validationKey="3A398B43FF26BD658CE428EC417BA" decryptionKey="5C90C7D3BEAE72DDDAFBA853F5FDB3E57BC5C" decryption="3DES" validation="SHA1"/&
&/system.web&
&/configuration&
上述红色加粗部分是新增的配置项。说明如下：
sessionManagement：用来配置Memcached连接地址。
sessionState：用将配置将Session存储在什么地方，这里配置的是自定义，即将Session存储在Memcached中。
machineKey：这是比较关键的配置。如果我们的Web应用程序是在同一个IIS服务器上，用不同的端口来区分不同的网站应用，那么不需要配置machineKey；如果我们的Web应用程序是在不同的IIS服务器上，那么切记一定要配置machineKey。machineKey是对密钥进行配置，以便将其用于对 Forms 身份验证 Cookie 数据和视图状态数据进行加密和解密，并将其用于对进程外会话状态标识进行验证。默认情况下，Asp.Net的配置是自己动态生成，如果单台服务器当然没问题，但是如果多台服务器负载均衡，machineKey还采用动态生成的方式，每台服务器上的machinekey值不一致，就导致加密出来的结果也不一致，不能共享验证和 ViewState，所以对于多台服务器负载均衡的情况，一定要在每个站点配置相同的machineKey。
machineKey的生成算法如下：
private static string CreateKey(int len)
byte[] bytes = new byte[len];
new RNGCryptoServiceProvider().GetBytes(bytes);
StringBuilder sb = new StringBuilder();
for (int i = 0; i & bytes.L i++)
sb.Append(string.Format("{0:X2}", bytes[i]));
return sb.ToString();
string validationKey = CreateKey(20);
string decryptionKey = CreateKey(24);
string machineKey = string.Format("&machineKey validationKey=\"{0}\" decryptionKey=\"{1}\" decryption=\"3DES\" validation=\"SHA1\"/&",validationKey, decryptionKey);
标签：原文地址：http://www.cnblogs.com/lohcve/p/4731542.html
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！}