分布式缓存策略

‘壹’ 分布式存储有哪些

问题一：当前主流分布式文件系统有哪些?各有什么优缺点 目前几个主流的分布式文件系统除GPFS外，还有PVFS、Lustre、PanFS、GoogleFS等。
1.PVFS(Parallel Virtual File System)项目是Clemson大学为了运行linux集群而创建的一个开源项目,目前PVFS还存在以下不足：
1）单一管理节点:只有一个管理节点来管理元数据，当集群系统达到一定的规模之后，管理节点将可能出现过度繁忙的情况，这时管理节点将成为系统瓶颈;
2）对数据的存储缺乏容错机制:当某一I/O节点无法工作时，数据将出现不可用的情况;
3）静态配置:对PVFS的配置只能在启动前进行，一旦系统运行则不可再更改原先的配置。
2.Lustre文件系统是一个基于对象存储的分布式文件系统，此项目于1999年在Carnegie Mellon University启动，Lustre也是一个开源项目。它只有两个元数据管理节点,同PVFS类似,当系统达到一定的规模之后，管理节点会成为Lustre系统中的瓶颈。
3.PanFS(Panasas File System)是Panasas公司用于管理自己的集群存储系统的分布式文件系统。
4.GoogleFS(Google File System)是Google公司为了满足公司内部的数据处理需要而设计的一套分布式文件系统。
5.相对其它的文件系统，GPFS的主要优点有以下三点：
1)使用分布式锁管理和大数据块策略支持更大规模的集群系统,文件系统的令牌管理器为块、inode、属性和目录项建立细粒度的锁，第一个获得锁的客户将负责维护相应共享对象的一致性管理，这减少了元数据服务器的负担;
2)拥有多个元数据服务器,元数据也是分布式,使得元数据的管理不再是系统瓶颈;
3)令牌管理以字节作为锁的最小单位,也就是说除非两个请求访问的是同一文件的同一字节数据,对于数据的访问请求永远不会冲突.

问题二：分布式存储是什么？选择什么样的分布式存储更好？ 分布式存储系统，是将数据分散存储在多 *** 立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。
联想超融合ThinkCloud AIO超融合云一体机是联想针对企业级用户推出的核心产品。ThinkCloud AIO超融合云一体机实现了对云管理平台、计算、网络和存储系统的无缝集成，构建了云计算基础设施即服务的一站式解决方案，为用户提供了一个高度简化的一站式基础设施云平台。这不仅使得业务部署上线从周缩短到天，而且与企业应用软件、中间件及数据库软件完全解耦，能够有效提升企业IT基础设施运维管理的效率和关键应用的性能

问题三：什么是分布式存储系统？ 就是将数据分散存储在多 *** 立的设备上

问题四：什么是分布式数据存储 定义：
分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式架构发展，基于关系型的分布式数据库在保留了传统数据库的数据模型和基本特征下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。
特点：
1.高可扩展性：分布式数据库必须具有高可扩展性，能够动态地增添存储节点以实现存储容量的线性扩展。
2 高并发性：分布式数据库必须及时响应大规模用户的读/写请求，能对海量数据进行随机读/写。
3. 高可用性：分布式数据库必须提供容错机制，能够实现对数据的冗余备份，保证数据和服务的高度可靠性。

问题五：分布式文件系统有哪些主要的类别？ 分布式存储在大数据、云计算、虚拟化场景都有勇武之地，在大部分场景还至关重要。munity.emc/message/655951 下面简要介绍*nix平台下分布式文件系统的发展历史：
1、单机文件系统
用于操作系统和应用程序的本地存储。
2、网络文件系统（简称：NAS）
基于现有以太网架构，实现不同服务器之间传统文件系统数据共享。
3、集群文件系统
在共享存储基础上，通过集群锁，实现不同服务器能够共用一个传统文件系统。

4、分布式文件系统
在传统文件系统上，通过额外模块实现数据跨服务器分布，并且自身集成raid保护功能，可以保证多台服务器同时访问、修改同一个文件系统。性能优越，扩展性很好，成本低廉。

问题六：分布式文件系统和分布式数据库有什么不同 分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元组的schema，存入取出删除的粒度较小。
分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。

问题七：分布式存储有哪些 华为的fusionstorage属于分布式 您好，很高兴能帮助您，首先，FusionDrive其实是一块1TB或3TB机械硬盘跟一块128GB三星830固态硬盘的组合。我们都知道，很多超极本同样采用了混合型硬盘，但是固态硬盘部分的容量大都只有8GB到32GB之间，这个区间无法作为系统盘来使用，只能作

