大纲 。

1.导致Redis阻塞的内在原因 。

2.导致Redis阻塞的外在原因 。

3.Redis的性能总结 。

4.Redis缓存的相关问题 。

5.数据库和缓存的一致性问题 。

6.数据库和缓存的一致性情况列举 。

  。

1.导致Redis阻塞的内在原因 。

(1)API或数据结构不合理 。

(2)持久化阻塞 。

  。

(1)API或数据结构不合理 。

比如对一个包含上万个元素的Hash结构执行hgetall操作，由于数据量大且复杂度为O(N)，所以速度会很慢。对于高并发场景，应该尽量避免在大对象上执行算法复杂度超O(N)的命令.

  。

比如hset命令复杂度只有O(1)，正常耗时应该在10微秒以下。为了追求低内存，过度放宽压缩列表(O(N)~O(N^2))的使用条件，会让hset的时间达到比如135毫秒.

  。

一.如何发现慢查询 。

执行"slowlog get {n}"命令可以获取最近n条慢查询命令。可以将慢查询默认的10毫秒改为1毫秒，默认的慢查询队列128调大.

  。

二.如何发现大对象 。

执行"redis-cli -h-p--bigkeys"命令，内部采用分段进行scan操作.

  。

为了避免产生慢查询，应该使用低算法复杂度的命令。比如hgetall改为hmget、hscan，禁用keys、sort，调整大对象、缩减大对象数据或把大对象拆分为多个小对象，防止一次命令操作过多数据.

  。

(2)持久化阻塞 。

一.fork操作阻塞 。

fork操作发生在RDB和AOF重写期间，应该避免使用过大的内存实例(10G以内)和规避fork操作缓慢的操作系统.

  。

二.AOF刷盘阻塞 。

当开启AOF时，文件刷盘的方式一般采用每秒一次，后台线程每秒对AOF缓冲区的数据执行fsync操作刷新到AOF文件.

  。

当硬盘压力过大时，fsync操作需要等待直到写入完成。如果主进程发现距离上一次fsync操作成功超过了两秒，为了数据安全它会一直阻塞直到后台线程执行fsync操作完成.

  。

三.大页内存写操作阻塞 。

子进程利用写时复制技术降低内存开销，只有写操作时才要复制修改的内存页.

  。

开启了THP的系统，每次复制内存页单位都由4KB变成2MB，这会拖慢写操作的执行时间，导致写操作成为慢查询.

  。

2.导致Redis阻塞的外在原因 。

(1)CPU竞争 。

(2)内存交换 。

(3)网络问题 。

  。

(1)CPU竞争 。

一.进程竞争 。

Redis是CPU密集型，不建议和其他多核CPU密集型服务部署在一起.

  。

二.绑定CPU 。

一台机器部署多实例CPU时，为了降低CPU频繁上下文切换，会把Redis进程绑定到CPU上。这时若父进程创建子进程进行RDB或AOF重写时，由于绑定CPU，父子进程竞争CPU会很激烈。故开启了持久化或参与复制的主节点，不建议绑定CPU.

  。

(2)内存交换 。

如果内存不够，操作系统会把Redis使用的部分内存换出到硬盘，性能急剧下降。所以要确保机器有充足的可用内存，确保Redis实例设置最大可用内存.

  。

(3)网络问题 。

  。

3.Redis的性能总结 。

(1)从CPU角度分析 。

(2)从内存角度分析 。

(3)从磁盘角度分析 。

(4)从网络角度分析 。

  。

首先需要判断出Redis是否真的慢。可以通过基准性能测试得出Redis的平均响应延迟和最大响应延迟。如果当前的响应延迟大于基准性能测试结果的两倍以上则可认为Redis慢了。如果真的发现Redis慢了，则可以通过以下角度进行分析判断.

  。

(1)从CPU角度分析 。

一.使用复杂度过高的命令 。

现象：CPU使用率高，slowlog有耗时命令，业务使用复杂度过高的命令如sort、sunion等，使用时间复杂度为O(N)的命令但N很大.

  。

原因：复杂度高的命令，执行时耗费CPU，一次返回客户端数据过多，网络传输耗时，阻塞后面请求.

  。

