Redis 拥有高性能的数据读写功能,被我们广泛用在缓存场景,一是能提高业务系统的性能,二是为数据库抵挡了高并发的流量请求, 点我 -> 解密 Redis 为什么这么快的秘密 。
把 Redis 作为缓存组件,需要防止出现以下的一些问题,否则可能会造成生产事故。
- Redis 缓存满了怎么办?
- 缓存穿透、缓存击穿、缓存雪崩如何解决?
- Redis 数据过期了会被立马删除么?
- Redis 突然变慢了如何做性能排查并解决?
- Redis 与 MySQL 数据一致性问题怎么应对?
今天「码哥」跟大家一起深入探索 缓存的工作机制和缓存一致性应对方案 。
在本文正式开始之前,我觉得我们需要先取得以下两点的共识:
- 缓存必须要有过期时间;
- 保证数据库跟缓存的最终一致性即可,不必追求强一致性。
目录如下:
目录
- 1. 什么是数据库与缓存一致性
-
- 2.1 Cache-Aside (旁路缓存)
- 2.2 Read-Through(直读)
- 2.3 Write-Through 同步直写
- 3. 旁路缓存下的一致性问题分析
- 3.1 先更新缓存,再更新数据库
- 3.2 先更新数据库,再更新缓存
- 3.3 先删缓存,再更新数据库
- 3.4 先更新数据库,再删缓存
- 4. 一致性解决方案有哪些?
1. 什么是数据库与缓存一致性
数据一致性指的是:
- 缓存中存有数据,缓存的数据值 = 数据库中的值;
- 缓存中没有该数据,数据库中的值 = 最新值。
反推缓存与数据库不一致:
- 缓存的数据值 ≠ 数据库中的值;
- 缓存或者数据库存在旧的数据,导致线程读取到旧数据。
为何会出现数据一致性问题呢?
把 Redis 作为缓存的时候,当数据发生改变我们需要双写来保证缓存与数据库的数据一致。
数据库跟缓存,毕竟是两套系统,如果要保证强一致性,势必要引入 2PC
或 Paxos
等分布式一致性协议,或者分布式锁等等,这个在实现上是有难度的,而且一定会对性能有影响。
如果真的对数据的一致性要求这么高,那引入缓存是否真的有必要呢?
2. 缓存的使用策略
在使用缓存时,通常有以下几种缓存使用策略用于提升系统性能:
Cache-Aside Pattern Read-Through Pattern Write-Through Pattern Write-Behind Pattern
2.1 Cache-Aside (旁路缓存)
所谓「旁路缓存」,就是 读取缓存、读取数据库和更新缓存的操作都在应用系统来完成 , 业务系统最常用的缓存策略 。
2.1.1 读取数据
读取数据逻辑如下:
- 当应用程序需要从数据库读取数据时,先检查缓存数据是否命中。
- 如果缓存未命中,则查询数据库获取数据,同时将数据写到缓存中,以便后续读取相同数据会命中缓存,最后再把数据返回给调用者。
- 如果缓存命中,直接返回。
时序图如下:
优点
- 缓存中仅包含应用程序实际请求的数据,有助于保持缓存大小的