1、redis和mysql怎么保证一致性

redis缓存的数据用来快速读取，但是当数据库需要更新的时候，就需要考虑两者之间的一致性。

1.1、先更新数据库，再更新缓存

或者先更新缓存，再更新数据库

这种方法在多并发的场景下都会有数据不一致的问题

1.2、延时双删

先删除缓存，再更新数据库，再延时删除缓存。

一开始删除了缓存，请求读取数据库数据，可能读取了旧数据放在了缓存里，等更新完数据库，延时之后，删除缓存。

请求就会去数据库里读取新的数据,形成缓存，这样就实现了一致性

为什么要延时呢？

因为有些请求可能读取数据库之后还没来的及形成缓存，没有延时的化，可能旧数据又形成了缓存，这样就会有不一致的问题。

优缺点：

• 优点：可以保证一致性
• 缺点：因为有延时，会造成阻塞，不适合高并发的场景

1.3、最终一致性

由于大部分情况我们可以接受数据更新的时候不一致，但是数据最终需要一致，那么可以采取最终一致性方案

• 比如基于RocketMQ的可靠性消息通信，来实现最终一致性。

• 或者直接通过Canal组件，监控Mysql中binlog的日志，把更新后的数据同步到Redis里面。

2、redis的过期策略

Redis的数据结构均可以通过EXPIRE key seconds 的方式设置key的过期时间（TTL）。

Redis的设计考虑到性能/内存等综合因素，设计了一套过期策略。

• 主动删除（惰性删除）

主动删除（惰性删除）指的是当key被访问的时候，先校验key是否过期，如果过期了则主动删除。

• 被动删除（定期策略）

被动删除（定期策略）指的是Redis服务器定时随机的测试key的过期时间，如果过期了则被动删除。

被动删除的存在必不可少，因为存在一些过期且永久不在访问的key，如果都依赖主动删除，那么它们将会永久占用内存。

Redis为了保证提供高性能服务，被动删除过期的key，采用了贪心策略/概率算法，默认每隔10秒扫描一次，具体策略如下：

从过期字典（设置了过期时间的key的集合）中随机选择20个key，检查其是否过期

删除其中已经过期的key

如果删除的过期key数量大于25%，则重复步骤1

此外开发在设计Redis缓存架构时，一定要注意要尽可能的避免（禁止）将大量的key设置为同一过期时间
为了避免同时过期，一定要将一些允许过期时间不需要非常精确的key，设置较为随机的过期时间，这样就可以将卡顿时间缩小。 ​