解决：不使用复杂度高的命令、集合中的聚合查询放在客户端做、一次查询数据尽量少、全量数据分批查、不要为了追求低内存而过度放宽压缩列表(O(N)~O(N^2))的使用条件.

  。

二.绑定CPU 。

现象：进程绑定一个CPU核心.

  。

原因：子进程继承父进程CPU使用偏好，子进程数据持久化期间，与父进程发生CPU争抢.

  。

解决：主进程、后台子线程、后台RDB进程、AOF重写进程，分别绑定固定的CPU核心.

  。

(2)从内存角度分析 。

一.操作bigkey 。

现象：slowlog出现set/del等简单命令，实例中存储了bigkey.

  。

原因：写入bigkey分配内存耗时久，删除bigkey释放内存耗时久.

  。

解决：不存储bigkey、使用unlink代替del可以把释放内存的操作交给后台线程执行、开启lazy-free机制，这样执行bigkey的del操作时也会把释放内存的操作交给后台线程.

  。

lazy-free机制会先评估释放内存的代价，代价小就主线程执行，毕竟不同线程间传递数据代价也高.

  。

二.集中过期 。

现象：整点发生延迟、间隔固定时间发生延迟，info中expired_keys短期突增.

  。

原因：清理过期key在主线程执行、key集中过期增加了清理负担，过期bigkey延迟更明显.

  。

解决：排查业务时是否使用expired/pexpired命令，过期增加一个随机时间、降低集中过期的压力，开启lazy-free机制。运维监控info中expired_keys指标，短期内突增及时报警.

  。

三.实例内存达到上限 。

现象：实例内存超过mxmemory之后写请求变慢，info中evicted_keys短期突增.

  。

原因：淘汰数据在主线程中执行、LRU淘汰数据也会消耗时间、写OPS越大延迟越明显、淘汰bigkey延迟越明显.

  。

解决：避免存储bigkey，视业务更换淘汰策略(随机比LRU快)，拆分实例分摊淘汰数据的压力，开启lazy-free机制，运维监控info中evicted_keys指标，短期内突增及时报警.

  。

四.fork操作耗时严重 。

现象：延迟只发生在这3个时候：后台定时RDB、后台AOF重写、主从全量同步.

  。

原因：进行fork调用时会创建子进程，fork拷贝内存页表耗费时间，完成fork操作前会阻塞主进程，虚拟机执行fork操作耗时更久.

  。

解决：实例内存10GB以下，优化RDB备份策略如低峰期执行RDB，视情况关闭AOF和AOF重写，Redis实例不部署在虚拟机上，调大repl-backlog-size降低全量同步的概率.

  。

五.开启内存大页 。

现象：子进程持久化数据期间，主进程写请求变慢(写时复制).

  。

原因：内存大页会以2MB为单位向操作系统申请内存，耗时久。内存大页机制是为了降低申请内存的次数，由于Redis对性能和延迟敏感，所以希望申请内存的时候耗时短.

  。

解决：关闭内存大页.

  。

六.使用swap 。

现象：所有请求变慢，延迟达到上百毫秒甚至秒级.

  。

原因：内存数据更换到磁盘，访问磁盘延迟高.

  。

解决：增加内存，重启实例释放swap，让实例重新使用内存，并进行swap监控报警.

  。

七.碎片整理 。

现象：延迟只发生在自动碎片整理期间.

  。

原因：碎片整理在主线程执行.

  。

解决：关闭碎片自动整理，合理配置碎片整理参数.

  。

八.从库加载大的RDB文件 。

主库实例大小控制在2~4GB，以免主从复制时，从库因加载大的RDB文件而阻塞.

  。

(3)从磁盘角度分析 。

现象：磁盘IO负载高，AOF重写期间延迟更明显.

  。

原因：开启了AOF，AOF刷盘always策略加重主线程写负担。AOF刷盘everysec策略时，如果磁盘负载高，write和fsync系统调用会发生阻塞.

  。

解决：升级SSD磁盘，不和高磁盘负载的服务部署在一起(如存储服务、消息队列服务)，重写AOF时不做fsync操作，高流量写入场景不开启AOF.

  。

(4)从网络角度分析 。

现象：稳定运行的实例，突然开始变慢，现象持续.

  。

