MySQL 与 Redis 数据一致性 2

[1. 强一致还是最终一致?](#1. 强一致还是最终一致?)
[2. 先写 MySQL 还是先写Redis?](#2. 先写 MySQL 还是先写Redis?)
- - [case 1](#case 1)
[3. 缓存(Redis)更新还是清除?](#3. 缓存(Redis)更新还是清除?)
- 更新策略
- - 更新策略会有数据不一致问题?
  - 数据不一致的概率与影响
  - 如果使用监听binlog更新数据还会出现数据不一致问题?
  - - binlog的消费问题
  - 使用消息队列行不行?
  - 其他方案
  - [总结: 数据不一致的处理方案](#总结: 数据不一致的处理方案)
- 清除策略
- - 解决缓存击穿问题的方案
  - - - 分布式锁
      - 使用更新策略
- 更新策略与清除策略的使用场景
- - - 更新策略
    - 删除策略
[4. 缓存(Redis)写的方式有哪些?](#4. 缓存(Redis)写的方式有哪些?)
总结
- - 其他保证:

1. 强一致还是最终一致?

Redis的定位是缓存,缓存的主要目的是为了减轻MySQL(DB层)的请求压力,并且快速响应
所以缓存一定要保持高性能,但是强一致性会严重破坏高性能的特性,所以一般是采用最终一致性的方案.
你能找到的市面上大部分的解决方案都是最终一致性的

2. 先写 MySQL 还是先写Redis?

先写 MySQL

原则: 谁保存全量持久化数据先更新谁

为什么需要先写 MySQL?

避免MySQL数据覆盖,丢失更新;(造成永久性错误)
因为并发情况下先写 Redis,无法保证 MySQL 写的时候是顺序的

case 1

假设有两个连续的更改视频标题的请求,

请求 1改为 A;
请求 2改为 B

先写 Redis先改成 A,然后改成 B(Redis 是单线程的,请求将顺序执行)

这时候请求 1 的线程处理比较慢(或者阻塞了一下)

这时候请求 2 先更新了持久化全量数据(MySQL) 中记录:改为 B

然后请求 1 才开始更改MySQL 中的数据:改为 A

这时候 MySQL 的数据是错的,并且重启也无法恢复的错误

如果先更新 Redis 会造成无法修复的数据不一致(MySQL 数据是错误的)

结论: 先做 MySQL 的更新,再更新 Redis

3. 缓存(Redis)更新还是清除?

原则: 必须避免缓存击穿(大量访问打到MySQL 将 MySQL 打爆)

简单理解就是如何 MySQL 崩溃了,整个服务就直接炸了

更新策略

优势: 可以有效避免缓存击穿问题
缺点: 可能存在数据不一致问题

更新策略会有数据不一致问题?

假设有两个连续的更新视频标题的请求

请求 1改为 A;
请求 2改为 B

先更新 MySQL,先改成 A,然后改成 B

这时候请求 1 的线程处理比较慢(或者阻塞了一下)

这时候请求 2 先更新了缓存数据( Redis) 中的记录

然后请求 1 才开始更改 Redis 中的数据

这时候Redis 的数据是错误的,会导致后面查询的时候全部查询到错误的数据(只能重新加载 MySQL 数据到 Redis 才能恢复)

数据不一致的概率与影响

概率低
- 一般同一条数据更新会做限制的,比如改名的接口会限制一分钟只能请求一次,甚至有些改名称限制更长
- 一个用户只能在一个设备上面进行登录,所以很难同时请求多次
- 简单来讲就是很难出现并发的场景
影响有限
- 缓存的数据都是有过期时间的,就算有一个黑客巧妙的绕开了前面的限制,还有过期时间兜底,数据到了过期时间会重新查询 MySQL 的最新数据并更新到 Redis(最终一致)

如果使用监听binlog更新数据还会出现数据不一致问题?

单独开一个服务监听数据库 binlog 日志更新缓存可以有效避免数据不一致的问题

首先产生不一致的原因是更新缓存的顺序无法保证,因为有的请求执行快,有的请求执行慢,这个无法保证,所以有可能造成覆盖的问题
但是 binlog 是有序的,按照事务提交的顺序进行追加的,所以使用 binlog 更新缓存(Redis)就是按照事务提交的顺序进行更新,就不会出现数据不一致的问题

binlog的消费问题

binlog要顺序消费就需要使用单线程的模型,这样其实性能并不是很好,但是我们可以使用聚合多次更改,同时做批量提交,可以极大的优化单线程消费的性能
如果是做多线程消费,那么就会有消费顺序的问题.有可能产生数据覆盖的问题(旧数据覆盖新数据(就是上面改名的case)

使用消息队列行不行?

不行

还是原来的逻辑后到的可能先入队,先到的可能后入队(先到的线程阻塞了一下)

消息队列主要能保证数据丢失,并且有重试机制保证更新成功
(这些其实对于缓存 Redis 来讲都可以接受,因为有过期时间兜底,实现最终一致)

其他方案

分布式锁解决数据不一致问题,但是一般不会使用,因为破坏了Redis 的高性能

...

总结: 数据不一致的处理方案

不处理: 一般是低概率事件并且有过期时间兜底,最终一致性保障,不需要因为一个低概率事件去配置复杂又消耗性能的方案
读取 binlog 更新: 使用 binlog 的有序性解决 Redis 更新执行顺序的问题
分布式锁(不推荐)

清除策略

优势: 操作简单,内存又好(避免不使用的数据加到 Redis)
缺点: 缓存击穿问题

清除策略有非常大的缓存击穿问题,可能造成 MySQL 被打爆,这是不能接受的

解决缓存击穿问题的方案

分布式锁

当未命中缓存就加分布式锁(使用 lua 脚本)避免大量请求打到 MySQL 导致服务崩溃

使用更新策略

更新策略与清除策略的使用场景

更新策略

抢红包这种高实时性,高并发写的业务(可以预测出一定会再端时间有大量并发读写的请求)

删除策略

适用于更新视频名称这种更新频率比较低的业务(无法预测数据是否热,并且可以接受短时间的延迟不一致(刷新后还是会最终一致))

4. 缓存(Redis)写的方式有哪些?

同步写

优点: 实现简单
缺点: 会加长处理时间(性能低)

伪代码:

go 复制代码

// 更新数据库
err := db.Update(data).Error()
if err != nil{
	return
}

// MySQL更新成功再更新 Redis
redis.Update(key,data)//或者使用删除redis.Delete(key)

异步写

协程写

优势: 实现简单
缺点: 开协程有一点点消耗 (8k),增加调度开销

伪代码

go 复制代码

// 更新数据库
err := db.Update(data).Error()
if err != nil{
	return
}

// 异步更新 Redis
go redis.Update(key,data)//或者使用删除redis.Delete(key)

监听binlog写

更新接口

go 复制代码

// 只做更新数据库操作
err := db.Update(data).Error()
if err != nil{
	return
}

Redis 更新服务

go 复制代码

for{
	//监听 binlog 日志
	binlog<-binlogChan
	
	//写 Redis
	redis.Update(binlog["key"],binlog["data"])//或者使用删除redis.Delete(binlog["key"])	
}

其他方案

消息队列
优势: 数据丢失,但是对于缓存来讲数据丢失是可以接受的,最终还是会报错了数据一致性(有过期时间兜底)

总结

对于可预见性的热数据,并且并发读写高的数据一般使用监听 binlog +更新缓存 Redis 数据的方式
- case: 抢红包
对于不可预见热key 并且更新频率低,容忍延迟刷新数据生效的业务使用异步协程+删除 Redis 缓存数据的方案
- case: 更新视频的名称等

其他保证:

重试与告警: 当写 Redis 失效的时候,再保证幂等(做计算类更新一定要保证幂等再重试,使用 lua)的情况下进行重试
- 如果超过设定的最大重试次数依旧没有成功,应当立即告警,记录,限流,降级,熔断;并进行抢修
击穿预防: 使用分布式锁限制热key 打到 MySQL 的请求的数量,避免缓存击穿.