Redis缓存更新策略及数据库缓存双写不一致问题解决方案

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删除缓存之后延时几百毫秒在删除一下缓存   不怎么靠谱。

        分布式的读写锁    读多写少的情况下用。（写要排队  读不用排队）

        写多读多的情况下还不知如何优化还请大佬帮忙，写在评论下，小弟带大家谢过大佬了

使用场景最佳实践方案：
低一致性需求：使用内存淘汰机制。

高一致性：主动更新，并以超时剔除作为补充

        读操作：

                缓存命中直接返回

                缓存未命中则查询数据库，并写于缓存，设置超时时间

        写操作：

                先写数据库，然后在删除缓存

                要确保数据库与缓存操作的原子性