原因：网络层存在数据传输延迟、丢包.

  。

解决：若是正常的业务大流量访问，需及时扩容或迁移实例，否则排查流量大的实例.

  。

4.Redis缓存的相关问题 。

(1)缓存的收益和成本 。

(2)缓存更新策略 。

(3)缓存穿透问题 。

(4)缓存击穿问题 。

(5)缓存雪崩问题 。

(6)缓存无底洞问题 。

(7)布隆过滤器介绍 。

  。

(1)缓存的收益和成本 。

一.缓存的收益 。

加速读写、降低后端负载.

  。

二.缓存的成本 。

数据不一致性(缓存层和存储层存在一定的时间窗口不一致，时间窗口跟更新策略有关)，维护成本(代码成本、集群成本).

  。

三.缓存的使用场景 。

开销大的复杂计算、加速请求响应.

  。

(2)缓存更新策略 。

一.LRU/LFU算法剔除 。

使用场景：缓存使用量超过预设的最大值.

  。

一致性：数据的一致性最差，因为要清理哪些数据由算法决定.

  。

维护成本：配置好maxmemory和对应的策略即可.

  。

二.超时剔除 。

使用场景：给缓存数据设置过期时间，过期时间后自动删除.

  。

一致性：一段时间窗口内存在一致性问题，取决于过期时间长短.

  。

维护成本：设置expire过期时间即可.

  。

三.主动更新 。

使用场景：对数据一致性要求高，更新真实数据后，立即更新缓存数据.

  。

一致性：一致性最高，但如果主动更新出了问题，那么该数据可能长时间不更新.

  。

维护成本：维护成本高，需要维护主动更新逻辑.

  。

四.总结建议 。

低一致性业务配置最大内存和LRU/LFU算法剔除策略即可。高一致性业务结合使用超时剔除和主动更新，以防主动更新出问题，过期时间后也能删除数据。比较推荐的缓存更新策略是：结合LRU/LFU算法剔除、超时剔除、主动更新三种方法共同完成.

  。

(3)缓存穿透问题 。

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求.

  。

缓存穿透的解决方法:

一.缓存空对象 。

适用于数据频繁变化，实时性要求高的场景。缓存层要存更多空对象的键，这些键一般设置一个较短的过期时间。如果存储层添加了空对象的数据，为避免缓存层和存储层出现不一致，需要主动清除空对象.

二.布隆过滤器拦截 。

适用于数据相对固定，实时性要求低的场景。虽然代码维护比较复杂，但是缓存空间占用比较少.

三.请求入口检查合法性 。

  。

(4)缓存击穿问题 。

缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期)。这时由于并发用户特别多，同时读缓存没读到数据，所以需要同时去数据库去取数据。从而引起数据库压力瞬间增大，造成过大压力.

  。

缓存击穿的解决方法:

问题的关键是产生了并发，因此需要限制并发访问数据库，可考虑加锁。由于Redis是单进程单实例，可利用setnx()的特性来实现简单的分布式锁.

  。

(5)缓存雪崩问题 。

缓存雪崩是指缓存中数据大批量到过期时间，而查询量巨大，引起数据库压力过大甚至宕机。和缓存击穿不同的是，缓存击穿是并发查同一条数据，缓存雪崩是不同数据都过期，很多数据都查不到而查数据库.

  。

缓存雪崩的解决方法:

一.缓存数据的过期时间加上随机数，避免同时过期 。

二.服务降级、服务熔断、请求限流 。

三.主从集群保护缓存高可用 。

四.提前演练 。

  。

(6)缓存无底洞问题 。

缓存无底洞问题是指客户端一次批量操作涉及多次网络，节点越多耗时越大，由于网络连接数变多，对节点性能有影响。所以缓存无底洞问题其实就是如何在更多节点的分布式缓存中进行高效的批量操作.

  。

缓存无底洞的解决方法:

一.串行命令：简单、少量的key，性能可以满足，但大量的key请求会导致延迟严重 。

二.串行IO：简单、少量节点，性能可以满足，但大量的节点也会导致延迟严重 。

三.并行IO：复杂，多线程维护成本高 。

四.hash_tag：性能最高、维护成本高、数据易倾斜 。

  。

(7)布隆过滤器介绍 。

