Redis缓存更新策略
双写不一致问题解决方案再下方
内存淘汰：不用自己维护，利用redis的内存淘汰机制，内存不足时自动淘汰部分数据，下次查询时更新缓存。
超时剔除：给缓存数据添加TTL时间，到期后自动删除缓存。下次查询时更新缓存。
主动更新：编写业务逻辑，在修改数据库的同时，更新缓存
cache Aside Patten：由缓存的调用者，在更新数据库的同时更新缓存 企业运用多
Read/Write Through Pattern:缓存与数据库整合为一个服务，由服务来维护一致性。
调用者调用该服务，无需关心缓存一致性问题。
Write Behind Caching Pattern：调用者只操作缓存，由其它线程异步的将缓存数据持
Cache Aside Pattern:
删除缓存还是更新缓存？
更新缓存：每次更新数据库都更新缓存，无效写操作较多
删除缓存：更新数据库时让缓存失效，查询时再更新缓存
如何保证缓存与数据库的操作放在一个事务？
单体系统，将缓存与数据库操作放在一个事务
分布式系统，利用TTC等分布式事务方案
先操作缓存还是先操作数据库？
先删除缓存，再操作数据库
可能存在的问题：如果线程1删除缓存，由于逻辑再太复杂，还没由更新完数据库，这时线程2，进行查询缓存，发现缓存没有，进行查询数据库，查询到还未更改的数据，线程2将查询到数据写入缓存中，再写入缓存中操作完成后，线程1更新数据库，
最终会导致：缓存中的数据还是原来的数据，数据库中数据时新数据。
先操作数据库，再删除缓存
可能存在的问题：当线程1 查询缓存的时候刚好缓存失效了，查询数据库，查到的是原数据，这时线程2对数据库进行更新操作，更新完之后删除缓存，再删除2删除缓存之后，线程1将查到的数据写入缓存，
最终会导致：数据库中是更新后的数据，缓存中是原数据，缓存与数据库不一致
但是出现这种几率的很小，因为缓存的速度远远高于操作数据库的速度，所以先操作数据库，再删除缓存更好
缓存数据库双写不一致 优化解决方法
延时双删 再线程2删除缓存之后延时几百毫秒在删除一下缓存 不怎么靠谱。
分布式的读写锁 读多写少的情况下用。（写要排队 读不用排队）
写多读多的情况下还不知如何优化还请大佬帮忙，写在评论下，小弟带大家谢过大佬了
使用场景最佳实践方案：
低一致性需求：使用内存淘汰机制。
高一致性：主动更新，并以超时剔除作为补充
读操作：
缓存命中直接返回
缓存未命中则查询数据库，并写于缓存，设置超时时间
写操作：
先写数据库，然后在删除缓存
要确保数据库与缓存操作的原子性
