Redis双写一致性，先改数据库再改缓存可以吗？有什么问题？

如问题所述，为什么市面上大部分方案都是先改数据库再删缓存

先改数据库再改缓存不可以吗？一般修改接口都会开启一个事务，update修改数据库后，再事务未结束前数据库锁并不会被释放，我们只需要在事务方法的最后一行修改缓存，并且每个接口的修改顺序都按照先改数据库再改缓存，这样有什么问题？

先操作数据库在操作缓存没问题啊，只要你的操作都是在同一个事务内就行。我觉得推荐改数据库再删缓存的那个是使用场景不同罢了

楼上gpt可没说错，你的redis是否开启事务？如果不开启事务，事务方法的最后一行，你觉得是先提交（或回滚）事务，还是先操作redis？

• 你可以看下这个问题的回答https://ask.csdn.net/questions/624668
• 你也可以参考下这篇文章：分布式系统中，缓存和数据库数据一致性问题总结
• 除此之外, 这篇博客: 数据库主从同步的作用是什么，如何解决数据不一致问题？中的 总结 部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读:
  

• 我今天讲解了数据库的主从同步，如果你的目标仅仅是数据库的高并发，那么可以先从 SQL 优化，索引以及 Redis 缓存数据库这些方面来考虑优化，然后再考虑是否采用主从架构的方式。

  在主从架构的配置中，如果想要采取读写分离的策略，我们可以自己编写程序，也可以通过第三方的中间件来实现。

  自己编写程序的好处就在于比较自主，我们可以自己判断哪些查询在从库上来执行，针对实时性要求高的需求，我们还可以考虑哪些查询可以在主库上执行。同时，程序直接连接数据库，减少了中间件层，相当于减少了性能损耗。

  采用中间件的方法有很明显的优势，功能强大，使用简单。但因为在客户端和数据库之间增加了中间件层会有一些性能损耗，同时商业中间件也是有使用成本的。我们也可以考虑采取一些优秀的开源工具，比如 MaxScale。它是 MariaDB 开发的 MySySQL 数据中间件。比如在下图中，使用 MaxScale作为数据库的代理，通过路由转发完成了读写分离。同时我们也可以使用 MHA 工具作为强一致的主从切换工具，从而完成 MySQL的高可用架构。

  

  

• 您还可以看一下 大壮老师的计算机软件行业入门指导视频教程课程中的 如果有其他行业资源可以不考虑从事计算机行业小节, 巩固相关知识点