问题：需要判断给定的元素是否存在给定的集合中.

  。

如果该集合是已经排序的，那么可以用二分查找来实现。但是，如果集合的数据量庞大到一定程度，大部分熟知的算法不再有什么用了。即使可以使用，但是机器内存也不允许，这时就可以使用布隆过滤器.

  。

一.布隆过滤器的实现步骤 。

步骤一：首先需要有一个长度为n的比特数组，开始时将这个比特数组里所有的元素都初始化为0：00000000000000000000，比如这个比特数组的n为20.

  。

步骤二：然后选取k个哈希函数，这k个哈希函数产生的结果的值的范围在0到n-1之间。接着对每个要添加进集合的对象进行哈希运算，然后将哈希计算结果作为数组的索引。将索引位置的比特位设置为1(不管该比特位原先为0还是为1).

  。

比如选取三个哈希函数，对象A计算出的哈希值分别为0、5、7，那么比特数组就为：10000101000000000000。对象B计算出的哈希值分别为2、8、13，那么添加B后的比特数组为：10100101100001000000。对象C计算出的哈希值分别为0、4、7，由于对象C的第一个和第三个哈希函数的值与对象A相同了，所以只需添加第二个哈希函数的值即可：10101101100001000000.

  。

步骤三：现在Bloom Filter里已经有3个元素了，下面判断某元素X是否在该集合中：对元素X采用相同的三个哈希函数哈希，然后以这三个哈希值为索引去比特数组里找。如果三个索引位置的比特位都为1就认为该元素在集合中，否则不是.

  。

可以用伪代码简单的描述一下这个算法:

public class BloomFilter {
    private bit[] bitSet = new bit[N];
    
    public void add(Object element) {
        int[] hashValues = getHashValues(element);
        for (int i : hashValues) {
            bitSet[i] = 1;
        }
    }
    
    public boolean exists(Object element) {
        int[] hashValues = getHashValues(element);
        for (int i : hashValues) {
            if (bitSet[i] != 1) return false;
        }
        return true;
    }
}

二.布隆过滤器算法的特征 。

特征一：如果该元素真的在集合中，那么Bloom Filter的exists方法肯定会返回true，这就是Bloom Filter不会漏报的特性.

  。

特征二：如果该元素不在集合中，那么Bloom Filter的exists方法也有可能返回true。因为不同的元素经过哈希之后哈希值可能发生碰撞，所以Bloom Filter有可能误报，但是误报的几率不高，小于1%.

  。

根据Bloom Filter的特征可以看到不是所有的场景都可以用的，只有在一些能容许少量的误报的情况下使用才行。该算法用很低的误报率却换来了大量的存储空间，实在是是一个很巧妙的算法.

  。

5.数据库和缓存的一致性问题 。

(1)关于缓存和数据库一致性的相关问题 。

(2)首先从引入缓存提高性能开始 。

(3)缓存利用率和一致性问题 。

(4)异常引起的一致性问题 。

(5)并发引起的一致性问题 。

(6)删除缓存可以保证一致性吗 。

(7)如何保证两步都执行成功 。

(8)主从库延迟和延迟双删问题 。

(9)可以做到强一致吗 。

(10)总结 。

  。

(1)关于缓存和数据库一致性的相关问题 。

一.到底是更新缓存还是删缓存?

二.到底选择先更新数据库再删除缓存，还是先删除缓存再更新数据库?

三.为什么要引入消息队列保证一致性?

四.延迟双删会有什么问题？到底要不要用?

  。

(2)首先从引入缓存提高性能开始 。

从最简单的场景开始引入，如果业务处于起步阶段流量非常小，那么无论是读请求还是写请求，直接操作数据库即可，架构模型如下:

但随着业务量的增长，项目请求量越来越大，这时如果每次都从数据库中读数据，则肯定会有性能问题。这个阶段通常的做法是，引入缓存来提高读性能，架构模型如下:

当下优秀的缓存中间件，当属Redis莫属，它不仅性能非常高，还提供了很多友好的数据类型，可以很好满足业务需求。但引入缓存后，就会面临一个问题：之前数据只存在数据库中，现在要放到缓存中读取，具体要怎么存呢?

  。

