更新Redis缓存，再更新数据库；还是更新数据库再更新Redis

在大型系统中，为了抗住高并发，减少数据库压力。都会引入缓存机制，一旦加多了一层缓存。就必须要处理缓存数据与数据库不一致的问题。

更新缓存和数据的机制处理策略如下：

redis场景流程

如果同时有两个写请求更新同一数据，每个写请求都是先更新数据库再更新缓存，在并发场景下可能会出现数据不一致

如果同时有一个读请求和一个写请求并发场景下，写请求是先删除缓存再更新数据库，可能造成数据不一致

先删缓存,后DB

如果同时有一个读请求和一个写请求并发场景下，写请求是更新数据库再删除缓存，可能造成数据不一致

先DB，后删缓存

综上 缓存通常会先更新数据库，然后再删除缓存，为了保障数据一致，还需要设置合理的缓存时间。

应用程序无需管理缓存和数据库，只需要将数据库的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。
Read/Write through 一般是由一个 Cache Provider 对外提供读写操作，应用程序不用感知操作的是缓存还是数据库。

Write behind简单理解就是延迟写入，Cache Provider 每隔一段时间会批量输入数据库，优点是应用程序写入速度非常快。