分布式缓存技术原理 浅析 - 20181120

一.引言

• 缓存是 分布式系统 中重要组件，主要解决数据高并发，大数据场景下，热点数据访问的性能安全问题，提供高性能的数据快速访问。
• 缓存的原理：将数据放到更快的存储中、将数据缓存到离应用最近的位置、将数据缓存到离用户最近的位置。

二.缓存的流程（浅谈）

1.缓存大致流程：

• F5(不走缓存) —> 浏览器缓存/应用缓存 —> Nginx代理 —>Redis缓存 —>本地数据库缓存 —> RDBMS
  接下来，分步骤了解下：

2.F5(不走缓存)

• refresh刷新页面，不走缓存（就近存储，减少请求量）

3.浏览器缓存/应用缓存

• 本地缓存 map结构，url作为key
• 因为网站短时间内变化少，具备了缓存条件，可以缓存到本地，提升响应速度和用户体验

4.Nginx代理服务器

• 负载均衡/动静分离
• freemaker页面静态化技术，可以把页面静态元素抽离出来作为缓存，因为页面主要改变的是数据，页面大致布局不变。
• 使用代理平台（定时，主动推送，然后直接在平台上拿数据即可）

5.Redis缓存（NoSQL产品）

• NoSQL是弱事务控制（提升了速度，用户体验好）
• 大数据分析（非精准，分析出规律和趋势）
• 利用MyBatis的一级，二级缓存

6.本地数据库缓存

• Mybatis和Oracle、MySQL本地数据库缓存，可以消解用户请求量

三.转载 - 分布式缓存那些事儿

原文链接：http://blog.csdn.net/dinglang_2009/article/details/9071075
（作者：dinglang_2009）
http://os.51cto.com/art/201306/397999.htm

在前面的一些文章中，从实战的角度，讲解了有关 memcached的应用、容灾、监控等等。但是缺乏对理论的讲解和原理性的剖析。本文将从理论的角度去介绍，让大家从宏观上对“分布式缓存、nosql”等技术有所了解，以便进一步学习和使用。在构建大规模的web应用时，缓存技术可以说是必备的，学习的必要性不言而喻。

分布式缓存概述

1.1 分布式缓存的特性

分布式缓存具有如下特性:

1. 高性能:当传统数据库面临大规模数据访问时,磁盘I/O 往往成为性能瓶颈,从而导致过高的响应延迟.分布式缓存将高速内存作为数据对象的存储介质,数据以key/value 形式存储,理想情况下可以获得DRAM 级的读写性能;

2. 动态扩展性:支持弹性扩展,通过动态增加或减少节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提高资源利用率;