最简单直接的方案是全量数据刷到缓存中:

一.数据库的数据全量刷入缓存(不设置失效时间) 。

二.写请求只更新数据库不更新缓存 。

三.启动一个定时任务把数据库的数据更新到缓存 。

这个方案的优点是：所有读请求都可以直接命中缓存，不需要再查数据库，性能非常高.

  。

但缺点也很明显，有2个问题:

一.缓存利用率低：不经常访问的数据一直留在缓存 。

二.数据不一致：因为是定时刷新缓存，所以缓存和数据库存在不一致(取决于定时任务的执行频率) 。

  。

所以这种方案一般更适合业务体量小，且对数据一致性要求不高的业务场景。但是如果业务的体量很大，那么如何解决这两个问题呢?

  。

(3)缓存利用率和一致性问题 。

问题一：如何提高缓存利用率 。

想要缓存利用率最大化，很容易想到的方案是缓存中只保留最近访问的热数据.

  。

具体可以这样优化:

一.写请求依旧只写数据库 。

二.读请求先读缓存，如果缓存不存在，则从数据库读取并重建缓存 。

三.同时写入缓存中的数据都设置失效时间 。

这样缓存中不经常访问的数据，随着时间的推移，都会逐渐过期淘汰掉。最终缓存中保留的都是经常被访问的热数据，缓存利用率得以最大化.

  。

问题二：如何保证数据一致 。

要想保证缓存和数据库实时一致，那就不能再用定时任务刷新缓存了。所以当数据发生更新时，不仅要操作数据库，还要操作缓存。具体操作就是，修改一条数据时，不仅要更新数据库，也要连带缓存也一起更新.

  。

但数据库和缓存都更新，又存在先后问题，那么对应的方案就有两个:

方案一：先更新缓存，后更新数据库 。

方案二：先更新数据库，后更新缓存 。

  。

(4)异常引起的一致性问题 。

这两个方案哪个方案更好呢？先不考虑并发问题，正常情况下，无论谁先谁后，都可以让两者保持一致，现在重点考虑异常情况。因为操作分为两步，那么就很有可能发生第一步成功、第二步失败的情况.

  。

情况一：先更新缓存成功，后更新数据库失败 。

如果缓存更新成功了，但数据库更新失败，那么此时缓存中是最新值，但数据库中是旧值。虽然此时读请求可以命中缓存，拿到正确的值，但一旦缓存失效，就会从数据库中读取到旧值，重建缓存也是这个旧值。这时用户会发现自己之前修改的数据又变回去了，对业务造成影响.

  。

情况二：先更新数据库成功，后更新缓存失败 。

如果数据库更新成功了，但缓存更新失败，那么此时数据库中是最新值，缓存中是旧值。之后的读请求读到的都是旧数据，只有当缓存失效后，才能从数据库中得到正确的值。这时用户会发现，自己刚刚修改了数据，但却看不到变更，一段时间过后，数据才变更过来，对业务也会有影响.

  。

可见，无论谁先谁后，但凡后者发生异常，就会对业务造成影响，那么应该怎么解决这个问题呢？一般会通过重试进行解决.

  。

其实除了操作失败的问题，还有并发的场景也会影响数据的一致性.

  。

(5)并发引起的一致性问题 。

假设采用先更新数据库，再更新缓存的方案，并且两步都成功执行，如果存在并发，那么情况会是怎样?

  。

有线程A和线程B两个线程，需要更新同一条数据，并发情况下会发生如下的场景:

步骤一：线程A更新数据库x = 1 。

步骤二：线程B更新数据库x = 2 。

步骤三：线程B更新缓存x = 2 。

步骤四：线程A更新缓存x = 1 。

  。

最终x的值在缓存中是1，在数据库中是2，发生了不一致。即线程A虽然先于线程B发生，但线程B操作数据库和缓存的时间，却要比线程A的时间短，于是执行时序发生错乱，最终这条数据的结果是不符合预期的.

  。

同样地，采用先更新缓存，再更新数据库的方案，也会发生类似的场景:

步骤一：线程A更新缓存x = 1 。

步骤二：线程B更新缓存x = 2 。

步骤三：线程B更新数据库x = 2 。

步骤四：线程A更新数据库x = 1 。

  。

