缓存服务器梳理

缓存服务器梳理

原文：https://www.cnblogs.com/chengxuyonghu/p/13683468.html
一、概述

主要功能：应用解耦，异步消息，流量削锋等问题
架构设计：实现高性能，高可用，可伸缩和最终一致性架构
常用消息队列：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，metaMQ，RocketMQ
使用场景：
1）RabbitMQ：对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次（集群不能动态扩展）
2）RocketMQ：具有高吞吐量、高可用性、适合大规模分布式系统应用的特点（支持的语言较少，语言支持的情况下优先选择）
3）Kafka：基于Pull的模式来处理消息消费，追求高吞吐量，适合产生大量数据的互联网服务的数据收集业务（多数用于处理日志）
二、核心功能理解

解耦：一个事务，只关心核心的流程。而需要依赖其他系统但不那么重要的事情，有通知即可，无需等待结果
异步消息：
一致性：保证消息的可靠性
1）强一致性：
2）最终一致性：主要是用“记录”和“补偿”的方式。在做所有的不确定的事情之前，先把事情记录下来，然后去做不确定的事情，结果可能是：成功、失败或是不确定，“不确定”（例如超时等）可以等价为失败。成功就可以把记录的东西清理掉了，对于失败和不确定，可以依靠定时任务等方式把所有失败的事情重新执行一遍，直到成功为止
三、使用总结

1.消息队列不是万能的，对于需要强事务保证而且延迟敏感的，RPC是优于消息队列的。

2.对于一些无关痛痒，或者对于别人非常重要但是对于自己不是那么关心的事情，可以利用消息队列去做。

3.支持最终一致性的消息队列，能够用来处理延迟不那么敏感的“分布式事务”场景，而且相对于笨重的分布式事务，可能是更优的处理方式。

4.当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的“漏斗”，在下游有能力处理的时候，再进行分发。

一、概述

原理：

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

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

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

缓存分类

1）CDN缓存

2）反向代理缓存

3）分布式Cache

4）本地应用缓存

缓存媒介

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

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

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

缓存设计

1）缓存的内容：1.热点数据；2.静态资源

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

缓存策略

1）过期策略：（1）固定时间：比如指定缓存的时间是30分钟；（2）相对时间：比如最近10分钟内没有访问的数据；

2）同步机制：（1）实时写入；（2）异步刷新

缓存的目的：将热点数据放到离用户最近或访问速度更快的介质中，加快数据的访问，减小响应时间

二、CDN缓存

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

CDN主要解决将数据缓存到离用户最近的位置，一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。

国内网络异常复杂，跨运营商的网络访问会很慢。为了解决跨运营商或各地用户访问问题，可以在重要的城市，部署CDN应用。使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

（1） 未部署CDN应用前

网络请求路径：

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

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

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

（2） 部署CDN应用后

网络路径：

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

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

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

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

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

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

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

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

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

缺点

1）动态资源缓存，需要注意实时性（解决方法：主要缓存静态资源，动态资源建立多级缓存或准实时同步）

2）.如何保证数据的一致性和实时性需要权衡考虑（解决方法：设置缓存失效时间（1个小时，最终一致性））

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

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

三、反向代理缓存

原理：反向代理位于应用服务器机房，处理所有对WEB服务器的请求。如果用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求，取回数据，本地缓存后再发送给用户。通过降低向WEB服务器的请求数，从而降低了WEB服务器的负载
代理缓存对比：常用的代理缓存有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，一般作为反向代理使用，可以实现简单的缓存

反向代理一般缓存静态资源，动态资源转发到应用服务器处理

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

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

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

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

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

Squid 反向代理加速网站实例

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

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

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

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

四、分布式缓存-memecache

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

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

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

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

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

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

3）协议简单：基于文本行的协议，直接通过telnet在memcached服务器上可进行存取数据 *** 作，简单，方便

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

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

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

