Redis和数据库的一致性问题，一般有以下几种方案。
一、先更新数据库， 再删除缓存
先更新数据库，再删除缓存，缓存删除失败的概率比较低，并且先更新数据库就能确保数据先写入持久层可以保证数据的可靠性和一致性，即使在删除缓存失败的情况下，数据库中已有最新数据。
但如果第二步失败了，会导致数据库中的数据已经更新，但是缓存还是旧数据，导致数据不一致。
为什么删缓存而不是更新
更新缓存的动作，相比于直接删除缓存，操作过程比较的复杂，而且也容易出错。
二、延迟双删
延迟双删解决的就是第一种方案第二部删除缓存失败的问题，先删除缓存，再更新数据库，再删除一次缓存。第二次删除一般建议设置1-2s就可以了。在高并发下，第一次删除缓存有可能会发生被另一请求再一次读取旧数据写入到缓存的问题，那么就需要第二次删除了，就是我们的延迟双删。
三、cache-aside：
更新数据库，基于 binlog 监听进行缓存删除，借助数据库的binlog或者基于异步消息订阅的方式。在代码的主要逻辑中，先操作数据库就行了，然后数据库操作完，可以发一个异步消息出来。然后再由一个监听者在接到消息之后，异步的把缓存中的数据删除掉。或者干脆借助数据库的binlog，订阅到数据库变更之后，异步的清除缓存。这两种方式都会有一定的延时，通常在毫秒级别，一般用于在可接受秒级延迟的业务场景中。