redis的缓存更新策略有这么几种：

1、由应用直接和redis以及数据库相连接：
        查询数据时，应用去redis中查询，查不到的话再由应用去数据库中查询，并将查询结果放在redis；
        更新数据时，由应用去触发redis数据的删除以及数据库的update。
2、应用只跟redis相连接，redis跟数据库连接：
        查询时，应用去redis中查，查不到的话，由redis去数据库中查，将查询到的结果缓存在redis并返回给应用；
        更新时，由应用去更新redis，并且由redis将数据同步到数据库。
3、应用只跟redis相连接，redis跟数据库连接：
        查询数据时，由应用去redis中查询；
        更新数据时，由应用更新到redis中之后就返回，redis异步将数据更新到数据库。
4、应用只跟redis连接，后台服务跟数据库连接：
        查询数据时，由应用去redis中查询；
        由后台服务自动将数据库中的最新数据更新到redis。

        需要注意的是，第一种更新策略，无论是先删除redis中的数据还是先update数据库，都会存在redis中出现脏数据的问题。

        比如：如果我们先删redis再update数据库，那么可能某个请求1删完redis了，还没来得及update 数据库，有另外一个请求2到达要进行查询这条数据，请求2在redis中查不到，就去db查，在db中查到了旧数据，并将旧数据再次放进redis，在请求1完成db的update之后，redis和db出现了数据不一致的情况，redis中出现了脏数据。
        再比如，有一条数据在redis中不存在，在db中存在，有两个请求同时到达，请求1要查询这条数据，请求2要更新这条数据，请求1在redis中未查到这条数据，所以去db查，这时请求2还未完成对于db的更新，所以请求1在db中查到了旧数据，这时请求2完成了db的update，并且删除了redis中的数据[当然现在redis中还是没有这条数据，也就无数据可删]，在请求2完成了redis的删除动作之后，请求1将手里之前查到的旧数据又放进了redis。

        解决这个问题，可以用延迟双删策略。

延迟双删策略：

        对于更新操作分三步：先删redis缓存 -> 再update数据库 -> 延迟N秒之后，再删一次redis缓存。

        之所以有第三步，是为了将在这期间其他请求存进redis中的脏数据删除，所以这个延迟时长一定要控制好，延迟必须大于向redis中执行一次写操作的耗时，以便保证在其他请求将脏数据向redis写完成之后再删，否则删了也没效果。但是这个N我们即便是控制得再好也无法完全避免redis的脏数据问题，因为有可能其他的向redis进行脏数据的写请求因为网络等原因而耗时延长，最终导致脏数据还是写进了redis。

        延迟双删策略只能在很大程度上解决redis的脏数据问题，让redis与db达到最终一致性，但不能完全避免，想要完全避免这种情况，可以使用同步锁，让整个的数据更新操作同步执行。