更新Redis时是直接从数据库拉最新数据，还是要把改动再写回数据库呢？

关于更新Redis时如何处理与数据库的关系，这是一个在实际开发中经常遇到的问题，主要有两种常见的思路,具体选择哪一种取决于你的业务场景和对数据一致性的要求。

第一种思路：先更新数据库，再让Redis缓存失效（或更新）。 这是目前被广泛推荐的一种做法，它的核心步骤是：当数据发生变更时，首先去更新数据库（例如MySQL），在数据库更新成功之后，不是去主动更新Redis，而是直接删除Redis中对应的旧数据，当下一次有请求需要读取这个数据时，发现Redis里没有了（这称为“缓存未命中”），就会自动去数据库里拉取最新的数据，并把它重新加载到Redis中，这个过程也被称为“懒加载”或“Cache-Aside模式”。

这种做法的好处很明显，它逻辑简单，避免了同时写两个系统（数据库和Redis）的复杂操作，它减少了数据不一致的风险，如果先更新Redis再更新数据库，或者两个更新操作中间有间隔，其他请求可能会读到Redis里已经更新但数据库里还是旧数据的“脏数据”，先更新数据库，再删除缓存，虽然理论上在极短的时间窗口内也可能存在不一致（例如在数据库更新后、缓存删除前，有请求读到了旧的缓存），但概率较低，且最终会通过缓存删除而达到一致，许多技术社区，如《阿里开发者》杂志在讨论缓存一致性时，都倾向于这种方案，因为它简单有效,能覆盖绝大多数业务场景。

第二种思路：同时更新数据库和Redis（双写）。 这种思路是，在业务逻辑中，无论是新增、修改还是删除数据，都同步地、立即地去操作两个地方：先更新数据库，紧接着就更新Redis，试图让两者始终保持一致，这听起来很理想,但实际操作起来问题较多。

主要问题在于，这两个写操作很难保证“原子性”，即要么都成功，要么都失败，如果数据库更新成功了，但更新Redis时网络超时或失败了，那么Redis里就是旧数据，后续所有请求都会读到错误的数据，反之亦然，即使你尝试用事务来包裹，但Redis和数据库通常是两个独立的系统，无法实现真正的分布式事务，这会引入极大的技术复杂度，除非有非常特殊且简单的场景，否则这种双写模式在实践中很容易导致数据混乱，并不被主流所提倡，一些来自企业实践的技术分享（如早期某些博客关于“缓存双写”的讨论）也指出，这种方式维护成本高,一致性难以保证。

到底该选哪种呢？ 对于绝大多数读多写少、对短暂数据不一致有一定容忍度的业务（如用户信息、文章内容、商品详情等），首选第一种“先更新数据库，再删除缓存”，它的优点是可靠、简单，即使出现不一致，也是缓存里没有数据，会回源到数据库取到正确值，只是可能增加一次数据库查询而已，这是一种“最终一致”的思路。

只有在极少数对实时一致性要求极高，且能通过其他技术手段（如细粒度的锁、串行化队列等）来保证双写绝对成功的场景，才会考虑第二种，但即便如此,也需要投入大量精力来设计和验证。

还需要注意一个关键点： 无论采用哪种思路，在高并发场景下都可能遇到经典问题，在第一种思路下，如果数据库更新后，缓存删除失败怎么办？通常需要加入重试机制，例如将删除失败的key放入消息队列稍后重删，另一个著名问题是“缓存击穿”：当缓存失效的瞬间，大量请求同时涌向数据库去拉取同一份数据，这可以通过在回源加载数据时加锁、或者设置“逻辑过期时间”等策略来缓解。

最直接、最常用的答案就是：更新数据时，首先确保把最新数据写入数据库，成功之后，让Redis里对应的旧缓存失效即可。 让下一次读取请求自然地从数据库拉取最新数据并重新填充缓存，这样做，你是在以数据库为唯一准确的数据来源，而Redis只是它的一个加速副本，这个关系清晰,问题也更容易被控制和解决。