问题八：linux下常用的分布式文件系统有哪些 这他妈不是腾讯今年的笔试题么
NFS（tldp/HOWTO/NFS-HOWTO/index）
网络文件系统是FreeBSD支持的文件系统中的一种，也被称为NFS。
NFS允许一个系统在网络上与它人共享目录和文件。通过使用NFS， 用户和程序可以象访问本地文件一样访问远端系统上的文件。它的好处是：
1、本地工作站使用更少的磁盘空间，因为通常的数据可以存放在一台机器上而且可以通过网络访问到。
2、用户不必在每个网络上机器里面都有一个home目录。home目录可以被放在NFS服务器上并且在网络上处处可用。
3、诸如软驱、CDROM、和ZIP之类的存储设备可以在网络上面被别的机器使用。可以减少整个网络上的可移动介质设备的数量。
开发语言c/c++,可跨平台运行。
OpenAFS（openafs）
OpenAFS是一套开放源代码的分布式文件系统，允许系统之间通过局域网和广域网来分享档案和资源。OpenAFS是围绕一组叫做cell的文件服务器组织的，每个服务器的标识通常是隐藏在文件系统中，从AFS客户机登陆的用户将分辨不出他们在那个服务器上运行，因为从用户的角度上看，他们想在有识别的Unix文件系统语义的单个系统上运行。
文件系统内容通常都是跨cell复制，一便一个硬盘的失效不会损害OpenAFS客户机上的运行。OpenAFS需要高达1GB的大容量客户机缓存，以允许访问经常使用的文件。它是一个十分安全的基于kerbero的系统，它使用访问控制列表(ACL）以便可以进行细粒度的访问，这不是基于通常的Linux和Unix安全模型。开发协议IBM Public，运行在linux下。
MooseFs（derf.homelinux）
Moose File System是一个具备容错功能的网路分布式文件统，它将数据分布在网络中的不同服务器上，MooseFs通过FUSE使之看起来就 是一个Unix的文件系统。但有一点问题，它还是不能解决单点故障的问题。开发语言perl,可跨平台操作。
pNFS（pnfs）
网络文件系统(Network FileSystem,NFS)是大多数局域网(LAN）的重要的组成部分。但NFS不适用于高性能计算中苛刻的输入书橱密集型程序，至少以前是这样。NFS标准的罪行修改纳入了Parallel NFS(pNFS），它是文件共享的并行实现，将传输速率提高了几个数量级。
开发语言c/c++,运行在linu下。
googleFs
据说是一个比较不错的一个可扩展分布式文件系统，用于大型的，分布式的，对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能，它可以给大量的用户提供性能较高的服务。google自己开发的。

问题九：分布式存储都有哪些，并阐述其基本实现原理 神州云科 DCN NCS DFS2000（简称DFS2000）系列是面向大数据的存储系统，采用分布式架构，真正的分布式、全对称群集体系结构，将模块化存储节点与数据和存储管理软件相结合，跨节点的客户端连接负载均衡，自动平衡容量和性能，优化集群资源，3-144节点无缝扩展，容量、性能岁节点增加而线性增长，在 60 秒钟内添加一个节点以扩展性能和容量。

问题十：linux 分布式系统都有哪些？ 常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。
GFS（Google File System）
--------------------------------------
Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。
下面分布式文件系统都是类 GFS的产品。
HDFS
--------------------------------------
Hadoop 实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。 Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapRece算法的一种开源应用，是Google开创其帝国的重要基石。
Ceph
---------------------------------------
是加州大学圣克鲁兹分校的Sage weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。
说 ceph 性能最高，C++编写的代码，支持Fuse，并且没有单点故障依赖， 于是下载安装， 由于 ceph 使用 btrfs 文件系统， 而btrfs 文件系统需要 Linux 2.6.34 以上的内核才支持。
可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。
Lustre
---------------------------------------
Lustre是一个大规模的、安全可靠的，具备高可用性的集群文件系统，它是由SUN公司开发和维护的。
该项目主要的目的就是开发下一代的集群文件系统，可以支持超过10000个节点，数以PB的数据量存储系统。
目前Lustre已经运用在一些领域，例如HP SFS产品等。

‘贰’ 分布式存储的优点有哪些

分布式存储的六大优点
分布式存储往往采用分布式的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，将通用硬件引入的不稳定因素降到最低。优点如下：

1. 高性能

一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度;一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。

2. 支持分级存储

由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。

3. 一致性

与传统的存储架构使用RAID模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带、分布式校验等方式满足租户对于可靠性不同的需求。在读取数据失败的时候，系统可以通过从其他副本读取数据，重新写入该副本进行恢复，从而保证副本的总数固定;当数据长时间处于不一致状态时，系统会自动数据重建恢复，同时租户可设定数据恢复的带宽规则，最小化对业务的影响。

4. 容灾性

在分布式存储的容灾中，一个重要的手段就是多时间点快照技术，使得用户生产系统能够实现一定时间间隔下的各版本数据的保存。特别值得一提的是，多时间点快照技术支持同时提取多个时间点样本同时恢复，这对于很多逻辑错误的灾难定位十分有用，如果用户有多台服务器或虚拟机可以用作系统恢复，通过比照和分析，可以快速找到哪个时间点才是需要回复的时间点，降低了故障定位的难度，缩短了定位时间。这个功能还非

5. 扩展性

6. 存储系统标准化

‘叁’ java几种缓存技术介绍说明

1、TreeCache / JBossCache

JBossCache是一个复制的事务处理缓存，它允许你缓存企业级应用数据来更好的改善性能。缓存数据被自动复制，让你轻松进行JBoss服务器之间 的集群工作。JBossCache能够通过JBoss应用服务或其他J2EE容器来运行一个MBean服务，当然，它也能独立运行。

2、WhirlyCache

Whirlycache是一个快速的、可配置的、存在于内存中的对象的缓存。它能够通过缓存对象来加快网站或应用程序的速度，否则就必须通过查询数据库或其他代价较高的处理程序来建立。

3、SwarmCache

SwarmCache是一个简单且有效的分布式缓存，它使用IP multicast与同一个局域网的其他主机进行通讯，是特别为集群和数据驱动web应用程序而设计的。SwarmCache能够让典型的读操作大大超过写操作的这类应用提供更好的性能支持。

4、JCache

JCache是个开源程序，正在努力成为JSR-107开源规范，JSR-107规范已经很多年没改变了。这个版本仍然是构建在最初的功能定义上。

5、ShiftOne

ShiftOne Java Object Cache是一个执行一系列严格的对象缓存策略的Java lib，就像一个轻量级的配置缓存工作状态的框架。

‘肆’ 分布式存储是什么

什么是分布式存储系统？
就是将数据分散存储在多 *** 立的设备上
分布式存储是什么？选择什么样的分布式存储更好？
分布式存储系统，是将数据分散存储在多 *** 立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

联想超融合ThinkCloud AIO超融合云一体机是联想针对企业级用户推出的核心产品。ThinkCloud AIO超融合云一体机实现了对云管理平台、计算、网络和存储系统的无缝集成，构建了云计算基础设施即服务的一站式解决方案，为用户提供了一个高度简化的一站式基础设施云平台。这不仅使得业务部署上线从周缩短到天，而且与企业应用软件、中间件及数据库软件完全解耦，能够有效提升企业IT基础设施运维管理的效率和关键应用的性能
什么是分布式数据存储
定义：

分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式架构发展，基于关系型的分布式数据库在保留了传统数据库的数据模型和基本特征下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。

特点：

1.高可扩展性：分布式数据库必须具有高可扩展性，能够动态地增添存储节点以实现存储容量的线性扩展。

2 高并发性：分布式数据库必须及时响应大规模用户的读/写请求，能对海量数据进行随机读/写。

3. 高可用性：分布式数据库必须提供容错机制，能够实现对数据的冗余备份，保证数据和服务的高度可靠性。
分布式块存储和 分布式文件存储有是什么区别
分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元组的schema，存入取出删除的粒度较小。

分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。
统一存储和融合存储以及分布式存储的区别
统一存储具体概念：

统一存储，实质上是一个可以支持基于文件的网络附加存储（NAS）以及基于数据块的SAN的网络化的存储架构。由于其支持不同的存储协议为主机系统提供数据存储，因此也被称为多协议存储。

基本简介：

统一存储（有时也称网络统一存储或者NUS）是一个能在单一设备上运行和管理文件和应用程序的存储系统。为此，统一存储系统在一个单一存储平台上整合基于文件和基于块的访问，支持基于光纤通道的SAN、基于IP的SAN（iSCSI）和NAS（网络附加存储）。

工作方式：

既然是一个集中化的磁盘阵列，那么就支持主机系统通过IP网络进行文件级别的数据访问，或通过光纤协议在SAN网络进行块级别的数据访问。同样，iSCSI亦是一种非常通用的IP协议，只是其提供块级别的数据访问。这种磁盘阵列配置多端口的存储控制器和一个管理接口，允许存储管理员按需创建存储池或空间，并将其提供给不同访问类型的主机系统。最通常的协议一般都包括了NAS和FC，或iSCSI和FC。当然，也可以同时支持上述三种协议的，不过一般的存储管理员都会选FC或iSCSI中的一种，它们都提供块级别的访问方式，和文件级别的访问方式（NAS方式）组成统一存储。
分布式存储支持多节点，节点是什么，一个磁盘还是一个主控？
一个节点是存储节点的简称，存储节点一般是一个存储服务器（必然带控制器），服务器之间通过高速网络互连。

现在越来越多的存储服务器使用arm CPU+磁盘阵列节省能耗，提高“容量能耗比”。
分布式文件系统有哪些主要的类别？
分布式存储在大数据、云计算、虚拟化场景都有勇武之地，在大部分场景还至关重要。munity.emc/message/655951 下面简要介绍*nix平台下分布式文件系统的发展历史：

1、单机文件系统

用于操作系统和应用程序的本地存储。

2、网络文件系统（简称：NAS）

基于现有以太网架构，实现不同服务器之间传统文件系统数据共享。

3、集群文件系统

在共享存储基础上，通过集群锁，实现不同服务器能够共用一个传统文件系统。

4、分布式文件系统

在传统文件系统上，通过额外模块实现数据跨服务器分布，并且自身集成raid保护功能，可以保证多台服务器同时访问、修改同一个文件系统。性能优越，扩展性很好，成本低廉。
分布式存储都有哪些，并阐述其基本实现原理
神州云科 DCN NCS DFS2000（简称DFS2000）系列是面向大数据的存储系统，采用分布式架构，真正的分布式、全对称群集体系结构，将模块化存储节点与数据和存储管理软件相结合，跨节点的客户端连接负载均衡，自动平衡容量和性能，优化集群资源，3-144节点无缝扩展，容量、性能岁节点增加而线性增长，在 60 秒钟内添加一个节点以扩展性能和容量。
什么是Hadoop分布式文件系统 10分
分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通浮计算机网络与节点相连。

Hadoop是Apache软件基金会所研发的开放源码并行运算编程工具和分散式档案系统，与MapRece和Google档案系统的概念类似。

HDFS（Hadoop 分布式文件系统）是其中的一部分。
分布式文件存储系统采用什么方式
一。分布式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才能正常 工作 。如果客户端完全禁止cookie，session将失效。是无状态的协议，客户每次读取web页面时，服务器都打开新的会话......

‘伍’ 分布式存储有什么好

分布式存储，它的最大特点是多节点部署， 数据通过网络分散放置。分布式存储的特点是扩展性强，通过多节点平衡负载，提高存储系统的可靠性与可用性。

‘陆’ 如何保证数据库缓存的最终一致性

对于互联网业务来说，传统的直接访问数据库方式，主要通过数据分片、一主多从等方式来扛住读写流量，但随着数据量的积累和流量的激增，仅依赖数据库来承接所有流量，不仅成本高、效率低、而且还伴随着稳定性降低的风险。

鉴于大部分业务通常是读多写少（读取频率远远高于更新频率），甚至存在读操作数量高出写操作多个数量级的情况。因此， 在架构设计中，常采用增加缓存层来提高系统的响应能力 ，提升数据读写性能、减少数据库访问压力，从而提升业务的稳定性和访问体验。

根据 CAP 原理，分布式系统在可用性、一致性和分区容错性上无法兼得，通常由于分区容错无法避免，所以一致性和可用性难以同时成立。对于缓存系统来说， 如何保证其数据一致性是一个在应用缓存的同时不得不解决的问题 。

需要明确的是，缓存系统的数据一致性通常包括持久化层和缓存层的一致性、以及多级缓存之间的一致性，这里我们仅讨论前者。持久化层和缓存层的一致性问题也通常被称为双写一致性问题，“双写”意为数据既在数据库中保存一份，也在缓存中保存一份。

对于一致性来说，包含强一致性和弱一致性 ，强一致性保证写入后立即可以读取，弱一致性则不保证立即可以读取写入后的值，而是尽可能的保证在经过一定时间后可以读取到，在弱一致性中应用最为广泛的模型则是最终一致性模型，即保证在一定时间之后写入和读取达到一致的状态。对于应用缓存的大部分场景来说，追求的则是最终一致性，少部分对数据一致性要求极高的场景则会追求强一致性。

为了达到最终一致性，针对不同的场景，业界逐步形成了下面这几种应用缓存的策略。

— 1 —

Cache-Aside

Cache-Aside 意为旁路缓存模式，是应用最为广泛的一种缓存策略。下面的图示展示了它的读写流程，来看看它是如何保证最终一致性的。在读请求中，首先请求缓存，若缓存命中（cache hit），则直接返回缓存中的数据；若缓存未命中（cache miss），则查询数据库并将查询结果更新至缓存，然后返回查询出的数据（demand-filled look-aside ）。在写请求中，先更新数据库，再删除缓存（write-invalidate）。

1、为什么删除缓存，而不是更新缓存？

在 Cache-Aside 中，对于读请求的处理比较容易理解，但在写请求中，可能会有读者提出疑问，为什么要删除缓存，而不是更新缓存？站在符合直觉的角度来看，更新缓存是一个容易被理解的方案，但站在性能和安全的角度，更新缓存则可能会导致一些不好的后果。

首先是性能 ，当该缓存对应的结果需要消耗大量的计算过程才能得到时，比如需要访问多张数据库表并联合计算，那么在写操作中更新缓存的动作将会是一笔不小的开销。同时，当写操作较多时，可能也会存在刚更新的缓存还没有被读取到，又再次被更新的情况（这常被称为缓存扰动），显然，这样的更新是白白消耗机器性能的，会导致缓存利用率不高。

而等到读请求未命中缓存时再去更新，也符合懒加载的思路，需要时再进行计算。删除缓存的操作不仅是幂等的，可以在发生异常时重试，而且写-删除和读-更新在语义上更加对称。

其次是安全 ，在并发场景下，在写请求中更新缓存可能会引发数据的不一致问题。参考下面的图示，若存在两个来自不同线程的写请求，首先来自线程 1 的写请求更新了数据库（step 1），接着来自线程 2 的写请求再次更新了数据库（step 3），但由于网络延迟等原因，线程 1 可能会晚于线程 2 更新缓存（step 4 晚于 step 3），那么这样便会导致最终写入数据库的结果是来自线程 2 的新值，写入缓存的结果是来自线程 1 的旧值，即缓存落后于数据库，此时再有读请求命中缓存（step 5），读取到的便是旧值。

2、为什么先更新数据库，而不是先删除缓存？

另外，有读者也会对更新数据库和删除缓存的时序产生疑问，那么为什么不先删除缓存，再更新数据库呢？在单线程下，这种方案看似具有一定合理性，这种合理性体现在删除缓存成功。

但更新数据库失败的场景下，尽管缓存被删除了，下次读操作时，仍能将正确的数据写回缓存，相对于 Cache-Aside 中更新数据库成功，删除缓存失败的场景来说，先删除缓存的方案似乎更合理一些。那么，先删除缓存有什么问题呢？

问题仍然出现在并发场景下，首先来自线程 1 的写请求删除了缓存（step 1），接着来自线程 2 的读请求由于缓存的删除导致缓存未命中，根据 Cache-Aside 模式，线程 2 继而查询数据库（step 2），但由于写请求通常慢于读请求，线程 1 更新数据库的操作可能会晚于线程 2 查询数据库后更新缓存的操作（step 4 晚于 step 3），那么这样便会导致最终写入缓存的结果是来自线程 2 中查询到的旧值，而写入数据库的结果是来自线程 1 的新值，即缓存落后于数据库，此时再有读请求命中缓存（ step 5 ），读取到的便是旧值。

另外，先删除缓存，由于缓存中数据缺失，加剧数据库的请求压力，可能会增大缓存穿透出现的概率。

3、如果选择先删除缓存，再更新数据库，那如何解决一致性问题呢？

为了避免“先删除缓存，再更新数据库”这一方案在读写并发时可能带来的缓存脏数据，业界又提出了延时双删的策略，即在更新数据库之后，延迟一段时间再次删除缓存，为了保证第二次删除缓存的时间点在读请求更新缓存之后，这个延迟时间的经验值通常应稍大于业务中读请求的耗时。

延迟的实现可以在代码中 sleep 或采用延迟队列。显而易见的是，无论这个值如何预估，都很难和读请求的完成时间点准确衔接，这也是延时双删被诟病的主要原因。

4、那么 Cache-Aside 存在数据不一致的可能吗？

在 Cache-Aside 中，也存在数据不一致的可能性。在下面的读写并发场景下，首先来自线程 1 的读请求在未命中缓存的情况下查询数据库（step 1），接着来自线程 2 的写请求更新数据库（step 2），但由于一些极端原因，线程 1 中读请求的更新缓存操作晚于线程 2 中写请求的删除缓存的操作（step 4 晚于 step 3），那么这样便会导致最终写入缓存中的是来自线程 1 的旧值，而写入数据库中的是来自线程 2 的新值，即缓存落后于数据库，此时再有读请求命中缓存（step 5），读取到的便是旧值。

这种场景的出现，不仅需要缓存失效且读写并发执行，而且还需要读请求查询数据库的执行早于写请求更新数据库，同时读请求的执行完成晚于写请求。足以见得，这种 不一致场景产生的条件非常严格，在实际的生产中出现的可能性较小 。

除此之外，在并发环境下，Cache-Aside 中也存在读请求命中缓存的时间点在写请求更新数据库之后，删除缓存之前，这样也会导致读请求查询到的缓存落后于数据库的情况。

虽然在下一次读请求中，缓存会被更新，但如果业务层面对这种情况的容忍度较低，那么可以采用加锁在写请求中保证“更新数据库&删除缓存”的串行执行为原子性操作（同理也可对读请求中缓存的更新加锁）。 加锁势必会导致吞吐量的下降，故采取加锁的方案应该对性能的损耗有所预期。

— 2 —

补偿机制

我们在上面提到了，在 Cache-Aside 中可能存在更新数据库成功，但删除缓存失败的场景，如果发生这种情况，那么便会导致缓存中的数据落后于数据库，产生数据的不一致的问题。

其实，不仅 Cache-Aside 存在这样的问题，在延时双删等策略中也存在这样的问题。针对可能出现的删除失败问题，目前业界主要有以下几种补偿机制。

1、删除重试机制

由于同步重试删除在性能上会影响吞吐量，所以常通过引入消息队列，将删除失败的缓存对应的 key 放入消息队列中，在对应的消费者中获取删除失败的 key ，异步重试删除。这种方法在实现上相对简单，但由于删除失败后的逻辑需要基于业务代码的 trigger 来触发 ，对业务代码具有一定入侵性。

鉴于上述方案对业务代码具有一定入侵性，所以需要一种更加优雅的解决方案，让缓存删除失败的补偿机制运行在背后，尽量少的耦合于业务代码。一个简单的思路是通过后台任务使用更新时间戳或者版本作为对比获取数据库的增量数据更新至缓存中，这种方式在小规模数据的场景可以起到一定作用，但其扩展性、稳定性都有所欠缺。

一个相对成熟的方案是基于 Mysql 数据库增量日志进行解析和消费，这里较为流行的是阿里巴巴开源的作为 MySQL binlog 增量获取和解析的组件 canal（类似的开源组件还有 Maxwell、Databus 等）。

canal sever 模拟 MySQL slave 的交互协议，伪装为 MySQL slave，向 MySQL master 发送 mp 协议，MySQL master 收到 mp 请求，开始推送 binary log 给 slave （即 canal sever ），canal sever 解析 binary log 对象（原始为 byte 流），可由 canal client 拉取进行消费，同时 canal server 也默认支持将变更记录投递到 MQ 系统中，主动推送给其他系统进行消费。

在 ack 机制的加持下，不管是推送还是拉取，都可以有效的保证数据按照预期被消费。当前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依赖 ZooKeeper 作为分布式协调组件来实现 HA ，canal 的 HA 分为两个部分：

那么，针对缓存的删除操作便可以在 canal client 或 consumer 中编写相关业务代码来完成。这样，结合数据库日志增量解析消费的方案以及 Cache-Aside 模型，在读请求中未命中缓存时更新缓存（通常这里会涉及到复杂的业务逻辑），在写请求更新数据库后删除缓存，并基于日志增量解析来补偿数据库更新时可能的缓存删除失败问题，在绝大多数场景下，可以有效的保证缓存的最终一致性。

另外需要注意的是，还应该隔离事务与缓存，确保数据库入库后再进行缓存的删除操作。 比如考虑到数据库的主从架构，主从同步及读从写主的场景下，可能会造成读取到从库的旧数据后便更新了缓存，导致缓存落后于数据库的问题，这就要求对缓存的删除应该确保在数据库操作完成之后。所以，基于 binlog 增量日志进行数据同步的方案，可以通过选择解析从节点的 binlog，来避免主从同步下删除缓存过早的问题。

3、数据传输服务 DTS

— 3 —

Read-Through

Read-Through 意为读穿透模式，它的流程和 Cache-Aside 类似，不同点在于 Read-Through 中多了一个访问控制层，读请求只和该访问控制层进行交互，而背后缓存命中与否的逻辑则由访问控制层与数据源进行交互，业务层的实现会更加简洁，并且对于缓存层及持久化层交互的封装程度更高，更易于移植。

— 4 —

Write-Through

Write-Through 意为直写模式，对于 Write-Through 直写模式来说，它也增加了访问控制层来提供更高程度的封装。不同于 Cache-Aside 的是，Write-Through 直写模式在写请求更新数据库之后，并不会删除缓存，而是更新缓存。

这种方式的 优势在于读请求过程简单 ，不需要查询数据库更新缓存等操作。但其劣势也非常明显，除了上面我们提到的更新数据库再更新缓存的弊端之外，这种方案还会造成更新效率低，并且两个写操作任何一次写失败都会造成数据不一致。

如果要使用这种方案， 最好可以将这两个操作作为事务处理，可以同时失败或者同时成功，支持回滚，并且防止并发环境下的不一致 。另外，为了防止缓存扰动的频发，也可以给缓存增加 TTL 来缓解。

站在可行性的角度，不管是 Write-Through 模式还是 Cache-Aside 模式，理想状况下都可以通过分布式事务保证缓存层数据与持久化层数据的一致性，但在实际项目中，大多都对一致性的要求存在一些宽容度，所以在方案上往往有所折衷。

Write-Through 直写模式适合写操作较多，并且对一致性要求较高的场景，在应用 Write-Through 模式时，也需要通过一定的补偿机制来解决它的问题。首先，在并发环境下，我们前面提到了先更新数据库，再更新缓存会导致缓存和数据库的不一致，那么先更新缓存，再更新数据库呢？

这样的操作时序仍然会导致下面这样线程 1 先更新缓存，最后更新数据库的情况，即由于线程 1 和 线程 2 的执行不确定性导致数据库和缓存的不一致。这种由于线程竞争导致的缓存不一致，可以通过分布式锁解决，保证对缓存和数据库的操作仅能由同一个线程完成。对于没有拿到锁的线程，一是通过锁的 timeout 时间进行控制，二是将请求暂存在消息队列中顺序消费。

在下面这种并发执行场景下，来自线程 1 的写请求更新了数据库，接着来自线程 2 的读请求命中缓存，接着线程 1 才更新缓存，这样便会导致线程 2 读取到的缓存落后于数据库。同理，先更新缓存后更新数据库在写请求和读请求并发时，也会出现类似的问题。面对这种场景，我们也可以加锁解决。

另在，在 Write-Through 模式下，不管是先更新缓存还是先更新数据库，都存在更新缓存或者更新数据库失败的情况，上面提到的重试机制和补偿机制在这里也是奏效的。

— 5 —

Write-Behind

Write behind 意为异步回写模式，它也具有类似 Read-Through/Write-Through 的访问控制层，不同的是，Write behind 在处理写请求时，只更新缓存而不更新数据库，对于数据库的更新，则是通过批量异步更新的方式进行的，批量写入的时间点可以选在数据库负载较低的时间进行。

在 Write-Behind 模式下，写请求延迟较低，减轻了数据库的压力，具有较好的吞吐性。但数据库和缓存的一致性较弱，比如当更新的数据还未被写入数据库时，直接从数据库中查询数据是落后于缓存的。同时，缓存的负载较大，如果缓存宕机会导致数据丢失，所以需要做好缓存的高可用。显然，Write behind 模式下适合大量写操作的场景，常用于电商秒杀场景中库存的扣减。

— 6 —

Write-Around

如果一些非核心业务，对一致性的要求较弱，可以选择在 cache aside 读模式下增加一个缓存过期时间，在写请求中仅仅更新数据库，不做任何删除或更新缓存的操作，这样，缓存仅能通过过期时间失效。这种方案实现简单，但缓存中的数据和数据库数据一致性较差，往往会造成用户的体验较差，应慎重选择。

— 7 —

总结

在解决缓存一致性的过程中，有多种途径可以保证缓存的最终一致性，应该根据场景来设计合适的方案，读多写少的场景下，可以选择采用“Cache-Aside 结合消费数据库日志做补偿”的方案，写多的场景下，可以选择采用“Write-Through 结合分布式锁”的方案 ，写多的极端场景下，可以选择采用“Write-Behind”的方案。

‘柒’ EhCache 分布式缓存/缓存集群

一 缓存系统简介 EhCache 是一个纯 Java 的进程内缓存框架 具有快速 精干等特点 是 Hibernate 中默认的 CacheProvider 键源 EhCache 应用架构图 下图是 EhCache 在应用程序中的位置

EhCache 的主要特性有 快速 精干 简单 多种缓存策略 缓存数据有两级 内存和磁盘 因此无需担心容量问题 缓存数据会在虚稿亮态拟机重启的过程中写入磁盘 可以通过 RMI 可插入 API 等方式进行分布式缓存 具有缓存和缓存管理器的侦听接口 支持多缓存管理器实例 以及一个实例的多个缓存区域 提供 Hibernate 的缓存实现 由于 EhCache 是进程中的缓存系统 一旦将应用部署在集群环境中 每一个节点维护各自的缓存数据 当某个节点对缓存数据进行更新 这些更新的数据无法在其它节点 *** 享 这不仅会降低节点运行的效率 而且会导致数据不同步的情况发生 例如某个网站采用 A B 两个节点作为集群部署 当 A 节点的缓存更新后 而 B 节点缓存尚未更新就可能出现用户在浏览页面的时候 一会是更新后的数据 一会是尚未更新的数据 尽管我们也可以通过 Session Sticky 技术来将用户锁定在某个节点上 但对于一些交互性比较强或者是非 Web 方式的系统来说 Session Sticky 显然不太适合 所以就需要用到 EhCache 的集群解决方案 从 版本开始 Ehcache可以使用分布式的缓存了 EhCache 从 版本开始 支持五种集群方案 分别是 ? Terracotta ? RMI ? JMS ? JGroups ? EhCache Server 其中的三种最为常用集群方式 分别是 RMI JGroups 以及 EhCache Server 本文主要介绍RMI的方式 分布式这个特性是以plugin的方键歼式实现的 Ehcache自带了一些默认的分布式缓存插件实现 这些插件可以满足大部分应用的需要 如果需要使用其他的插件那就需要自己开发了 开发者可以通过查看distribution包里的源代码及JavaDoc来实现它 尽管不是必须的 在使用分布式缓存时理解一些ehcahce的设计思想也是有帮助的 这可以参看分布式缓存设计的页面 以下的部分将展示如何让分布式插件同ehcache一起工作 下面列出的是一些分布式缓存中比较重要的方面 ? 你如何知道集群环境中的其他缓存？ ? 分布式传送的消息是什么形式？ ? 什么情况需要进行复制？增加（Puts） 更新（Updates）或是失效（Expiries）？ ? 采用什么方式进行复制？同步还是异步方式？ 为了安装分布式缓存 你需要配置一个PeerProvider 一个CacheManagerPeerListener 它们对于一个CacheManager来说是全局的 每个进行分布式操作的cache都要添加一个cacheEventListener来传送消息

二 集群缓存概念及其配置 正确的元素类型 只有可序列化的元素可以进行复制 一些操作 比如移除 只需要元素的键值而不用整个元素 在这样的操作中即使元素不是可序列化的但键值是可序列化的也可以被复制 成员发现（Peer Discovery） Ehcache进行集群的时候有一个cache组的概念 每个cache都是其他cache的一个peer 没有主cache的存在 刚才我们问了一个问题 你如何知道集群环境中的其他缓存？这个问题可以命名为成员发现（Peer Discovery） Ehcache提供了两种机制用来进行成员发现 就像一辆汽车 手动档和自动档 要使用一个内置的成员发现机制要在ehcache的配置文件中指定元素的class属性为 net sf ehcache distribution 自动的成员发现 自动的发现方式用TCP广播机制来确定和维持一个广播组 它只需要一个简单的配置可以自动的在组中添加和移除成员 在集群中也不需要什么优化服务器的知识 这是默认推荐的 成员每秒向群组发送一个 心跳 如果一个成员 秒种都没有发出信号它将被群组移除 如果一个新的成员发送了一个 心跳 它将被添加进群组 任何一个用这个配置安装了复制功能的cache都将被其他的成员发现并标识为可用状态 要设置自动的成员发现 需要指定ehcache配置文件中元素的properties属性 就像下面这样 peerDiscovery=automatic multicastGroupAddress=multicast address | multicast host name multicastGroupPort=port timeToLive= （timeToLive属性详见常见问题部分的描述） 示例 假设你在集群中有两台服务器 你希望同步sampleCache 和sampleCache 每台独立的服务器都要有这样的配置 配置server 和server <class= net sf ehcache distribution properties= peerDiscovery=automatic multicastGroupAddress= />multicastGroupPort= timeToLive= 手动进行成员发现 进行手动成员配置要知道每个监听器的IP地址和端口 成员不能在运行时动态地添加和移除 在技术上很难使用广播的情况下就可以手动成员发现 例如在集群的服务器之间有一个不能传送广播报文的路由器 你也可以用手动成员发现进行单向的数据复制 只让server 知道server 而server 不知道server 配置手动成员发现 需要指定ehcache配置文件中的properties属性 像下面这样 peerDiscovery=manual rmiUrls=//server:port/cacheName //server:port/cacheName … rmiUrls配置的是服务器cache peers的列表 注意不要重复配置 示例 假设你在集群中有两台服务器 你要同步sampleCache 和sampleCache 下面是每个服务器需要的配置 配置server <class= net sf ehcache distribution properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置server <class= net sf ehcache distribution properties= peerDiscovery=manual />rmiUrls=//server : /sampleCache |//server : /sampleCache 配置CacheManagerPeerListener 每个CacheManagerPeerListener监听从成员们发向当前CacheManager的消息 配置CacheManagerPeerListener需要指定一个 它以插件的机制实现 用来创建CacheManagerPeerListener 的属性有 class – 一个完整的工厂类名 properties – 只对这个工厂有意义的属性 使用逗号分隔 Ehcache有一个内置的基于RMI的分布系统 它的监听器是RMICacheManagerPeerListener 这个监听器可以用 RMI来配置 <class= net sf ehcache distribution RMI properties= hostName=localhost port= />socketTimeoutMillis= 有效的属性是 hostname （可选） – 运行监听器的服务器名称 标明了做为集群群组的成员的地址 同时也是你想要控制的从集群中接收消息的接口

在CacheManager初始化的时候会检查hostname是否可用 如果hostName不可用 CacheManager将拒绝启动并抛出一个连接被拒绝的异常 如果指定 hostname将使用InetAddress getLocalHost（） getHostAddress（）来得到 警告 不要将localhost配置为本地地址 因为它在网络中不可见将会导致不能从远程服务器接收信息从而不能复制 在同一台机器上有多个CacheManager的时候 你应该只用localhost来配置 port – 监听器监听的端口 socketTimeoutMillis （可选） – Socket超时的时间 默认是 ms 当你socket同步缓存请求地址比较远 不是本地局域网 你可能需要把这个时间配置大些 不然很可能延时导致同步缓存失败 配置CacheReplicators 每个要进行同步的cache都需要设置一个用来向CacheManagerr的成员复制消息的缓存事件监听器 这个工作要通过为每个cache的配置增加一个cacheEventListenerFactory元素来完成 <! Sample cache named sampleCache ><cache name= sampleCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true /></cache>class – 使用net sf ehcache distribution RMICacheReplicatorFactory 这个工厂支持以下属性 replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers 默认是true replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制 默认是true replicateRemovals= true | false – 当元素移除的时候是否进行复制 默认是true replicateAsynchronously=true | false – 复制方式是异步的（指定为true时）还是同步的（指定为false时） 默认是true replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制指定为true时为复制 默认是true replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制（指定为true时为复制） 默认是true 你可以使用ehcache的默认行为从而减少配置的工作量 默认的行为是以异步的方式复制每件事 你可以像下面的例子一样减少RMICacheReplicatorFactory的属性配置 <! Sample cache named sampleCache All missing RMICacheReplicatorFactory properties default to true ><cache name= sampleCache maxElementsInMemory= eternal= true overflowToDisk= false memoryStoreEvictionPolicy= LFU ><cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory /></cache> 常见的问题 Windows上的Tomcat 有一个Tomcat或者是JDK的bug 在tomcat启动时如果tomcat的安装路径中有空格的话 在启动时RMI监听器会失败 参见 bin/wa?A =ind &L=rmi users&P= 和 doc/faq howto bugs/l 由于在Windows上安装Tomcat默认是装在 Program Files 文件夹里的 所以这个问题经常发生 广播阻断 自动的peer discovery与广播息息相关 广播可能被路由阻拦 像Xen和VMWare这种虚拟化的技术也可以阻拦广播 如果这些都打开了 你可能还在要将你的网卡的相关配置打开 一个简单的办法可以告诉广播是否有效 那就是使用ehcache remote debugger来看 心跳 是否可用 广播传播的不够远或是传得太远 你可以通过设置badly misnamed time to live来控制广播传播的距离 用广播IP协议时 timeToLive的值指的是数据包可以传递的域或是范围 约定如下 是限制在同一个服务器 是限制在同一个子网 是限制在同一个网站 是限制在同一个region 是限制在同一个大洲 是不限制 译者按 上面这些资料翻译的不够准确 请读者自行寻找原文理解吧 在Java实现中默认值是 也就是在同一个子网中传播 改变timeToLive属性可以限制或是扩展传播的范围

三 RMI方式缓存集群/配置分布式缓存 RMI 是 Java 的一种远程方法调用技术 是一种点对点的基于 Java 对象的通讯方式 EhCache 从 版本开始就支持 RMI 方式的缓存集群 在集群环境中 EhCache 所有缓存对象的键和值都必须是可序列化的 也就是必须实现 java io Serializable 接口 这点在其它集群方式下也是需要遵守的 下图是 RMI 集群模式的结构图

采用 RMI 集群模式时 集群中的每个节点都是对等关系 并不存在主节点或者从节点的概念 因此节点间必须有一个机制能够互相认识对方 必须知道其它节点的信息 包括主机地址 端口号等 EhCache 提供两种节点的发现方式 手工配置和自动发现 手工配置方式要求在每个节点中配置其它所有节点的连接信息 一旦集群中的节点发生变化时 需要对缓存进行重新配置 由于 RMI 是 Java 中内置支持的技术 因此使用 RMI 集群模式时 无需引入其它的 Jar 包 EhCache 本身就带有支持 RMI 集群的功能 使用 RMI 集群模式需要在 ehcache xml 配置文件中定义 节点 分布式同步缓存要让这边的cache知道对方的cache 叫做Peer Discovery（成员发现） EHCache实现成员发现的方式有两种 手动查找 A 在ehcache xml中配置PeerDiscovery成员发现对象 Server 配置 配置本地hostName port是 分别监听 : 的mobileCache和 : 的mobileCache 注意这里的mobileCache是缓存的名称 分别对应着server server 的cache的配置 <?xml version= encoding= gbk ?><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd > <diskStore path= java io tmpdir /> <! 集群多台服务器中的缓存 这里是要同步一些服务器的缓存 server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache 注意 每台要同步缓存的服务器的RMI通信socket端口都不一样 在配置的时候注意设置 > <! server 的配置 > < class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache /></ehcache>以上注意元素出现的位置在diskStore下

同样在你的另外 台服务器上增加配置 Server 配置本地host port为 分别同步 : 的mobileCache和 : 的mobileCache <! server 的配置 >< class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache />Server 配置本地host port为 分别同步 : 的mobileCache缓存和 : 的mobileCache缓存 <! server 的配置 >< class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache />这样就在三台不同的服务器上配置了手动查找cache的PeerProvider成员发现的配置了 值得注意的是你在配置rmiUrls的时候要特别注意url不能重复出现 并且端口 地址都是对的 如果指定 hostname将使用InetAddress getLocalHost（） getHostAddress（）来得到 警告 不要将localhost配置为本地地址 因为它在网络中不可见将会导致不能从远程服务器接收信息从而不能复制 在同一台机器上有多个CacheManager的时候 你应该只用localhost来配置 B 下面配置缓存和缓存同步监听 需要在每台服务器中的ehcache xml文件中增加cache配置和cacheEventListenerFactory cacheLoaderFactory的配置 <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /><! 配置自定义缓存 maxElementsInMemory:缓存中允许创建的最大对象数 eternal:缓存中对象是否为永久的 如果是 超时设置将被忽略 对象从不过期 timeToIdleSeconds:缓存数据空闲的最大时间 也就是说如果有一个缓存有多久没有被访问就会被销毁 如果该值是 就意味着元素可以停顿无穷长的时间 timeToLiveSeconds:缓存数据存活的时间 缓存对象最大的的存活时间 超过这个时间就会被销毁 这只能在元素不是永久驻留时有效 如果该值是 就意味着元素可以停顿无穷长的时间 overflowToDisk:内存不足时 是否启用磁盘缓存 memoryStoreEvictionPolicy:缓存满了之后的淘汰算法 每一个小时更新一次缓存（ 小时过期） ><cache name= mobileCache maxElementsInMemory= eternal= false overflowToDisk= true timeToIdleSeconds= timeToLiveSeconds= memoryStoreEvictionPolicy= LFU > <! RMI缓存分布同步查找 class使用net sf ehcache distribution RMICacheReplicatorFactory 这个工厂支持以下属性 replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers 默认是true replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制 默认是true replicateRemovals= true | false – 当元素移除的时候是否进行复制 默认是true replicateAsynchronously=true | false – 复制方式是异步的 指定为true时 还是同步的 指定为false时 默认是true replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true = > <! 监听RMI同步缓存对象配置 注册相应的的缓存监听类 用于处理缓存事件 如put remove update 和expire > <cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true /> replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true <! 用于在初始化缓存 以及自动设置 > <bootstrapCacheLoaderFactory class= net sf ehcache bootstrap BootstrapCacheLoaderFactory /></cache> C 这样就完成了 台服务器的配置 下面给出server 的完整的ehcache xml的配置 <?xml version= encoding= gbk ?><ehcache xmlns:xsi= instance xsi:noNamespaceSchemaLocation= ehcache xsd > <diskStore path= java io tmpdir /> <!

集群多台服务器中的缓存 这里是要同步一些服务器的缓存 server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache server hostName: port: cacheName:mobileCache 注意每台要同步缓存的服务器的RMI通信socket端口都不一样 在配置的时候注意设置 > <! server 的配置 > < class= net sf ehcache distribution properties= hostName=localhost port= socketTimeoutMillis= peerDiscovery=manual rmiUrls=// : /mobileCache|// : /mobileCache /> <defaultCache maxElementsInMemory= eternal= false timeToIdleSeconds= timeToLiveSeconds= overflowToDisk= false /> <! 配置自定义缓存 maxElementsInMemory:缓存中允许创建的最大对象数 eternal:缓存中对象是否为永久的 如果是 超时设置将被忽略 对象从不过期 timeToIdleSeconds:缓存数据空闲的最大时间 也就是说如果有一个缓存有多久没有被访问就会被销毁 如果该值是 就意味着元素可以停顿无穷长的时间 timeToLiveSeconds:缓存数据存活的时间 缓存对象最大的的存活时间 超过这个时间就会被销毁 这只能在元素不是永久驻留时有效 如果该值是 就意味着元素可以停顿无穷长的时间 overflowToDisk:内存不足时 是否启用磁盘缓存 memoryStoreEvictionPolicy:缓存满了之后的淘汰算法 每一个小时更新一次缓存（ 小时过期） > <cache name= mobileCache maxElementsInMemory= eternal= false overflowToDisk= true timeToIdleSeconds= timeToLiveSeconds= memoryStoreEvictionPolicy= LFU > <! RMI缓存分布同步查找 class使用net sf ehcache distribution RMICacheReplicatorFactory 这个工厂支持以下属性 replicatePuts=true | false – 当一个新元素增加到缓存中的时候是否要复制到其他的peers 默认是true replicateUpdates=true | false – 当一个已经在缓存中存在的元素被覆盖时是否要进行复制 默认是true replicateRemovals= true | false – 当元素移除的时候是否进行复制 默认是true replicateAsynchronously=true | false – 复制方式是异步的 指定为true时 还是同步的 指定为false时 默认是true replicatePutsViaCopy=true | false – 当一个新增元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true replicateUpdatesViaCopy=true | false – 当一个元素被拷贝到其他的cache中时是否进行复制 指定为true时为复制 默认是true = > <! 监听RMI同步缓存对象配置 注册相应的的缓存监听类 用于处理缓存事件 如put remove update 和expire > <cacheEventListenerFactory class= net sf ehcache distribution RMICacheReplicatorFactory properties= replicateAsynchronously=true /> replicatePuts=true replicateUpdates=true replicateUpdatesViaCopy=false replicateRemovals=true <! 用于在初始化缓存 以及自动设置 > <bootstrapCacheLoaderFactory class= net sf ehcache bootstrap BootstrapCacheLoaderFactory /> </cache></ehcache> 自动发现 自动发现配置和手动查找的方式有一点不同 其他的地方都基本是一样的 同样在ehcache xml中增加配置 配置如下 <! 搜索某个网段上的缓存timeToLive 是限制在同一个服务器 是限制在同一个子网 是限制在同一个网站 是限制在同一个region 是限制在同一个大洲 是不限制 >< class= net sf ehcache distribution properties= peerDiscovery=automatic multicastGroupAddress= multicastGroupPort= timeToLive= /> lishixin/Article/program/Java/hx/201311/25706

‘捌’ ehcache java 对象缓存怎么实现

1.技术背景：
系统缓存是位于应用程序与物理数据源之间，用于临时存放复制数据的内存区域，目的是为减少应用程序对物理数据源访问的次数，从而提高应用程序的运行性能。缓存设想内存是有限的，缓存的时效性也是有限的，所以可以设定内存数量的大小可以执行失效算法，可以在内存满了的情况下，按照最少访问等算法将缓存直接移除或切换到硬盘上。
Ehcache从Hibernate发展而来，逐渐涵盖了Cache界的全部功能，是目前发展势头最好的一个项目，具有快速、简单、低消耗、扩展性强、支持对象或序列化缓存，支持缓存或元素的失效，提供LRU、LFU和FIFO缓存策略，支持内存缓存和硬盘缓存和分布式缓存机制等特点。其中Cache的存储方式为内存或磁盘（ps：无须担心容量问题）
2.EhCahe的类层次介绍：
主要分为三层，最上层是CacheManager，它是操作Ehcache的入口。可以通过CacheManager.getInstance()获得一个单子的CacheManager，或者通过CacheManager的构造函数创建一个新的CacheManager。每个CacheManger都管理多个Cache。每个Cache都以一种类Hash的方式，关联多个Element。Element就是我们用于存放缓存内容的地方。
3.环境搭建：
很简单只需要将ehcache-2.1.0-distribution.tar.gz和ehcache-web-2.0.2-distribution.tar.gz挤压的jar包放入WEB-INF/lib下。
再创建一个重要的配置文件ehcache.xml，可以从ehcache组件包中拷贝一个，也可以自己建立一个，需要放到classpath下，一般放于/WEB-INF/classed/ehcache.xml；具体的配置文件可以网上搜一下
4.实际运用
一个网站的首页估计是被访问次数最多的，我们可以考虑给首页做一个页面缓存；
缓存策略：应该是某个固定时间之内不变的，比如说2分钟更新一次，以应用结构page-filter-action-service--db为例。
位置：页面缓存做到尽量靠近客户的地方，就是在page和filter之间，这样的优点就是第一个用户请求后，页面被缓存，第二个用户在请求，走到filter这个请求就结束了，需要在走到action-service--db，好处当然是服务器压力大大降低和客户端页面响应速度加快。
首页页面缓存存活时间定为2分钟，也就是参数timeToLiveSeconds（缓存的存活时间）应该设置为120，同时timeToIdleSeconds（多长时间不访问缓存，就清楚该缓存）最好也设为2分钟或者小于2分钟。

接着我们来看一下SimplePageCachingFilter的配置，

<filter>
<filter-name>indexCacheFilterfilter-name>
<filter-class>
net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter
<filter-class>
<filter>
<filter-mapping>
<filter-name>indexCacheFilterfilter-name>
<url-pattern>*index.actionurl-pattern>
<filter-mapping>

将上述代码加入到web.xml，那么当打开首页时，你会发现2分钟才会有一堆sql语句出现在控制台，也可以调整为5分钟，总之一切尽在掌控之中。

当然，如果你像缓存首页的部分内容时，你需要使用这个filter，我看一下：
<filter>
<filter-name>indexCacheFilterfilter-name>
<filter-class>
net.sf.ehcache.constructs.web.filter.
<filter-class>
filter>
<filter-mapping>
<filter-name>indexCacheFilterfilter-name>
<url-pattern>*/index_right.jsp<url-pattern>
<filter-mapping>

如此我们将jsp页面通过jsp：include到其他页面，这样就做到了页面局部缓存的效果，这一点貌似没有oscache的tag好用。

此外cachefilter中还有一个特性，就是gzip，也就是缓存中的元素是被压缩过的，如果客户端浏览器支持压缩的话，filter会直接返回压缩过的流，这样节省了带宽，把解压的工作交给了客户端浏览即可，当然如果客户端不支持gzip，那么filter会把缓存的元素拿出来解压后在返回给客户端浏览器（大多数爬虫是不支持gzip的，所以filter也会解压后在返回流）。
总之，Ehcache是一个非常轻量级的缓存实现，而且从1.2之后支持了集群，而且是hibernate默认的缓存provider，本文主要介绍Ehcahe对页面缓存的支持，但是它的功能远不止如此，要用好缓存，对J2ee中缓存的原理、适用范围、适用场景等等都需要比较深刻的理解，这样才能用好用对缓存。

为了大家通过实际例子加深了解与场景运用，在奉献一个实例：
*在Spring中运用EhCache
适用任意一个现有开源CacheFramework，要求可以Cache系统中service或者DAO层的get/find等方法返回结果，如果数据更新（适用了Create/update/delete），则刷新cache中相应的内容。
根据需求，计划适用SpringAOP+enCache来实现这个功能，采用ehCache原因之一就是Spring提供了enCache的支持，至于为何仅仅支持ehcache而不支持oscache和jbosscache就无从得知了。
AOP少不了拦截器，先创建一个实现了MethodInterceptor接口的拦截器，用来拦截Service/DAO的方法调用，拦截到方法后，搜索该方法的结果在cache中是否存在，如果存在，返回cache中结果，如果不存在返回数据库查询结果，并将结果返回到缓存。
,InitializingBean
{
privatestaticfinalLoglogger=LogFactory.getLog(MethodCacheInterceptor.class);
privateCachecache;
publicvoidsetCache(Cachecache){
this.cache=cache;
}
publicMethodCacheInterceptor(){
super();
}
/**
*拦截Service/DAO的方法，并查找该结果是否存在，如果存在就返回cache中的值，
*否则，返回数据库查询结果，并将查询结果放入cache
*/
publicObjectinvoke(MethodInvocationinvocation)throwsThrowable{
StringtargetName=invocation.getThis().getClass().getName();
StringmethodName=invocation.getMethod().getName();
Object[]arguments=invocation.getArguments();
Objectresult;
logger.debug("Findobjectfromcacheis"+cache.getName());
StringcacheKey=getCacheKey(targetName,methodName,arguments);
Elementelement=cache.get(cacheKey);
Page13of26
if(element==null){
logger.debug("Holpmethod,Getmethodresultandcreatecache........!");
result=invocation.proceed();
element=newElement(cacheKey,(Serializable)result);
cache.put(element);
}
returnelement.getValue();
}
/**
*获得cachekey的方法，cachekey是Cache中一个Element的唯一标识
*cachekey包括包名+类名+方法名，如com.co.cache.service.UserServiceImpl.getAllUser
*/
privateStringgetCacheKey(StringtargetName,StringmethodName,Object[]arguments){
StringBuffersb=newStringBuffer();
sb.append(targetName).append(".").append(methodName);
if((arguments!=null)&&(arguments.length!=0)){
for(inti=0;i<arguments.length;i++){
sb.append(".").append(arguments[i]);
}
}
returnsb.toString();
}
/**
*implementInitializingBean，检查cache是否为空
*/
publicvoidafterPropertiesSet()throwsException{
Assert.notNull(cache,"Needacache.PleaseusesetCache(Cache)createit.");
}
}

上面的代码可以看到，在方法invoke中，完成了搜索cache/新建cache的功能
随后，再建立一个拦截器MethodCacheAfterAdvice，作用是在用户进行create/update/delete操作时来刷新、remove相关cache内容，这个拦截器需要实现AfterRetruningAdvice接口，将会在所拦截的方法执行后执行在afterReturning（objectarg0，Methodarg1，Object[]arg2,objectarg3)方法中所预定的操作

,InitializingBean
{
privatestaticfinalLoglogger=LogFactory.getLog(MethodCacheAfterAdvice.class);
privateCachecache;
Page15of26
publicvoidsetCache(Cachecache){
this.cache=cache;
}
publicMethodCacheAfterAdvice(){
super();
}
publicvoidafterReturning(Objectarg0,Methodarg1,Object[]arg2,Objectarg3)throws
Throwable{
StringclassName=arg3.getClass().getName();
Listlist=cache.getKeys();
for(inti=0;i<list.size();i++){
StringcacheKey=String.valueOf(list.get(i));
if(cacheKey.startsWith(className)){
cache.remove(cacheKey);
logger.debug("removecache"+cacheKey);
}
}
}
publicvoidafterPropertiesSet()throwsException{
Assert.notNull(cache,"Needacache.PleaseusesetCache(Cache)createit.");
}
}

该方法获取目标class的全名，如：com.co.cache.test.TestServiceImpl，然后循环cache的keylist，刷新/removecache中所有和该class相关的element。

接着就是配置encache的属性，如最大缓存数量、cache刷新的时间等等。
<ehcache>
<diskStorepath="c:\myapp\cache"/>
<defaultCache
maxElementsInMemory="1000"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="true"
/>
<cachename="DEFAULT_CACHE"
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="300000"
timeToLiveSeconds="600000"
overflowToDisk="true"
/>
</ehcache>

这里需要注意的是defaultCache定义了一个默认的cache，这个Cache不能删除，否则会抛出Nodefaultcacheisconfigured异常。另外由于使用拦截器来刷新Cache内容，因此在定义cache生命周期时可以定义较大的数值，timeToIdleSeconds="30000000",timeToLiveSeconds="6000000"，好像还不够大？

然后再将Cache和两个拦截器配置到Spring的配置文件cache.xml中即可，需要创建两个“切入点”，分别用于拦截不同方法名的方法。在配置application.xml并且导入cache.xml。这样一个简单的Spring+Encache框架就搭建完成。

‘玖’ 分布式文件存储系统通过什么方式提高可用性和安全性

分布式存储的六大优点

1. 高性能

一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度;一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。

2. 支持分级存储

由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。

3. 多副本的一致性

与传统的存储架构使用RAID模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带、分布式校验等方式满足租户对于可靠性不同的需求。在读取数据失败的时候，系统可以通过从其他副本读取数据，重新写入该副本进行恢复，从而保证副本的总数固定;当数据长时间处于不一致状态时，系统会自动数据重建恢复，同时租户可设定数据恢复的带宽规则，最小化对业务的影响。

4. 容灾与备份

在分布式存储的容灾中，一个重要的手段就是多时间点快照技术，使得用户生产系统能够实现一定时间间隔下的各版本数据的保存。特别值得一提的是，多时间点快照技术支持同时提取多个时间点样本同时恢复，这对于很多逻辑错误的灾难定位十分有用，如果用户有多台服务器或虚拟机可以用作系统恢复，通过比照和分析，可以快速找到哪个时间点才是需要回复的时间点，降低了故障定位的难度，缩短了定位时间。这个功能还非常有利于进行故障重现，从而进行分析和研究，避免灾难在未来再次发生。多副本技术，数据条带化放置，多时间点快照和周期增量复制等技术为分布式存储的高可靠性提供了保障。

5. 弹性扩展

得益于合理的分布式架构，分布式存储可预估并且弹性扩展计算、存储容量和性能。分布式存储的水平扩展有以下几个特性：

1) 节点扩展后，旧数据会自动迁移到新节点，实现负载均衡，避免单点过热的情况出现;

2) 水平扩展只需要将新节点和原有集群连接到同一网络，整个过程不会对业务造成影响;