除此之外，如果从缓存利用率的角度来评估更新缓存的方案，也是不太推荐的。因为每次数据发生变更都更新缓存，但缓存中的数据不一定会被马上读取，这会导致缓存中存放了很多不常访问的数据，浪费缓存资源。而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应的。很有可能是先查询数据库，再经过一系列计算得出一个值，然后才把这个值才写到缓存中.

  。

由此可见，这种更新数据库 + 更新缓存的方案，不仅缓存利用率不高，还会造成机器性能浪费。所以需要考虑另外一种方案：删除缓存.

  。

(6)删除缓存可以保证一致性吗 。

删除缓存对应的方案也有两种:

方案一：先删除缓存，后更新数据库 。

方案二：先更新数据库，后删除缓存 。

  。

经过前面的分析得知，但凡第二步操作失败，都会导致数据不一致。这里不再详述异常情况下的具体场景，而是重点来看并发情况下的问题.

  。

如果采用方案一：先删除缓存，后更新数据库 。

有2个线程要并发读写数据，可能会发生如下情况:

步骤一：线程A要更新x = 2(原值x = 1) 。

步骤二：线程A先删除缓存 。

步骤三：线程B读缓存，发现不存在，从数据库中读取到旧值(x = 1) 。

步骤四：线程A将新值写入数据库(x = 2) 。

步骤五：线程B将旧值写入缓存(x = 1) 。

  。

最终x的值在缓存中是1(旧值)，在数据库中是2(新值)，发生不一致。可见，先删除缓存，后更新数据库，当发生读+写并发时，还是会出现数据不一致.

  。

如果采用方案二：先更新数据库，后删除缓存 。

有2个线程要并发读写数据，可能会发生以下情况:

步骤一：缓存中x不存在(数据库x = 1) 。

步骤二：线程A读取数据库，得到旧值(x = 1) 。

步骤三：线程B更新数据库(x = 2) 。

步骤四：线程B删除缓存 。

步骤五：线程A将旧值写入缓存(x = 1) 。

  。

最终x的值在缓存中是1(旧值)，在数据库中是2(新值)，发生不一致。这种情况理论上是可能发生的，但实际发生的概率很低，因为必须满足3个条件:

条件一：缓存刚好已失效 。

条件二：读请求 + 写请求并发 。

条件三：写比读的时间更短 。

  。

也就是更新数据库 + 删除缓存的时间(步骤三和步骤四)，要比读数据库 + 写缓存时间(步骤二和步骤五)短。其实条件三发生的概率是非常低的，因为写数据库一般会先加锁，所以写数据库通常是要比读数据库的时间更长.

  。

因此，先更新数据库 + 再删除缓存的方案，是可以更好地保证数据一致性的。所以，应采用这种方案来操作数据库和缓存，来解决并发情况下的数据不一致问题.

  。

(7)如何保证两步都执行成功 。

前面分析到，无论是更新缓存还是删除缓存，只要第二步发生失败，那么就会导致数据库和缓存不一致。所以保证第二步成功执行，就是解决问题的关键.

  。

如果程序在执行过程中发生异常，那么最简单的解决办法就是：重试。无论是先操作缓存，还是先操作数据库，但凡后者执行失败了，就发起重试，尽可能地去做补偿.

  。

那这是不是意味着，只要执行失败，立即重试就可以呢？答案是否定的，失败后立即重试的问题在于:

一.立即重试很大概率还会失败 。

二.重试次数设置多少才合理 。

三.重试会一直占用这个线程资源，无法服务其它客户端请求 。

  。

所以，如果想通过重试的方式解决问题，这种同步重试的方案依旧不严谨。通常来说，更好的方案应该是异步重试.

  。

异步重试就是把重试请求写到消息队列中，然后由专门的消费者来重试，直到成功。或者更直接的做法，为了避免第二步执行失败，可以把操作缓存这一步直接放到消息队列中，由消费者来操作缓存.

  。

到这里可能会问，写消息队列也有可能会失败，而且引入消息队列又增加了更多的维护成本，这样做值得吗？这个问题很好，但思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目重启了，那么这次重试请求也就丢失了，那这条数据就一直不一致了.

  。

