一、redis缓存更新策略
缓存更新是Redis为了节约内存而设计出来的一个东西，主要是因为内存数据宝贵，当我们向Redis插入太多数据，此时就可能会导致缓存中的数据过多，所以Redis会对部分数据进行更新，或把他叫为淘汰更合适。
自动淘汰：
当Redis内存达到
max-memory限制时，启动自动淘汰机制。可配置多种淘汰策略（如LRU、TTL、LFU等），移除不重要或即将过期的数据。
超时剔除：
为键设置TTL（过期时间），超时后Redis自动删除，释放空间。
主动更新：
针对数据库更新导致的缓存与数据不一致问题，手动调用方法删除指定缓存。
注意：需要确保后续读取请求获取最新数据，保持数据一致性。
业务场景：
低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存。
高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存。
二、数据库缓存不一致解决方案
当数据库更新后，若缓存未能同步，会导致用户看到过时数据，引发业务逻辑错误、用户体验下降及系统稳定性问题。一般采用以下三种策略：
Cache Aside Pattern 人工编码方式，双写方案：
应用程序在更新数据库后，立即手动更新或删除对应缓存。
优点：实现简单，灵活控制。适用于读多写少场景。
注意：并发更新可能导致的缓存问题，如击穿、雪崩，需采取相应防范措施。
Read/Write Through Pattern 系统级集成：
使用中间件或服务层自动同步数据库与缓存，所有读写操作均通过该层进行。
优点：简化开发，自动保证一致性。适用于对一致性要求高的场景。
注意：可能增加系统复杂度，对某些复杂查询或数据模型需定制支持。
Write Behind Caching Pattern 异步缓写，最终一致性：
应用程序仅更新缓存，后台任务异步批量写入数据库，实现最终一致性。
优点：大幅提升写入性能，适合大量写入且能容忍短暂不一致的场景。
注意：确保可靠的异步处理机制，应对读取“临时”数据及系统故障导致的任务积压或丢失。
