1. 更新策略三种方式 

缓存更新是redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向redis插入太多数据，此时就可能会导致缓存中的数据过多，所以redis会对部分数据进行更新，或者把他叫为淘汰更合适。

有三种缓存更新策略方式：

内存淘汰：redis自动进行，当redis内存达到咱们设定的max-memery的时候，会自动触发淘汰机制，淘汰掉一些不重要的数据(可以自己设置策略方式)。这种是默认的。

这种策略在一定程度上保证了数据一致性，当redis的内存不够时，会自动淘汰一部分的缓存数据。假如我们恰好要查询这些淘汰掉的数据，而redis缓存中已经把这些数据清除了，就会到数据库中查找，然后将数据库中查询的数据更新到缓存中，从而保证数据的一致性。

但如果redis的内存没有占满，redis就不会主动的清除缓存，加入我们更改了数据库中的数据，由于redis的内存没有占满，并不会更新缓存，就会导致数据库数据和缓存数据不一致。

超时剔除：当我们给redis设置了过期时间ttl之后，redis会将超时的数据进行删除，下次再次查询数据时，由于缓存数据删除了，就会到数据库中查询数据，再把数据更新到缓存中。

这种方式保证数据的唯一性的关键性在于过期时间ttl的设置。假设设置过期时间为30分钟，也就是说30分钟更新一次缓存，如果某些数据在30分钟以内被修改，也会出现数据库数据和缓存数据短暂不一致的情况。

从维护成本的角度来看，只需要设置一个过期时间即可，维护成本还是较低的。

主动更新：就是由开发人员自行控制的，由开发人员编写逻辑什么时候更新。当我们修改数据库后，将缓存数据也修改，这种的确能够很好的保证数据一致性，但要确保程序能够正常运行。

 

2. 如何选择更新策略

对于长久不发生改变的需求，或者说变化的可能性不大，可以使用内存淘汰。如店铺信息。

对于高一致性的需求，可以使用主动更新策略，并用超时剔除作为兜底方案。如优惠券发放等。

3. 操作顺序问题

3.1 先删除缓存再操作数据库

正常情况：如果是先删除缓存，那么请求的数据就会到达数据库中，然后重建缓存。

非正常情况：由于没有加锁的原因，在多线程情况下，线程1在缓存中没有找到数据，就到达数据库中查询，然后重建缓存，但此时有个线程2，在重建缓存后，刚好更新了数据，那么就会导致书库中的数据和缓存中的数据不一致的情况。

发生这种概率的情况还是蛮高的，因为删除缓存这个操作比较快，而修改、写入数据是比较慢的。

3.2 先操作数据库再删除缓存

正常情况：线程1操作数据库，此时其他线程来查询数据必然是拿到缓存的旧数据的返回了，并不会到达数据库。

非正常情况：恰好缓存失效了，线程1到数据库中查询数据并删除缓存、重建缓存，就在重建缓存期间，线程2修改好了数据库，而此时线程1用了旧数据重建缓存。这种情况的概率就相对来说比较小了，需要满足两个线程并行执行；线程1查询时缓存失效了；恰好线程1查完数据准备写缓存了，线程2在这期间修改了数据并将缓存删除了，线程1才开始写缓存。这条件太苛刻了，因为redis是存入内存的，读写速度非常快，线程2要完成修改数据库到删除缓存的时间要控制在微秒级别，发生的概率就不大了。

所以还是先操作数据库在删除缓存的方案好一些。