所以，这里必须把重试或第二步操作放到另一个服务中，这个服务用消息队列最为合适。这是因为消息队列的特性，正好符合这里的需求:

一.消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失(重启项目也不担心) 。

二.消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者(符合重试的场景) 。

  。

至于写队列失败和消息队列的维护成本问题:

一.写队列失败：操作缓存和写消息队列，同时失败的概率其实是很小的 。

二.维护成本：项目中一般都会用到消息队列，维护成本并没有新增很多 。

  。

所以，引入消息队列来解决这个问题，是比较合适的，这时架构模型就变成了这样:

如果确实不想在应用中去写消息队列，是否有更简单的方案，同时又可以保证一致性呢？方案还是有的，这就是近几年比较流行的解决方案：订阅数据库变更日志，再操作缓存.

  。

具体来讲就是，业务应用在修改数据时，只需修改数据库，无需操作缓存。那什么时候操作缓存呢？这就和数据库的变更日志有关了.

  。

以MySQL为例，当一条数据发生修改时，MySQL就会产生一条变更日志binlog，我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存.

订阅变更日志binlog，目前也有比较成熟的开源中间件，比如Canal，使用这种方案的优点在于:

一.无需考虑写消息队列失败情况：只要写MySQL成功，binlog肯定会有 。

二.自动投递到下游队列：Canal会自动把数据库变更日志投递给下游的消息队列 。

  。

至此，可以得出结论：想要保证数据库和缓存一致性，推荐采用先更新数据库，再删除缓存方案，并配合消息队列或订阅变更日志的方式来做.

  。

(8)主从库延迟和延迟双删问题 。

延迟双删其实是为了解决缓存中是旧值但数据库中是新值的问题.

  。

情况一：在先删除缓存再更新数据库方案中，存在缓存中是旧值但数据库中是新值的情况.

  。

当两个线程要并发读写数据，可能会发生以下情况:

一.线程A要更新x = 2(原值x = 1) 。

二.线程A先删除缓存 。

三.线程B读缓存，发现不存在，从数据库中读取到旧值(x = 1) 。

四.线程A将新值写入数据库(x = 2) 。

五.线程B将旧值写入缓存(x = 1) 。

  。

最终x的值在缓存中是1(旧值)，在数据库中是2(新值)，发生不一致.

  。

情况二：在先更新数据库再删除缓存方案中，遇到读写分离+主从库延迟时，特别容易发生缓存中是旧值但数据库中是新值的情况.

  。

当两个线程要并发读写数据，可能会发生以下情况:

一.线程A更新主库x = 2(原值x = 1) 。

二.线程A删除缓存 。

三.线程B查询缓存，没有命中，查询从库得到旧值(从库x = 1) 。

四.从库同步完成(主从库x = 2) 。

五.线程B将旧值写入缓存(x = 1) 。

  。

最终x的值在缓存中是1(旧值)，在主从库中是2(新值)，发生了不一致.

  。

由此可见，上述情况出现不一致问题的核心在于：缓存都被更新回了旧值。因此为了解决缓存中是旧值但数据库中是新值的问题，最有效的办法就是把缓存删掉。但是不能立即删，而是需要延迟删，这也是业界常用的缓存延迟双删策略.

  。

情况一的解决方案：在线程A删除缓存、更新完数据库之后，先休眠一会，再删除一次缓存.

  。

情况二的解决方案：线程A可以生成一条延时消息写到消息队列中，消费者延时删除缓存.

  。

这两个方案的目的，都是为了把缓存清掉，这样下次就可以从数据库读取到最新值写入缓存。但是，这个延迟删除缓存的延迟时间到底设置多久才合理呢?

一.延迟时间要大于主从复制的延迟时间 。

二.延迟时间要大于读取数据库 + 写入缓存的时间 。

  。

这个延迟删除缓存的延迟时间在分布式和高并发场景下，其实是很难评估的。很多时候，都是凭借经验大致估算这个延迟时间，例如延迟为1-5s，只能尽可能地降低不一致的概率。所以采用这种方案，也只是尽可能保证一致性而已，极端情况下还是有可能发生不一致的.

  。

所以实际使用中，建议采用先更新数据库，再删除缓存的方案。同时要尽可能地保证主从复制不要有太大延迟，降低出问题的概率.

  。