1、MemCached介绍
MemCached是一种基于内存的key-value存储，用来存储小块的任意数据（字符串、对象）。它便于快速开发，减轻开发难度，解决了大数据量缓存的很多问题，本质上，它是一个简洁的key-value存储系统

2、MemCached工作原理
主要通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度。

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

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

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

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

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

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

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

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

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

（优点：计算简单，高效；缺点：在memcached服务器增加或减少时，几乎所有的缓存都会失效，危险：所有压力直接抵达后端，数据库会崩溃的）

2）散列算法：先算出memcached服务器的散列值，并将其分布到0到2的32次方的圆上，然后用同样的方法算出存储数据的键的散列值并映射至圆上，最后从数据映射到的位置开始顺时针查找，将数据保存到查找到的第一个服务器上，如果超过2的32次方，依然找不到服务器，就将数据保存到第一台memcached服务器上（添加了一台memcached服务器，只在圆上增加服务器的逆时针方向的第一台服务器上的键会受到影响）

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

五、分布式缓存-redis

简介：
1）Redis 是一个开源（BSD许可）的，基于内存的，多数据结构存储系统。可以用作数据库、缓存和消息中间件

2）支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询

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

Redis缓存策略
（1）缓存【失效】：客户端请求数据先从缓存中查询，如果没有再查询数据库，最后将数据放入缓存

（2）缓存【命中】：客户端从缓存中直接取到数据，返回结果

（3）缓存【更新】：客户端写入数据到数据库，成功之后，让缓存失效（下次请求时从缓存中拿不到，则查询数据库，再放入缓存）

Redis常用数据类型
1、String

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

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

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

2、Hash

常用命令：hget,hset,hgetall 。

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

实现方式：

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

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

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

3、List

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

应用场景：

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

实现方式：

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

4、Set

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

应用场景：

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

实现方式：

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

5、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实现的高可用方案

切换流程：

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

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

3. 依次类推

主从同时Down机情况：

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

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

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

2. 依次dump主上redis服务

3. 关闭主

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

5. 启动从

6.删除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单点问题；

优点：

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

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

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

哨兵模式：
1）哨兵(sentinel) 会不断地检查Master和Slave是否运作正常

2）当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

3）自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移 *** 作，它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。

4）Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

5）优点：系统更健壮，可用性更高

6）缺点：Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费；配置复杂

Cluster集群模式

1）架构模式：支撑N个redis master node，每个master node都可以挂载多个slave node（读写分离：写到master，然后读就从mater对应的slave去读）

2）使用场景：redis cluster，主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster

3）hash slot算法：
（1）redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot
（2）redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot
（3）hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去（移动hash slot的成本是非常低的）
（4）客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现

4）通信机制

（1）gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些 *** 作会有一些滞后
（2）每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口（每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong）

5）gossip协议：包含多种消息，包括ping，pong，meet，fail，等等

（1）meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信
（2）ping: 每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据
（3）pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新
（4）fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了

6）高可用
（1）如果一个节点认为某个节点pfail了，那么会在gossip ping消息中，ping给其他节点，如果超过半数的节点都认为pfail了，那么就会变成fail
（2）对宕机的master node，从其所有的slave node中，选择一个切换成master node（检查每个slave node与master node断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master）
（3）每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举
（4）所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master
（5）从节点执行主备切换，从节点切换为主节点

六、memcache与redis对比

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

多线程：Memcache支持多线程，redis支持单线程；CPU利用方面Memcache优于redis

持久化：Memcache不支持持久化，Redis支持持久化

内存利用率：memcache高，redis低（采用压缩的情况下比memcache高）

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

6、Redis与MemCached的区别
（1）Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等；

（2）Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储；

（3）虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘；

（4）分布式集群部署：

a、memcache集群节点间的数据是独立的，不能相互通讯，但可以利用magent开源软件解决 ;

b、Redis高可用的，可以做一主多从，主从之间进行数据同步。 当Master宕机后，通过选举算法(Paxos、Raft)从slave中选举出新Master继续对外提供服务，