3) 当节点被添加到集群，集群系统的整体容量和性能也随之线性扩展，此后新节点的资源就会被管理平台接管，被用于分配或者回收。

6. 存储系统标准化

随着分布式存储的发展，存储行业的标准化进程也不断推进，分布式存储优先采用行业标准接口(SMI-S或OpenStack Cinder)进行存储接入。在平台层面，通过将异构存储资源进行抽象化，将传统的存储设备级的操作封装成面向存储资源的操作，从而简化异构存储基础架构的操作，以实现存储资源的集中管理，并能够自动执行创建、变更、回收等整个存储生命周期流程。基于异构存储整合的功能，用户可以实现跨不同品牌、介质地实现容灾，如用中低端阵列为高端阵列容灾，用不同磁盘阵列为闪存阵列容灾等等，从侧面降低了存储采购和管理成本。

‘拾’ php应用中常用的9大缓存技术

一、全页面静态化缓存

也就是将页面全部生成html静态页面，用户访问时直接访问的静态页面，而不会去走php服务器解析的流程。此种方式，在CMS系统中比较常见，比如dedecms；

一种比较常用的实现方式是用输出缓存：

Ob_start()******要运行的代码*******$content=Ob_get_contents();****将缓存内容写入html文件*****Ob_end_clean();

