分布式环境中，业务报错如何保证 redis 数据一致性？

共计 971 个字符，预计需要花费 3 分钟才能阅读完成。

这是一个困扰我很久的问题，一直不知道有什么好的处理方式，故来此地取经。
举个例子：
分布式订单服务 A 和库存服务 B
服务 A 调用服务 B，服务 A 修改了 redis 缓存，服务 B 报错了，全局事物回滚，服务 A 的缓存没有回滚
各位大佬，这种情况有什么推荐处理方式吗？

？你逻辑代码有问题吧，服务 A 调用服务 B 处理完成之后才写缓存吧，服务 B 报错那根本就到不了写缓存这一步，谁先写缓存的啊？交给消息队列来做

怎么做，人家标题是《如何保证 redis 数据一致性》，不是《如何进行流量削峰》服务 A 订阅服务 B 的回滚事件不就好了，咋感觉你这个不伦不类的啊，SOA 分布式中台这些基于数据共享，所以缓存基本都放生产服务那一侧，消费服务不会在本地留存的
微服务可以走数据复制，大多数都是 cqrs，查询用 restful 或者 rpc，消费服务本地可以留存缓存，变更多数走事件啊，出现问题，溯源一下，该订阅的订阅，该通知的通知。如果还是 rpc 那种命令式的调用，遇到这种问题不好说
分布式本质就是数据共享和数据复制两种模型，共享任何缓存都是放在生产者那一侧管理，消费者只管调用就好，有良好的封装性，多个服务组合一个业务过程，一致性由这个上层业务过程服务来协调，三段式就可以，错误冒出到最上层，然后向下层协调一致性。数据复制，消费者留存一份，你肯定不能通过命令接口互调，只能借助事件

你这种场景，有两种情况
1. 如果你 A 的数据是预热或上次查询得到，你就需要订阅 B 的事件
2. 如果这部分数据是业务中获得，就需要通过分布式事务方案，比如 saga，一层层回滚，同样是基于事件的
两者的区别是 1 是常态化订阅，2 是事务回滚我记得有个 sentinel…. 可以回滚失败的事务 …….. 没学过分布式，不过 A 作为订单服务器，不应该是接到订单后发给 B 处理，等 B 返回消息后才进行缓存吗其实可以用消息队列来保证最终一致性就可以，b 如果失败则发送消息到队列中 a 中订阅这个队列来做数据回滚，但是引入消息队又要妥善解决消息丢失，重复消费等问题，这也是一种方案