A. Redis分布式缓存搭建
花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用，又补齐了集群模式的使用和搭建经验，并对集群的一些个原理做了理解。
笔者安装中遇到的一些问题：
如果make报错，可能是没装gcc或者gcc++编辑器，安装之 yum -y install gcc gcc-c++ kernel-devel ，有可能还是提示一些个c文件编译不过，gcc -v查看下版本，如果不到5.3那么升级一下gcc：
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
这回编译通过了，提示让你最好make test一下/
执行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升级tcl， yum install tcl
重新make test，如果还有error就删了目录，重新tar包解压重新make , make test
o/ All tests passed without errors! ，表示编译成功。
然后make install即可。
直接运行命令： ./redis-server /usr/redis-6.0.3/redis.conf &
redis.conf 配置文件里 bind 0.0.0.0 设置外部访问， requirepass xxxx 设置密码。
redis高可用方案有两种：
常用搭建方案为1主1从或1主2从+3哨兵监控主节点， 以及3主3从6节点集群。
（1）sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
sentinel2.conf配置：
坑1：master节点也会在故障转移后成为从节点，也需要配置masterauth
当kill master进程之后，经过sentinel选举，slave成为了新的master，再次启动原master，提示如下错误：
原因是此时的master再次启动已经是slave了，需要向现在的新master输入密码，所以需要在master.conf
中配置：
坑2：哨兵配置文件要暴露客户端可以访问到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置该哨兵对应的master名字、master地址和端口，以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者（也就是客户端）的角度、配置访问者能访问的地址，例如sentinel与master在一台服务器（122.xx.xxx.xxx）上，那么相对sentinel其master在本机也就是127.0.0.1上，这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题，但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵，则得到的master地址为127.0.0.1，也就是springboot所在服务器本机，这显然就有问题了。
附springboot2.1 redis哨兵配置：
坑3：要注意配置文件.conf会被哨兵修改
redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。
曾经遇到过这样一个问题，大致的信息如下
slaves莫名其妙多了一个，master的地址也明明改了真实对外的地址，这里又变成127.0.0.1 !
最后，把5个redis进程都停掉，逐个检查配置文件，发现redis的配置文件在主从哨兵模式会被修改，master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001， 怀疑应该是之前配置错误的时候（见坑2）被哨兵动态加上去的！ 总之，实践中一定要多注意配置文件的变化。
（2）集群
当数据量大到一定程度，比如几十上百G，哨兵模式不够用了需要做水平拆分，早些年是使用codis，twemproxy这些第三方中间件来做分片的，即 客户端 -> 中间件 -> Redis server 这样的模式，中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案，大家就都采用官方的Redis Cluster方案了。
Redis Cluster从逻辑上分16384个hash slot，分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot，据此判断这个slot属于哪个节点。
每个节点可以设置1或多个从节点，常用的是3主节点3从节点的方案。
reshard，重新分片，可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明，不影响线上业务。
搭建Redis cluster
redis.conf文件关键的几个配置：
启动6个集群节点
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
这时候这6个节点还是独立的，要把他们配置成集群：
说明： -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码，然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。
上述命令执行完以后会有一个询问： Can I set the above configuration? yes同意自动做好的分片即可。
最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理，集群启动成功。
查看集群状态：
坑1：暴露给客户端的节点地址不对
使用lettuce连接发现连不上，查看日志 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样，集群启动的时候带的地址应该是提供给客户端访问的地址。
我们要重建集群：先把6个redis进程停掉，然后删除 nodes-7001.conf 这些节点配置文件，删除持久化文件 mp.rdb 、 appendonly.aof ，重新启动6个进程，在重新建立集群：
然后，还是连不上，这次报错 connection timed out: /172.xx.0.xx:7004 ，发现连到企鹅云服务器的内网地址上了！
解决办法，修改每个节点的redis.conf配置文件，找到如下说明：
所以增加配置：
然后再重新构建集群，停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套（累死了）
重新使用Lettuce测试，这次终于连上了！
坑2：Lettuce客户端在master节点故障时没有自动切换到从节点
name这个key在7002上，kill这个进程模拟master下线，然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去，如下图：
重新启动7002进程，
7006已成为新master，7002成为它的slave，然后Lettuce也能连接上了。
解决办法，修改Lettuce的配置：
笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端，当使用Redis cluster集群模式时，需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。
重新测试：停掉master 7006，这次Lettuce可以正常切换连到7002slave上去了。（仍然会不断的在日志里报连接错误，因为需要一直尝试重连7006，但因为有7002从节点顶上了、所以应用是可以正常使用的）
Redis不保证数据的强一致性
Redis并不保证数据的强一致性，也就是取CAP定理中的AP
关于一致性Hash算法，可以参考 一致性Hash算法 - (jianshu.com)
Redis cluster使用的是hash slot算法，跟一致性Hash算法不太一样，固定16384个hash槽，然后计算key落在哪个slot里边（计算key的CRC16值再对16384取模），key找的是slot而不是节点，而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知，这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时，大量key对应的寻址都发生改动导致缓存失效的问题。
比如集群增加了1个节点，这时候如果不做任何操作，那么新增加的这个节点上是没有slot的，所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效，当reshard一部分slot到新节点后，客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点，而没迁移的slot仍然寻址到原来的节点。
关于热迁移，猜想，内部应该是先做复制迁移，等迁移完了，再切换slot与节点的对应关系，复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后，再删除原节点上已经迁移的slot所对应的key。
与哨兵模式比较类似，当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机，然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程，当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点，此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点，那么这个从节点当选新的master节点。
所有节点都持有元数据，节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。
这种去中心化的分布式节点之间内部协调，包括故障识别、故障转移、选主等等，核心在于gossip扩散协议，能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据，即所有的节点都知悉当前集群全局的情况。
Redis高可用方案 - (jianshu.com)
面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent.com)
深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs.com)
Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)
云服务器Redis集群部署及客户端通过公网IP连接问题
B. php 中如何使用缓存，使用哪种缓存机制最好;
php的缓存三种.有文件缓存，数据库缓存，memcache缓存;
memcache缓存要求对服务器支持，而且它的缓存是由期限的，一般是30天。这种缓存的效率是最高的。读存取的速度最快。
数据库缓存
和
文件缓存比较简单。适用小的项目。和php新手
C. 分布式存储是什么
分布式存储系统，是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
分布式和集中式存储
集中存储的优缺点是，物理介质集中布放;视频流上传到中心对机房环境要求高，要求机房空间大，承重、空调等都是需要考虑的问题。
分布存储，集中管理的优缺点是，物理介质分布到不同的地理位置;视频流就近上传，对骨干网带宽没有什么要求;可采用多套低端的小容量的存储设备分布部署，设备价格和维护成本较低;小容量设备分布部署，对机房环境要求低。
链乔教育在线旗下学硕创新区块链技术工作站是中国教育部学校规划建设发展中心开展的“智慧学习工场2020-学硕创新工作站 ”唯一获准的“区块链技术专业”试点工作站。专业站立足为学生提供多样化成长路径，推进专业学位研究生产学研结合培养模式改革，构建应用型、复合型人才培养体系。
D. Spring本地缓存的使用方法
我们现在在用的Spring Cache，可以直接看Spring Boot提供的缓存枚举类，有如下这些：
EhCache：一个纯Java的进程内缓存框架，所以也是基于本地缓存的。(注意EhCache2.x和EhCache3.x相互不兼容)。
Redis：分布式缓存，只有Client-Server(CS)模式，Java一般使用Jedis/Luttuce来操纵。
Hazelcast：基于内存的数据网格。虽然它基于内存，但是分布式应用程序可以使用Hazelcast进行分布式缓存、同步、集群、处理、发布/订阅消息等。
Guava：它是Google Guava工具包中的一个非常方便易用的本地化缓存实现，基于LRU（最近最少使用）算法实现，支持多种缓存过期策略。在Spring5.X以后的版本已经将他标记为过期了。
Caffeine：是使用Java8对Guava缓存的重写版本，在Spring5中将取代了Guava，支持多种缓存过期策略。
SIMPLE：使用ConcurrentMapCacheManager，因为不支持缓存过期时间，所以做本地缓存基本不考虑该方式。
关于分布式缓存，我们需要后面会专门讨论Redis的用法，这里只看本地缓存。性能从高到低，依次是Caffeine，Guava，ConcurrentMapCacheManager，其中Caffeine在读写上都快了Guava近一倍。
这里我们只讨论在Spring Boot里面怎么整合使用Caffeine和EhCache。
主要有以下几个步骤：
1)加依赖包：
2)配置缓存：
这里有两种方法，通过文件配置或者在配置类里面配置，先看一下文件配置，我们可以写一个properties文件，内容像这样：
然后还要在主类中加上@EnableCaching注解：
另外一种更灵活的方法是在配置类中配置：
应用类：
测试类：
导入依赖包，分为2.x版本和3.x版本。
其中2.x版本做如下导入：
3.x版本做如下导入：
导包完成后，我们使用JCacheManagerFactoryBean + ehcache.xml的方式配置：
参考资料：
https://blog.csdn.net/f641385712/article/details/94982916
http://www.360doc.com/content/17/1017/20/16915_695800687.shtml
E. 大数据环境下分布式文件系统有哪些特点,相应的优化思路是什么
分布式元数据管理：分布式元数据管理主要通过元数据服务分布式部署的方式，实现了元数据分布式管理，解决一般分布式文件系统的单元数据服务节点导致的响应用户请求效率不高、存储文件数目受限和单点故障等问题，具有降低用户请求处理延迟，提高分布式文件系统的可扩展性和可用性的特性。一般包括完全分布式架构、元数据访问负载均衡、元数据服务器高效索引、元数据服务器弹性伸缩等技术点。
多层级存储管理：多层级存储管理用于实现内存 / SSD/HDD 等异构存储设备的池化管理，以及各类存储设备的动态接入管理，通过设备抽象和提供统一命名空间，面向分布式文件系统提供统一的存储资源池，支持热点数据自动感知和智能化存储调度，最大程度提升数据存储与访问的效能。一般包括异构存储设备管理、多存储系统适配、统一命名空间、基于热度的存储资源调度等技术点。
数据一致性保障：数据一致性保障主要解决分布式文件系统中多副本和缓存等在数据存储与访问过程中的一致性问题，通过构建数据一致性模型、进行数据一致性校验等方式，保障数据在存储和访问过程中的一致性，在提升数据访问性能的同时确保数据存储和访问的正确性。一般包括一致性协议优化、一致性检验等技术点。
高并行读写优化：高并行读写优化用于提高分布式文件读写的并行化水平，最大化提升分布式文件系统下的数据访问效率。一般包括分布式数据访问缓存管理和调度算法优化、IO 算法优化和合并 IO 等技术点。
分布式散列与动态均衡：分布式散列与动态均衡实现分布式文件系统下高性能的数据块定位，提高数据访问性能，以及数据块的迁移和再平衡，提升分布式文件系统的稳定性和可持续服务能力。一般包括基于一致性哈希的数据块索引管理、动态数据再平衡等技术点。
存储高可用：存储高可用通过数据多副本技术、状态自检测和自修复、核心服务分布式部署等技术手段，实现自动检测分布式文件系统中的各种错误和失效，并且在文件系统出现错误和失效时可自行进行多副本间的数据修复，最终持续向用户提供正常的数据访问服务。一般包括可配置数据多副本、数据自恢复及自维护等技术点。
海量小文件高性能存储访问：海量小文件高性能存储访问主要采用小文件汇集成大文件进行存储、细粒度二级索引管理等技术，实现在现有分布式文件系统的基础上，扩展对海量小文件的存储与访问的能力，同时解决小文件的随机读写问题，大大提高分布式文件系统对海量小文件的存储访问效率。
F. 如何实现高性能分布式文件存储
其实分布式文件存储，最复杂的就是元数据的保存和处理，而我使用的XGFS文件存储软件只需要三个全闪存元数据高可用节点，就可以高效保存和处理 100 亿文件规模的数据，可以灵活扩展，满足公司不断增长的业务对性能和容量的需求，XSKY星辰天合这款产品还是很有性价比的。
G. 存储器层次结构中的缓存
《深入理解计算机系统》p422
6.1 存储器层次结构中的缓存
一般而言,高速缓存( cache ,读作“ cash ”)是一个小而快速的存储设备,它作为存储在更大、也更慢的设备中的数据对象的缓冲区域。使用高速缓存的过程称为缓存( caching ,读作“ cashing ”)。存储器层次结构的中心思想是,对于每个 k ,位于 k 层的更快更小的存储设备作为位于 k 十1层的更大更慢的存储设备的缓存。换句话说,层次结构中的每一层都缓存来自较低一层的数据对象。例如,本地磁盘作为通过网络从远程磁盘取出的文件(例如 Web 页面)的缓存,主存作为本地磁盘上数据的缓存,依此类推,直到最小的缓存—— CPU 寄存器组。图6-22展示了存储器层次结构中缓存的一般性概念。第 k 十1层的存储器被划分成连续的数据对象组块( chunk ),称为块( block )。每个块都有一个唯一的地址或名字,使之区别于其他的块。块可以是固定大小的(通常是这样的),也可以是可变大小的(例如存储在 Web 服务器上的远程 HTML 文件)。例如,图6-22中第 k 十1层存储器被划分成16个大小固定的块,编号为0~15。
类似地,第 k 层的存储器被划分成较少的块的集合,每个块的大小与 k 十1层的块的大小一样。在任何时刻,第 k 层的缓存包含第 k 十1层块的一个子集的副本。例如,在图6-22中,第 k 层的缓存有4个块的空间,当前包含块4、9、14和3的副本。
数据总是以块大小为传送单元( transfer unit )在第 k 层和第 k +1层之间来回复制的。虽然在层次结构中任何一对相邻的层次之间块大小是固定的,但是其他的层次对之间可以有不同的块大小。例如,在图6-21中,L1和 LO 之间的传送通常使用的是1个字大小的块。L2和L1之间(以及I3和I2之间、L4和I3之间)的传送通常使用的是几十个字节的
块。而L5和L4之间的传送用的是大小为几百或几千字节的块。一般而言,层次结构中较低层(离 CPU 较远)的设备的访问时间较长,因此为了补偿这些较长的访问时间,倾向于使用较大的块。
1. 缓存命中
当程序需要第 k 十1层的某个数据对象 d 时,它首先在当前存储在第 k 层的一个块中查找 d 。如果 d 刚好缓存在第 k 层中,那么就是我们所说的缓存命中( cache hit )。该程序直接从第 k 层读取 d ,根据存储器层次结构的性质,这要比从第 k +1层读取 d 更快。例如,一个有良好时间局部性的程序可以从块14中读出一个数据对象,得到一个对第 k 层的缓存命中。
2. 缓存不命中
另一方面,如果第 k 层中没有缓存数据对象 d ,那么就是我们所说的缓存不命中( cache miss )。当发生缓存不命中时,第 k 层的缓存从第 k 十1层缓存中取出包含 d 的那个块,如果第 k 层的缓存已经满了,可能就会覆盖现存的一个块。
覆盖一个现存的块的过程称为替换( replacing )或驱逐( evicting )这个块。被驱逐的这个块有时也称为牺牲块( victim block )。决定该替换哪个块是由缓存的替换策略( replace — ment policy )来控制的。例如,一个具有随机替换策略的缓存会随机选择一个牺牲块。一个具有最近最少被使用 LRU )替换策略的缓存会选择那个最后被访问的时间距现在最远的块。
在第 k 层缓存从第 k 十1层取出那个块之后,程序就能像前面一样从第 k 层读出 d 了。例如,在图6-22中,在第 k 层中读块12中的一个数据对象,会导致一个缓存不命中,因为块12当前不在第 k 层缓存中。一旦把块12从第 k 十1层复制到第 k 层之后,它就会保持在那里,等待稍后的访问。
3. 缓存不命中的种类
区分不同种类的缓存不命中有时候是很有帮助的。如果第 k 层的缓存是空的,那么对
任何数据对象的访问都会不命中。一个空的缓存有时被称为冷缓存( cold cache ),此类不命中称为强制性不命中( compulsory miss )或冷不命中( cold miss )。冷不命中很重要,因为它们通常是短暂的事件,不会在反复访问存储器使得缓存暖身( warmed up )之后的稳定状态中出现。
只要发生了不命中,第 k 层的缓存就必须执行某个放置策略( placement policy ),确定把它从第 k 十1层中取出的块放在哪里。最灵活的替换策略是允许来自第 k +1层的任何块放在第 k 层的任何块中。对于存储器层次结构中高层的缓存(靠近 CPU ),它们是用硬件来实现的,而且速度是最优的,这个策略实现起来通常很昂贵,因为随机地放置块,定位起来代价很高。
因此,硬件缓存通常使用的是更严格的放置策略,这个策略将第 k 十1层的某个块限制放置在第 k 层块的一个小的子集中(有时只是一个块)。例如,在图6-22中,我们可以确定第 k 十1层的块 i 必须放置在第 k 层的块( i mod 4)中。例如,第 k 十1层的块0、4、8和12会映射到第 k 层的块0;块1、5、9和13会映射到块1;依此类推。注意,图6-22中的示例缓存使用的就是这个策略。
这种限制性的放置策略会引起一种不命中,称为冲突不命中( conflict miss ),在这种情况中,缓存足够大,能够保存被引用的数据对象,但是因为这些对象会映射到同一个缓存块,缓存会一直不命中。例如,在图6-22中,如果程序请求块0,然后块8,然后块0,然后块8,依此类推,在第 k 层的缓存中,对这两个块的每次引用都会不命中,即使这个缓存总共可以容纳4个块。
程序通常是按照一系列阶段(如循环)来运行的,每个阶段访问缓存块的某个相对稳定不变的集合。例如,一个嵌套循环可能会反复地访问同一个数组的元素。这个块的集合称为这个阶段的工作集( working set )。当工作集的大小超过缓存的大小时,缓存会经历容量不命中( capacity miss )。换句话说就是,缓存太小了,不能处理这个工作集。
4. 缓存管理
正如我们提到过的,存储器层次结构的本质是,每一层存储设备都是较低一层的缓存。在每一层上,某种形式的逻辑必须管理缓存。这里,我们的意思是指某个东西要将缓存划分成块,在不同的层之间传送块,判定是命中还是不命中,并处理它们。管理缓存的逻辑可以是硬件、软件,或是两者的结合。
例如,编译器管理寄存器文件,缓存层次结构的最高层。它决定当发生不命中时何时发射加载,以及确定哪个寄存器来存放数据。L1、L2和L3层的缓存完全是由内置在缓存中的硬件逻辑来管理的。在一个有虚拟内存的系统中, DRAM 主存作为存储在磁盘上的数据块的缓存,是由操作系统软件和 CPU 上的地址翻译硬件共同管理的。对于一个具有像 AFS 这样的分布式文件系统的机器来说,本地磁盘作为缓存,它是由运行在本地机器上的 AFS 客户端进程管理的。在大多数时候,缓存都是自动运行的,不需要程序采取特殊的或显式的行动。
6.3.2 存储器层次结构概念小结
概括来说,基于缓存的存储器层次结构行之有效,是因为较慢的存储设备比较快的存储设备更便宜,还因为程序倾向于展示局部性:
1）利用时间局部性: 由于时间局部性,同一数据对象可能会被多次使用。一旦一个数据对象在第一次不命中时被复制到缓存中,我们就会期望后面对该目标有一系列的访问命中。因为缓存比低一层的存储设备更快,对后面的命中的服务会比最开始的不命中快很多。
2）利用空间局部性: 块通常包含有多个数据对象。由于空间局部性,我们会期望后面对该块中其他对象的访问能够补偿不命中后复制该块的花费。现代系统中到处都使用了缓存。正如从图6-23中能够看到的那样, CPU 芯片、操作系统、分布式文件系统中和万维网上都使用了缓存。各种各样硬件和软件的组合构成和管理着缓存。注意,图6-23中有大量我们还未涉及的术语和缩写。在此我们包括这些术语和缩写是为了说明缓存是多么的普遍。
H. 分布式文件存储系统采用什么方式
一。分布式Session的几种实现方式 1.基于数据库的Session共享 2.基于NFS共享文件系统 3.基于memcached 的session，如何保证 memcached 本身的高可用性？ 4. 基于resin/tomcat web容器本身的session复制机制 5. 基于TT/Redis 或 jbosscache 进行 session 共享。 6. 基于cookie 进行session共享 或者是： 一、Session Replication 方式管理 (即session复制) 简介：将一台机器上的Session数据广播复制到集群中其余机器上 使用场景：机器较少，网络流量较小 优点：实现简单、配置较少、当网络中有机器Down掉时不影响用户访问 缺点：广播式复制到其余机器有一定廷时，带来一定网络开销 二、Session Sticky 方式管理 简介：即粘性Session、当用户访问集群中某台机器后，强制指定后续所有请求均落到此机器上 使用场景：机器数适中、对稳定性要求不是非常苛刻 优点：实现简单、配置方便、没有额外网络开销 缺点：网络中有机器Down掉时、用户Session会丢失、容易造成单点故障 三、缓存集中式管理 简介：将Session存入分布式缓存集群中的某台机器上，当用户访问不同节点时先从缓存中拿Session信息 使用场景：集群中机器数多、网络环境复杂 优点：可靠性好 缺点：实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入 二。Session和Cookie的区别和联系以及Session的实现原理 1、session保存在服务器，客户端不知道其中的信息；cookie保存在客户端，服务器能够知道其中的信息。 2、session中保存的是对象，cookie中保存的是字符串。 3、session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到。而cookie中如果设置了路径参数，那么同一个网站中不同路径下的cookie互相是访问不到的。 4、session需要借助cookie才能正常<nobr oncontextmenu="return false;" onmousemove="kwM(3);" id="key3" onmouseover="kwE(event,3, this);" style="COLOR: #6600ff; BORDER-BOTTOM: 0px dotted; BACKGROUND-COLOR: transparent; TEXT-DECORATION: underline" onclick="return kwC();" onmouseout="kwL(event, this);" target="_blank">工作</nobr>。如果客户端完全禁止cookie，session将失效。 http是无状态的协议，客户每次读取web页面时，服务器都打开新的会话，而且服务器也不会自动维护客户的上下文信息，那么要怎么才能实现网上商店中的 购物车呢，session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客 户,session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为JSESSIONID的输出cookie，我 们叫做session cookie,以区别persistent cookies,也就是我们通常所说的cookie,注意session cookie是存储于浏览器内存中的，并不是写到硬盘上的，这也就是我们刚才看到的JSESSIONID，我们通常情是看不到JSESSIONID的，但 是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，我们就可以在地址栏看到 sessionid=KWJHUG6JJM65HS2K6之类的字符串。 明白了原理，我们就可以很容易的分辨出persistent cookies和session cookie的区别了，网上那些关于两者安全性的讨论也就一目了然了，session cookie针对某一次会话而言，会话结束session cookie也就随着消失了，而persistent cookie只是存在于客户端硬盘上的一段文本（通常是加密的），而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，自然不如 session cookie安全了。 通常session cookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的sessionid，这样我们信息共享的目的就达不到 了，此时我们可以先把sessionid保存在persistent cookie中，然后在新窗口中读出来，就可以得到上一个窗口SessionID了，这样通过session cookie和persistent cookie的结合我们就实现了跨窗口的session tracking（会话跟踪）。 在一些web开发的书中，往往只是简单的把Session和cookie作为两种并列的http传送信息的方式，session cookies位于服务器端，persistent cookie位于客户端，可是session又是以cookie为基础的，明白的两者之间的联系和区别，我们就不难选择合适的技术来开发web service了。 总之： 一、cookie机制和session机制的区别 具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。 同时我们也看到，由于在服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上还有其他选择。 二、会话cookie和持久cookie的区别 如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。 如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。 存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。 三、如何利用实现自动登录 当用户在某个网站注册后，就会收到一个惟一用户ID的cookie。客户后来重新连接时，这个用户ID会自动返回，服务器对它进行检查，确定它是否为注册用户且选择了自动登录，从而使用户无需给出明确的用户名和密码，就可以访问服务器上的资源。 四、如何根据用户的爱好定制站点 网站可以使用cookie记录用户的意愿。对于简单的设置，网站可以直接将页面的设置存储在cookie中完成定制。然而对于更复杂的定制，网站只需仅将一个惟一的标识符发送给用户，由服务器端的数据库存储每个标识符对应的页面设置。 五、cookie的发送 1.创建Cookie对象 2.设置最大时效 3.将Cookie放入到HTTP响应报头 如果你创建了一个cookie，并将他发送到浏览器，默认情况下它是一个会话级别的cookie:存储在浏览器的内存中，用户退出浏览器之后被删除。如 果你希望浏览器将该cookie存储在磁盘上，则需要使用maxAge，并给出一个以秒为单位的时间。将最大时效设为0则是命令浏览器删除该 cookie。 发送cookie需要使用HttpServletResponse的addCookie方法，将cookie插入到一个 Set-Cookie HTTP请求报头中。由于这个方法并不修改任何之前指定的Set-Cookie报头，而是创建新的报头，因此我们将这个方法称为是addCookie，而 非setCookie。同样要记住响应报头必须在任何文档内容发送到客户端之前设置。 六、cookie的读取 1.调用request.getCookie 要获取有浏览器发送来的cookie，需要调用HttpServletRequest的getCookies方法，这个调用返回Cookie对象的数组，对应由HTTP请求中Cookie报头输入的值。 2.对数组进行循环，调用每个cookie的getName方法，直到找到感兴趣的cookie为止 cookie与你的主机(域)相关，而非你的servlet或JSP页面。因而，尽管你的servlet可能只发送了单个cookie，你也可能会得到许多不相关的cookie。 例如： String cookieName = “userID”; Cookie cookies［］ = request.getCookies(); if (cookies!=null){ for(int i=0;i Cookie cookie = cookies［i］; if (cookieName.equals(cookie.getName())){ doSomethingWith(cookie.getValue()); } } } 七、如何使用cookie检测初访者 A.调用HttpServletRequest.getCookies()获取Cookie数组 B.在循环中检索指定名字的cookie是否存在以及对应的值是否正确 C.如果是则退出循环并设置区别标识 D.根据区别标识判断用户是否为初访者从而进行不同的操作 八、使用cookie检测初访者的常见错误 不能仅仅因为cookie数组中不存在在特定的数据项就认为用户是个初访者。如果cookie数组为null，客户可能是一个初访者，也可能是由于用户将cookie删除或禁用造成的结果。 但是，如果数组非null,也不过是显示客户曾经到过你的网站或域，并不能说明他们曾经访问过你的servlet。其它servlet、JSP页面以及 非Java Web应用都可以设置cookie，依据路径的设置，其中的任何cookie都有可能返回给用户的浏览器。 正确的做法是判断cookie数组是否为空且是否存在指定的Cookie对象且值正确。 九、使用cookie属性的注意问题 属性是从服务器发送到浏览器的报头的一部分；但它们不属于由浏览器返回给服务器的报头。 因此除了名称和值之外，cookie属性只适用于从服务器输出到客户端的cookie；服务器端来自于浏览器的cookie并没有设置这些属性。 因而不要期望通过request.getCookies得到的cookie中可以使用这个属性。这意味着，你不能仅仅通过设置cookie的最大时效， 发出它，在随后的输入数组中查找适当的cookie,读取它的值，修改它并将它存回Cookie，从而实现不断改变的cookie值。 十、如何使用cookie记录各个用户的访问计数 1.获取cookie数组中专门用于统计用户访问次数的cookie的值 2.将值转换成int型 3.将值加1并用原来的名称重新创建一个Cookie对象 4.重新设置最大时效 5.将新的cookie输出 十一、session在不同环境下的不同含义 session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话是从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。 然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义。 session在Web开发环境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器端之间保持状态的解决方案。有时候Session也用来指这种解决方案的存储结构。 十二、session的机制 session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。 但程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否包含了一个session标识－称为session id,如果已经包含一个session id则说明以前已经为此客户创建过session，服务器就按照session id把这个session检索出来使用(如果检索不到，可能会新建一个，这种情况可能出现在服务端已经删除了该用户对应的session对象，但用户人为 地在请求的URL后面附加上一个JSESSION的参数)。 如果客户请求不包含session id，则为此客户创建一个session并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给客户端保存。 十三、保存session id的几种方式 A．保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。 B． 由于cookie可以被人为的禁止，必须有其它的机制以便在cookie被禁止时仍然能够把session id传递回服务器，经常采用的一种技术叫做URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在URL后面。网络在整个交互过程中始终 保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。 C．另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。 十四、session什么时候被创建 一个常见的错误是以为session在有客户端访问时就被创建，然而事实是直到某server端程序(如Servlet)调用HttpServletRequest.getSession(true)这样的语句时才会被创建。 十五、session何时被删除 session在下列情况下被删除： A．程序调用HttpSession.invalidate() B．距离上一次收到客户端发送的session id时间间隔超过了session的最大有效时间 C．服务器进程被停止 再次注意关闭浏览器只会使存储在客户端浏览器内存中的session cookie失效，不会使服务器端的session对象失效。