3. 高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(single point of failure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而导致缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用;

4. 易用性:提供单一的数据与管理视图;API 接口简单,且与拓扑结构无关;动态扩展或失效恢复时无需人工配置;自动选取备份节点;多数缓存系统提供了图形化的管理控制台,便于统一维护;

5. 分布式代码执行(distributed code execution):将任务代码转移到各数据节点并行执行,客户端聚合返回结果,从而有效避免了缓存数据的移动与传输.最新的Java 数据网格规范JSR-347中加入了分布式代码执行与Map/reduce 的API 支持,各主流分布式缓存产品,如IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和Red Hat Infinispan 等也都支持这一新的编程模型.

1.2 典型应用场景

分布式缓存的典型应用场景可分为以下几类:

1. 页面缓存.用来缓存Web 页面的内容片段,包括HTML、CSS 和图片等,多应用于社交网站等;

2. 应用对象缓存.缓存系统作为ORM 框架的二级缓存对外提供服务,目的是减轻数据库的负载压力,加速应用访问;

3. 状态缓存.缓存包括Session 会话状态及应用横向扩展时的状态数据等,这类数据一般是难以恢复的,对可用性要求较高,多应用于高可用集群;

4. 并行处理.通常涉及大量中间计算结果需要共享;

5. 事件处理.分布式缓存提供了针对事件流的连续查询(continuous query)处理技术,满足实时性需求;

6. 极限事务处理.分布式缓存为事务型应用提供高吞吐率、低延时的解决方案,支持高并发事务请求处理,多应用于铁路、金融服务和电信等领域.

1.3 分布式缓存的发展

分布式缓存经历了多个发展阶段,由最初的本地缓存到弹性缓存平台直至弹性应用平台[8],目标是朝着构建更好的分布式系统方向发展(如下图所示).

1. 本地缓存:数据存储在应用代码所在内存空间.优点是可以提供快速的数据访问;缺点是数据无法分布式共享,无容错处理.典型的,如Cache4j;

2. 分布式缓存系统:数据在固定数目的集群节点间分布存储.优点是缓存容量可扩展(静态扩展);缺点是扩展过程中需要大量配置,无容错机制.典型的,如 Memcached;

3. 弹性缓存平台:数据在集群节点间分布存储,基于冗余机制实现高可用性.优点是可动态扩展,具有容错能力;缺点是复制备份会对系统性能造成一定影响.典型的,如 Windows Appfabric Caching;

4. 弹性应用平台:弹性应用平台代表了云环境下分布式缓存系统未来的发展方向.简单地讲,弹性应用平台是弹性缓存与代码执行的组合体,将业务逻辑代码转移到数据所在节点执行,可以极大地降低数据传输开销,提升系统性能.典型的,如 GigaSpaces XAP.

1.4 分布式缓存与NoSQL

NoSQL 又称为Not Only Sql,主要是指非关系型、分布式、支持水平扩展的数据库设计模式.NoSQL 放弃了传统关系型数据库严格的事务一致性和范式约束,采用弱一致性模型.相对于NoSQL 系统,传统数据库难以满足云环境下应用数据的存储需求,具体体现在以下3 个方面:

1. 根据CAP 理论,一致性(consistency)、可用性(availability)和分区容错(partition tolerance)这3 个要素最多同时满足两个,不可能三者兼顾.对云平台中部署的大量Web 应用而言,数据可用性与分区容错的优先级通常更高,所以一般会选择适当放松一致性约束.传统数据库的事务一致性需求制约了其横向伸缩与高可用技术的实现;

2. 传统数据库难以适应新的数据存储访问模式.Web 2.0 站点以及云平台中存在大量半结构化数据,如用户Session 数据、时间敏感的事务型数据、计算密集型任务数据等,这些状态数据更适合以Key/Value 形式存储,不需要RDBMS 提供的复杂的查询与管理功能;

3. NoSQL 提供低延时的读写速度,支持水平扩展,这些特性对拥有海量数据访问请求的云平台而言是至关重要的.传统关系型数据无法提供同样的性能,而内存数据库容量有限且不具备扩展能力.分布式缓存作为NoSQL 的一种重要实现形式,可为云平台提供高可用的状态存储与可伸缩的应用加速服务,与其他NoSQL 系统间并无清晰的界限.平台中应用访问与系统故障均具有不可预知性,为了更好地应对这些挑战,应用软件在架构时通常采用无状态设计,大量状态信息不再由组件、容器或平台来管理,而是直接交 付给后端的分布式缓存服务或NoSQL 系统.

1.5 分布式缓存与极限事务处理

随着云计算与 Web 2.0 的进一步发展,许多企业或组织时常会面对空前的需求:百万级的并发用户访问、每秒数以千计的并发事务处理、灵活的弹性与可伸缩性、低延时及7×24×365 可用性等.传统事务型应用面临极限规模的并发事务处理,出现了极限事务处理型应用,典型的有铁路售票系统.Wikipedia 认为,极限事务处理是每秒多于500 事务或高于10 000 次并发访问的事务处理 Gartner 将极限事务处理(extreme transactionprocessing,简称XTP)定义为一种为事务型应用的开发、部署、管理和维护供支持的应用模式,特点是对性能、可扩展性、可用性、可管理性等方面的极限需求.Gartner 在其报告中预测指出,极限事务处理型应用的规模将由2005 年的10%提升至2010 年的20%,极限事务处理技术是未来5 年~10 年的热点技术.极限事务处理的引入,无疑给传统Web 三层架构带来了新的挑战.即,如何在廉价的、标准化的硬件和软件平台之上,对大容量、业务关键型的事务处理应用提供良好的支撑.分布式缓存作为一种关键的XTP 技术,可为事务型应用提供高吞吐率、低延时的技术解决方案.其延迟写(write-behind)机制可提供更短的响应时间,同时极大地降低数据库的事务处理负载,分阶段事件驱动架构(staged event-driven architecture)可以支持大规模、高并发的事务处理请求.此外,分布式缓存在内存中管理事务并提供数据的一致性保障,采用数据复制技术实现高可用性,具有较优的扩展性与性能组合.

四.转载 - 缓存技术的详解

原文链接：https://blog.csdn.net/qq_26517369/article/details/78330694
（作者：qq_26517369）
一、缓存概述

缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。提供高性能的数据快速访问。

1、缓存的原理

将数据写入/读取速度更快的存储（设备）；

将数据缓存到离应用最近的位置；

将数据缓存到离用户最近的位置。

2、缓存分类

在分布式系统中，缓存的应用非常广泛，从部署角度有以下几个方面的缓存应用。

CDN缓存；

反向代理缓存；

分布式Cache；

本地应用缓存；

3、缓存媒介

常用中间件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等；

缓存的内容：文件，数据，对象；

缓存的介质：CPU，内存（本地，分布式），磁盘（本地，分布式）

4、缓存设计

缓存设计需要解决以下几个问题：

缓存什么？

哪些数据需要缓存：1.热点数据；2.静态资源。

缓存的位置？

CDN，反向代理，分布式缓存服务器，本机（内存，硬盘）

如何缓存的问题？

过期策略

固定时间：比如指定缓存的时间是30分钟；

相对时间：比如最近10分钟内没有访问的数据；

同步机制

实时写入；（推）

异步刷新；（推拉）

二、CDN缓存

CDN主要解决将数据缓存到离用户最近的位置，一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。国内网络异常复杂，跨运营商的网络访问会很慢。为了解决跨运营商或各地用户访问问题，可以在重要的城市，部署CDN应用。使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

1、CND原理

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

（1）未部署CDN应用前

网络请求路径：

请求：本机网络（局域网）——》运营商网络——》应用服务器机房

响应：应用服务器机房——》运营商网络——》本机网络（局域网）

在不考虑复杂网络的情况下，从请求到响应需要经过3个节点，6个步骤完成一次用户访问操作。

（2）部署CDN应用后

网络路径：

请求：本机网络（局域网）——》运营商网络

响应：运营商网络——》本机网络（局域网）

在不考虑复杂网络的情况下，从请求到响应需要经过2个节点，2个步骤完成一次用户访问操作。

与不部署CDN服务相比，减少了1个节点，4个步骤的访问。极大的提高的系统的响应速度。

2、CDN优缺点

优点（摘自百度百科）：

本地Cache加速：提升访问速度，尤其含有大量图片和静态页面站点。

镜像服务：消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。

远程加速：远程访问用户根据DNS负载均衡技术智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度。

带宽优化：自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。

集群抗攻击：广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响，同时保证较好的服务质量。

缺点：

动态资源缓存，需要注意实时性；

解决：主要缓存静态资源，动态资源建立多级缓存或准实时同步；

如何保证数据的一致性和实时性需要权衡考虑；

解决：

（1）设置缓存失效时间（1个小时，最终一致性）；

（2）数据版本号；

3、CND架构参考

摘自《云宙视频CDN系统》

4、CND技术实践

目前，中小型互联网公司，综合成本考虑，一般租用第三方CDN服务，大型互联网公司，采用自建或第三方结合的方式。比如淘宝刚开始使用第三方的，当流量很大后，第三方公司无法支撑其CDN流量，淘宝最后采用自建CDN的方式实现。

淘宝CDN，如下图（来自网络）：

三、反向代理缓存

反向代理是指在网站服务器机房部署代理服务器，实现负载均衡、数据缓存、安全控制等功能。

1、缓存原理

反向代理位于应用服务器机房，处理所有对WEB服务器的请求。如果用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求，取回数据，本地缓存后再发送给用户。通过降低向WEB服务器的请求数，从而降低了WEB服务器的负载。

反向代理一般缓存静态资源，动态资源转发到应用服务器处理。常用的缓存应用服务器有Varnish、Ngnix、Squid。

2、Squid示例

Squid 反向代理一般只缓存静态资源，动态程序默认不缓存。根据从 WEB 服务器返回的 HTTP 头标记来缓冲静态页面。有四个最重要 HTTP 头标记：

Last-Modified：告诉反向代理页面什么时间被修改

Expires：告诉反向代理页面什么时间应该从缓冲区中删除

Cache-Control：告诉反向代理页面是否应该被缓冲

Pragma用来包含实现特定的指令，最常用的是 Pragma:no-cache

Squid 反向代理加速网站实例

通过DNS的轮询技术，将客户端的请求分发给其中一台 Squid 反向代理服务器处理；

如果这台 Squid 缓存了用户的请求资源，则将请求的资源直接返回给用户；

否则这台 Squid 将没有缓存的请求根据配置的规则发送给邻居 Squid 和后台的 WEB 服务器处理；

这样既减轻后台 WEB 服务器的负载，又提高整个网站的性能和安全性。

2、代理缓存比较

常用的代理缓存有Varnish，Squid，Ngnix，简单比较如下：

（1）varnish和squid是专业的cache服务，nginx需要第三方模块支持；

（2） Varnish采用内存型缓存，避免了频繁在内存、磁盘中交换文件，性能比Squid高；

（3）Varnish由于是内存cache，所以对小文件如css,js,小图片啥的支持很棒，后端的持久化缓存可以采用的是Squid或ATS；

（4）Squid功能全而大，适合于各种静态的文件缓存，一般会在前端挂一个HAProxy或nginx做负载均衡跑多个实例；

（5）Nginx采用第三方模块ncache做的缓冲，性能基本达到varnish，一般作为反向代理使用，可以实现简单的缓存。

四、分布式缓存

CDN，反向代理缓存，主要解决静态文件，或用户请求资源的缓存，数据源一般为静态文件或动态生成的文件（有缓存头标识）。

而分布式缓存，主要指缓存用户经常访问数据的缓存，数据源为数据库。一般起到热点数据访问和减轻数据库压力的作用。

目前分布式缓存设计，在大型网站架构中是必备的架构要素。常用的中间件有Memcache，Redis。

1、Memcache

Memcache是一个高性能，分布式内存对象缓存系统，通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中，然后从内存中读取，从而大大提高读取速度。

Memcache特性：

（1）使用物理内存作为缓存区，可独立运行在服务器上。每个进程最大2G，如果想缓存更多的数据，可以开辟更多的Memcache进程（不同端口）或者使用分布式Memcache进行缓存，将数据缓存到不同的物理机或者虚拟机上。

（2）使用key-value的方式来存储数据，这是一种单索引的结构化数据组织形式，可使数据项查询时间复杂度为O(1)。

（3）协议简单：基于文本行的协议，直接通过telnet在memcached服务器上可进行存取数据操作，简单，方便多种缓存参考此协议。

（4）基于Libevent高性能通信：Libevent是一套利用C开发的程序库，它将BSD系统的kqueue，Linux系统的epoll等事件处理功能封装成一个接口，与传统的select相比，提高了性能。

（5）内置的内存管理方式：所有数据都保存在内存中，存取数据比硬盘快，当内存满后，通过LRU算法自动删除不使用的缓存，但没有考虑数据的容灾问题，重启服务，所有数据会丢失。

（6）分布式：各个memcached服务器之间互不通信，各自独立存取数据，不共享任何信息。服务器并不具有分布式功能，分布式部署取决于Memcache客户端。

（7）缓存策略：memcached的缓存策略是LRU（最近最少使用）到期失效策略。在memcached内存储数据项时，可以指定它在缓存的失效时间，默认为永久。当memcached服务器用完分配的内时，失效的数据被首先替换，然后也是最近未使用的数据。在LRU中，memcached使用的是一种Lazy Expiration策略，自己不会监控存入的key/vlue对是否过期，而是在获取key值时查看记录的时间戳，检查key/value对空间是否过期，这样可减轻服务器的负载。

Memcache工作原理：

Memcache的工作流程如下：

（1）先检查客户端的请求数据是否在memcached中，如有，直接把请求数据返回，不再对数据库进行任何操作。

（2） 如果请求的数据不在memcached中，就去查数据库，把从数据库中获取的数据返回给客户端，同时把数据缓存一份到memcached中（memcached客户端不负责，需要程序实现）。

（3） 每次更新数据库的同时更新memcached中的数据，保证一致性。

（4） 当分配给memcached内存空间用完之后，会使用LRU（Least Recently Used，最近最少使用）策略加上到期失效策略，失效数据首先被替换，然后再替换掉最近未使用的数据。

Memcache集群

memcached 虽然称为“分布式 ” 缓存服务器，但服务器端并没有 “ 分布式 ” 功能。每个服务器都是完全独立和隔离的服务。 memcached 的分布式，是由客户端程序实现的。

当向memcached集群存入/取出key value时，memcached客户端程序根据一定的算法计算存入哪台服务器，然后再把key value值存到此服务器中。

存取数据分二步走，第一步，选择服务器，第二步存取数据。

分布式算法(Consistent Hashing)：

选择服务器算法有两种，一种是根据余数来计算分布，另一种是根据散列算法来计算分布。

余数算法：

先求得键的整数散列值，再除以服务器台数，根据余数确定存取服务器。

优点：计算简单，高效。

缺点：在memcached服务器增加或减少时，几乎所有的缓存都会失效。

散列算法：（一致性Hash）

先算出memcached服务器的散列值，并将其分布到0到2的32次方的圆上，然后用同样的方法算出存储数据的键的散列值并映射至圆上，最后从数据映射到的位置开始顺时针查找，将数据保存到查找到的第一个服务器上，如果超过2的32次方，依然找不到服务器，就将数据保存到第一台memcached服务器上。

如果添加了一台Memcached服务器，只在圆上增加服务器的逆时针方向的第一台服务器上的键会受到影响。

一致性Hash算法：解决了余数算法增加节点命中大幅额度降低的问题，理论上，插入一个实体节点，平均会影响到：虚拟节点数 /2 的节点数据的命中。

2、Redis

Redis 是一个开源（BSD许可）的，基于内存的，多数据结构存储系统。可以用作数据库、缓存和消息中间件。 支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。

内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动分区（Cluster）提供高可用性（high availability）。

Redis常用数据类型

String

常用命令：set，get，decr，incr，mget。

应用场景：String是最常用的一种数据类型，与Memcache的key value存储方式类似。

实现方式：String在Redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr，decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

Hash

常用命令：hget，hset，hgetall 。

应用场景：以存储一个用户信息对象数据，为例：

实现方式：Redis Hash对应的Value，内部实际就是一个HashMap，实际这里会有2种不同实现。

（1）Hash的成员比较少时Redis为了节省内存会采用类似一维数 组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap。

（2）当成员数量增大时会自动转成真正的HashMap，此时encoding为ht。

List

常用命令：lpush,rpush,lpop,rpop,lrange。

应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。

实现方式：Redis list的实现为一个双向链表，可以支持反向查找和遍历，方便操作。不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

Set

常用命令：sadd,spop,smembers,sunion。

应用场景：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set 是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

实现方式：set的内部实现是一个value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

Sorted set

常用命令：zadd、zrange、zrem、zcard。

使用场景：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。

实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的 是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

Redis集群

（1）通过keepalived实现的高可用方案

切换流程：

当Master挂了后，VIP漂移到Slave；Slave 上keepalived 通知redis 执行：slaveof no one ,开始提供业务；

当Master起来后，VIP 地址不变，Master的keepalived 通知redis 执行slaveof slave IP host ，开始作为从同步数据；

依次类推。

主从同时Down机情况：

非计划性，不做考虑，一般也不会存在这种问题

计划性重启，重启之前通过运维手段SAVE DUMP 主库数据；需要注意顺序：

关闭其中一台机器上所有redis，是得master全部切到另外一台机器（多实例部署，单机上既有主又有从的情况）；并关闭机器

依次dump主上redis服务

关闭主

启动主，并等待数据load完毕

启动从

删除DUMP 文件（避免重启加载慢）

（2）使用Twemproxy 实现集群方案

由twitter开源的c版本proxy，同时支持memcached和redis，目前最新版本为：0.2.4，持续开发中;https://github.com/twitter/twemproxy .twitter用它主要减少前端与缓存服务间网络连接数。

特点：快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash分片算法。

这里使用keepalived实现高可用主备方案，解决proxy单点问题。

优点：

对于客户端而言，redis集群是透明的，客户端简单，遍于动态扩容；

Proxy为单点、处理一致性hash时，集群节点可用性检测不存在脑裂问题；

高性能，CPU密集型，而redis节点集群多CPU资源冗余，可部署在redis节点集群上，不需要额外设备。

3、Memcache与Redis的比较

（1）数据结构：Memcache只支持key value存储方式，Redis支持更多的数据类型，比如Key value、hash、list、set、zset；

（2）多线程：Memcache支持多线程，Redis支持单线程；CPU利用方面Memcache优于Redis；

（3）持久化：Memcache不支持持久化，Redis支持持久化；

（4）内存利用率：Memcache高，Redis低（采用压缩的情况下比Memcache高）；

（5）过期策略：Memcache过期后，不删除缓存，会导致下次取数据数据的问题，Redis有专门线程，清除缓存数据；

五、本地缓存

本地缓存是指应用内部的缓存，标准的分布式系统，一般有多级缓存构成。本地缓存是离应用最近的缓存，一般可以将数据缓存到硬盘或内存。

1、硬盘缓存

将数据缓存到硬盘到，读取时从硬盘读取。原理是直接读取本机文件，减少了网络传输消耗，比通过网络读取数据库速度更快。可以应用在对速度要求不是很高，但需要大量缓存存储的场景。

2、内存缓存

直接将数据存储到本机内存中，通过程序直接维护缓存对象，是访问速度最快的方式。

六、缓存架构示例

职责划分：

CDN：存放HTML、CSS、JS等静态资源；

反向代理：动静分离，只缓存用户请求的静态资源；

分布式缓存：缓存数据库中的热点数据；

本地缓存：缓存应用字典等常用数据。

请求过程：

（1）浏览器向客户端发起请求，如果CDN有缓存则直接返回；

（2）如果CDN无缓存，则访问反向代理服务器；

（3）如果反向代理服务器有缓存则直接返回；

（4）如果反向代理服务器无缓存或动态请求，则访问应用服务器；

（5）应用服务器访问本地缓存；如果有缓存，则返回代理服务器，并缓存数据；（动态请求不缓存）

（6）如果本地缓存无数据，则读取分布式缓存；并返回应用服务器；应用服务器将数据缓存到本地缓存（部分）；

（7）如果分布式缓存无数据，则应用程序读取数据库数据，并放入分布式缓存。

七、缓存常见问题

1、数据一致性

缓存是在数据持久化之前的一个节点，主要是将热点数据放到离用户最近或访问速度更快的介质中，加快数据的访问，减小响应时间。

因为缓存属于持久化数据的一个副本，因此不可避免的会出现数据不一致问题。导致脏读或读不到数据的情况。数据不一致，一般是因为网络不稳定或节点故障导致。根据数据的操作顺序，主要有以下几种情况。

场景介绍

（1）先写缓存，再写数据库

如下图：

假如缓存写成功，但写数据库失败或响应延迟，则下次读取（并发读）缓存时，就出现脏读。

（2）先写数据库，再写缓存

如下图：

假如写数据库成功，但写缓存失败，则下次读取（并发读）缓存时，则读不到数据。

（3）缓存异步刷新

指数据库操作和写缓存不在一个操作步骤中，比如在分布式场景下，无法做到同时写缓存或需要异步刷新（补救措施）时候。

此种情况，主要考虑数据写入和缓存刷新的时效性。比如多久内刷新缓存，不影响用户对数据的访问。

解决方法

第一个场景：这个写缓存的方式，本身就是错误的，需要改为先写持久化介质，再写缓存的方式。

第二个场景：

（1）根据写入缓存的响应来进行判断，如果缓存写入失败，则回滚数据库操作；此种方法增加了程序的复杂度，不建议采用；

（2）缓存使用时，假如读缓存失败，先读数据库，再回写缓存的方式实现。

第三个场景：

（1）首先确定，哪些数据适合此类场景；

（2）根据经验值确定合理的数据不一致时间，用户数据刷新的时间间隔。

其他方法

（1）超时：设置合理的超时时间；

（2）刷新：定时刷新一定范围内（根据时间，版本号）的数据；

以上是简化数据读写场景，实际中会分为：

（1）缓存与数据库之间的一致性；

（2）多级缓存之前的一致性；

（3）缓存副本之前的一致性。

2、缓存高可用

业界有两种理论，第一套缓存就是缓存，临时存储数据的，不需要高可用。第二种缓存逐步演化为重要的存储介质，需要做高可用。

本人的看法是，缓存是否高可用，需要根据实际的场景而定。临界点是是否对后端的数据库造成影响。

具体的决策依据需要根据，集群的规模（数据，缓存），成本（服务器，运维），系统性能（并发量，吞吐量，响应时间）等方面综合评价。

解决方法

缓存的高可用，一般通过分布式和复制实现。分布式实现数据的海量缓存，复制实现缓存数据节点的高可用。架构图如下：

其中，分布式采用一致性Hash算法，复制采用异步复制。

其他方法

（1）复制双写：缓存节点的复制，由异步改为双写，只有两份都写成功，才算成功。

（2）虚拟层：一致性Hash存在，假如其中一个HASH环不可用，数据会写入临近的环，当HASH可用时，数据又写入正常的HASH环，会导致数据偏移问题。这种情况，可以考虑在HASH环前面加一个虚拟层实现。

（3）多级缓存：比如一级使用本地缓存，二级采用分布式Cahce，三级采用分布式Cache+本地持久化；

方式很多，需要根据业务场景灵活选择。

3、缓存雪崩

雪崩是指当大量缓存失效时，导致大量的请求访问数据库，导致数据库服务器，无法抗住请求或挂掉的情况。

解决方法：

（1）合理规划缓存的失效时间；

（2）合理评估数据库的负载压力；

（3）对数据库进行过载保护或应用层限流；

（4）多级缓存设计，缓存高可用。

4、缓存穿透

缓存一般是Key，value方式存在，当某一个Key不存在时会查询数据库，假如这个Key，一直不存在，则会频繁的请求数据库，对数据库造成访问压力。

解决方法：

（1）对结果为空的数据也进行缓存，当此key有数据后，清理缓存；

（2）一定不存在的key，采用布隆过滤器，建立一个大的Bitmap中，查询时通过该bitmap过滤。