门户网站制作流程广州网站推广

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 的高性能

…

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

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

清除策略

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

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

解决缓存击穿问题的方案

分布式锁

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

使用更新策略

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

更新策略

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

删除策略

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

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

同步写

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

伪代码:

// 更新数据库
err := db.Update(data).Error()
if err != nil{return
}// MySQL更新成功再更新 Redis
redis.Update(key,data)//或者使用删除redis.Delete(key)

异步写

协程写

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

伪代码

// 更新数据库
err := db.Update(data).Error()
if err != nil{return
}// 异步更新 Redis
go redis.Update(key,data)//或者使用删除redis.Delete(key)

监听binlog写

更新接口

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

Redis 更新服务

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

其他方案

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

总结

• 对于可预见性的热数据,并且并发读写高的数据一般使用监听 binlog +更新缓存 Redis 数据的方式

  • case: 抢红包

• 对于不可预见热key 并且更新频率低,容忍延迟刷新数据生效的业务使用异步协程+删除 Redis 缓存数据的方案

  • case: 更新视频的名称等

其他保证:

• 重试与告警: 当写 Redis 失效的时候,再保证幂等(做计算类更新一定要保证幂等再重试,使用 lua)的情况下进行重试

  • 如果超过设定的最大重试次数依旧没有成功,应当立即告警,记录,限流,降级,熔断;并进行抢修

• 击穿预防: 使用分布式锁限制热key 打到 MySQL 的 请求的数量,避免缓存击穿.