(9)可以做到强一致吗 。

可见上述这些方案还是不够完美，其实很难让缓存和数据库强一致。强一致最常见的方案是2PC、3PC、Paxos、Raft这类一致性协议，但它们的性能往往比较差，而且也比较复杂，还要考虑各种容错问题.

  。

通常来说，引入缓存的目的其实是为了性能。一旦决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平的两端，无法做到都满足要求。而且当操作数据库和缓存完成之前，只要有其它请求可以进来，都有可能查到中间状态的数据。所以如果非要追求强一致，那必须要求所有更新操作完成之前期间，不能有任何请求进来。虽然可以通过加分布锁的方式来实现，但要付出的代价，很可能会超过引入缓存带来的性能提升.

  。

所以既然决定使用缓存，就必须容忍一致性问题，只能尽可能地去降低问题出现的概率。同时也要知道缓存都是有失效时间的，就算在这期间存在短期不一致，依旧有缓存失效时间来兜底，这样也能达到最终一致.

  。

强一致方案：2PC、3PC、Paxos、Raft，性能较差、实现复杂、各种容错问题 。

  。

分布式锁方案：锁付出的代价可能超过引入缓存带来的性能提升 。

  。

使用缓存方案：必须容忍一致性问题，尽量降低不一致概率，缓存失效时间兜底，最终一致 。

  。

(10)总结 。

缓存和数据库一致性问题的总结:

  。

一.为了提高应用的性能，会引入缓存 。

  。

二.引入缓存后需要考虑缓存和数据库一致性问题，可选的方案有：更新数据库 + 更新缓存、更新数据库 + 删除缓存 。

  。

三.更新数据库 + 更新缓存方案，在并发场景下无法保证缓存和数据一致性，且存在缓存资源浪费和机器性能浪费的情况 。

  。

四.更新数据库 + 删除缓存方案，在并发场景下依旧有数据不一致问题，解决方案是延迟双删，但这个延迟时间很难评估 。

  。

五.在先更新数据库再删除缓存方案下，为了保证两步都成功执行，需配合消息队列或订阅变更日志的方案来做，本质是通过重试的方式保证数据一致性 。

  。

六.在先更新数据库再删除缓存方案下，读写分离 + 主从库延迟也会导致缓存和数据库不一致，缓解此问题的方案是延迟双删，凭借经验发送延迟消息到队列中延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率 。

  。

对一致性问题的理解:

  。

一.性能和一致性不能同时满足，为了性能通常会采用最终一致性的方案 。

  。

二.缓存和数据库一致性问题的有三个核心：缓存利用率、并发、缓存 + 数据库一起成功 。

  。

三.失败场景下要保证一致性，常见手段就是重试，同步重试会影响吞吐量，通常会采用异步重试 。

  。

四.订阅变更日志的本质是把权威数据源(如MySQL)当做Leader副本，让其它异质系统(如Redis/ES)成为它的Follower副本，通过同步变更日志的方式，保证Leader和Follower之间数据一致 。

  。

6.数据库和缓存的一致性情况列举 。

这里假设缓存没有主从延迟，而且设置的键都是有过期时间的.

  。

情况一：先更新数据库，再更新缓存的方案下，两线程的写写+读写并发情况 。

出现了四种数据不一致的并发情况，两种发生在写写并发的时候，两种发生在读写并发的时候.

情况二：先更新缓存，再更新数据库的方案下，两线程的写写+读写并发情况 。

出现了六种数据不一致的并发情况，两种发生在写写并发的时候，四种发生在读写并发的时候.

情况三：先删除缓存，再更新数据库的方案下，两线程的写写+读写并发情况 。

出现了四种数据不一致的并发情况，四种情况都是发生在读写并发的时候.

情况四：先更新数据库，再删除缓存的方案下，两线程的写写+读写并发情况 。

出现了一种数据不一致的并发情况，而且是在读写并发的时候发生的，写写并发不存在不一致的情况。这种情况发生的条件是：缓存刚好失效 + 并发读写 + 读还要比写慢.

  。

最后此篇关于Redis原理—5.性能和使用总结的文章就讲到这里了,如果你想了解更多关于Redis原理—5.性能和使用总结的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。