二、数据缓存

顾名思义，就是缓存数据的一种方式；比如，商城中的某个商品信息，当用商品id去请求时，就会得出包括店铺信息、商品信息等数据，此时就可以将这些数据缓存到一个php文件中，文件名包含商品id来建一个唯一标示；下一次有人想查看这个商品时，首先就直接调这个文件里面的信息，而不用再去数据库查询；其实缓存文件中缓存的就是一个php数组之类；

Ecmall商城系统里面就用了这种方式；

三、查询缓存

其实这跟数据缓存是一个思路，就是根据查询语句来缓存；将查询得到的数据缓存在一个文件中，下次遇到相同的查询时，就直接先从这个文件里面调数据，不会再去查数据库；但此处的缓存文件名可能就需要以查询语句为基点来建立唯一标示；

按时间变更进行缓存

就是对于缓存文件您需要设一个有效时间，在这个有效时间内，相同的访问才会先取缓存文件的内容，但是超过设定的缓存时间，就需要重新从数据库中获取数据，并生产最新的缓存文件；比如，我将我们商城的首页就是设置2个小时更新一次。

四、页面部分缓存

该种方式，是将一个页面中不经常变的部分进行静态缓存，而经常变化的块不缓存，最后组装在一起显示；可以使用类似于ob_get_contents的方式实现，也可以利用类似ESI之类的页面片段缓存策略，使其用来做动态页面中相对静态的片段部分的缓存。