主机恢复后以slave的身份重新加入

（5）存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）；

（6）灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；

Redis简介
Redis 是完全开源免费的，是一个高性能的key-value数据库。

Redis 与其他 key - value 缓存产品有以下三个特点：
（1）Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

（2）Redis支持String、list、set、zset、hash等数据结构的存储。

（3）Redis支持数据的备份，即master-slave模式的数据备份。

七、本地缓存

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

内存缓存：直接将数据存储到本机内存中，通过程序直接维护缓存对象，是访问速度最快的方式（适合少量缓存，对速度敏感的场景）

八、缓存架构示例

职责划分（建议使用方式，非绝得）：

1）CDN：存放HTML,CSS,JS等静态资源；

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

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

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

请求过程

1）浏览器向客户端发起请求，如果CDN有缓存则直接返回
2） 如果CDN无缓存，则访问反向代理服务器；如果反向代理服务器有缓存则直接返回
3）如果反向代理服务器无缓存或动态请求，则访问应用服务器
4）应用服务器访问本地缓存；如果有缓存，则返回代理服务器，并缓存数据；（动态请求不缓存）
5）如果本地缓存无数据，则读取分布式缓存；并返回应用服务器；应用服务器将数据缓存到本地缓存（部分）
6） 如果分布式缓存无数据，则应用程序读取数据库数据，并放入分布式缓存

九、数据一致性（缓存属于持久化数据的一个副本，因此不可避免的会出现数据不一致问题）

有问题的几种更新缓存策略

（1）先更新缓存，然后更新DB。见下图：

从图中可以看出，两个并发写 *** 作，由于某些原因（io阻塞，cpu时间片分配，协程调度，网络原因等等），导致Thread2的更新DB晚于Thread1的更新DB，但是Redis中此时的数据Thread1的，而DB中的数据时Thread2的，这就出现了不一致的问题，DB中是脏数据

（2）先更新DB，然后更新缓存。见下图：

从图中可以看出，两个并发写 *** 作，由于某些原因导致Thread2的更新Redis晚于Thread1的更新Redis ，但是DB中此时的数据Thread1的，而Redis中的数据时Thread2的，这就出现了不一致的问题

（3）先删除缓存，然后再更新数据库。见下图：

两个并发 *** 作，一个是更新 *** 作，另一个是查询 *** 作，更新 *** 作删除缓存后，查询 *** 作没有命中缓存，会把老数据读出来后放到缓存中，然后更新 *** 作更新了DB。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的

（4）先数据库，成功之后，让缓存失效，下次请求时从缓存中拿不到，则查询数据库，再放入缓存。见下图：

这种更新策略是我们实际最常用的，但也可能出现问题。实际上出现问题的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写 *** 作。

而实际上数据库的写 *** 作会比读 *** 作慢得多，而且还要锁表，而读 *** 作必需在写 *** 作前进入数据库 *** 作，而又要晚于写 *** 作更新缓存，所有的这些条件都具备的概率基本并不大。

使用场景
1）先写缓存，再写数据库：假如缓存写成功，但写数据库失败或响应延迟，则下次读取（并发读）缓存时，就出现脏读（不建议此种使用方式）

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

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

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

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

3）缓存异步刷新：需要考虑数据写入和缓存刷新的时效性（根据经验值确定合理的数据不一致时间，用户数据刷新的时间间隔）

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

第一个场景：

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

第二个场景：

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

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

第三个场景：

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

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

其他优化方式：

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

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

多级缓存需要考虑的问题
1）缓存与数据库之间的一致性；

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

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

缓存高可用

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

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

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

其他方法

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

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

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

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

合理规划缓存的失效时间；
合理评估数据库的负载压力；
对数据库进行过载保护或应用层限流
多级缓存设计，缓存高可用

十一、缓存穿透

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

解决方法：
1）对结果为空的数据也进行缓存，当此key有数据后，清理缓存

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