该种方式可以用于如商城中的商品页；

五、Opcode缓存

首先php代码被解析为Tokens，然后再编译为Opcode码，最后执行Opcode码，返回结果；所以，对于相同的php文件，第一次运行时可以缓存其Opcode码，下次再执行这个页面时，直接会去找到缓存下的opcode码，直接执行最后一步，而不再需要中间的步骤了。

比较知名的是XCache、TurckMMCache、PHPAccelerator等。

六、按内容变更进行缓存

这个也并非独立的缓存技术，需结合着用；就是当数据库内容被修改时，即刻更新缓存文件；

比如，一个人流量很大的商城，商品很多，商品表必然比较大，这表的压力也比较重；我们就可以对商品显示页进行页面缓存；

当商家在后台修改这个商品的信息时，点击保存，我们同时就更新缓存文件；那么，买家访问这个商品信息时，实际问的是一个静态页面，而不需要再去访问数据库；

试想，如果对商品页不缓存，那么每次访问一个商品就要去数据库查一次，如果有10万人在线浏览商品，那服务器压力就大了；

七、内存式缓存

提到这个，可能大家想到的首先就是Memcached；memcached是高性能的分布式内存缓存服务器。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。

它就是将需要缓存的信息，缓存到系统内存中，需要获取信息时，直接到内森塌存中取；比较常用的方式就是key_>value方式；缓孝

connect($memcachehost,$memcacheport)ordie("Couldnotconnect");$memcache->set('key','缓存的内容');$get=$memcache->get($key);//获取信息?>

八、apache缓存模块

apache安装完以后，是不允许被cache的。云南IT培训http://www.kmbdqn.cn/认为如果外接了cache或squid服务器要求进行web加速的话，就需要在htttpd.conf里进行设置，当然前提是在安装apache的时候要激活mod_cache的模块。此哪圆