这是一个困扰我很久的问题，一直不知道有什么好的处理方式，故来此地取经。
举个例子：
分布式订单服务 A 和库存服务 B
服务 A 调用服务 B ，服务 A 修改了 redis 缓存，服务 B 报错了，全局事物回滚，服务 A 的缓存没有回滚
各位大佬，这种情况有什么推荐处理方式吗？
热议
2楼 Salta 昨天19:40
？ 你逻辑代码有问题吧，服务A调用服务B处理完成之后才写缓存吧，服务B报错那根本就到不了写缓存这一步，谁先写缓存的啊？
3楼 liang0754 昨天19:46
交给消息队列来做
4楼 Salta 昨天19:49
交给消息队列来做
怎么做，人家标题是《如何保证 redis 数据一致性》，不是《如何进行流量削峰》
5楼 淡漠的茶 昨天19:52
服务A订阅服务B的回滚事件不就好了， 咋感觉你这个不伦不类的啊，SOA分布式中台这些基于数据共享， 所以缓存基本都放生产服务那一侧， 消费服务不会在本地留存的
微服务可以走数据复制，大多数都是cqrs ， 查询用restful 或者 rpc，消费服务本地可以留存缓存， 变更多数走事件啊， 出现问题，溯源一下， 该订阅的订阅，该通知的通知。如果还是rpc那种命令式的调用，遇到这种问题不好说
分布式本质就是数据共享和数据复制两种模型， 共享任何缓存都是放在生产者那一侧管理， 消费者只管调用就好，有良好的封装性， 多个服务组合一个业务过程，一致性由这个上层业务过程服务来协调，三段式就可以， 错误冒出到最上层， 然后向下层协调一致性。 数据复制， 消费者留存一份， 你肯定不能通过命令接口互调， 只能借助事件
6楼 liang0754 昨天19:54
怎么做，人家标题是《如何保证 redis 数据一致性》，不是《如何进行流量削峰》 ...
微服务 可靠事件模式
7楼 淡漠的茶 昨天20:19
你这种场景，有两种情况
1. 如果你A的数据是预热或上次查询得到，你就需要订阅B的事件
2. 如果这部分数据是业务中获得， 就需要通过分布式事务方案，比如saga， 一层层回滚， 同样是基于事件的
两者的区别是1是常态化订阅，2是事务回滚
8楼 plato0516 昨天22:06
我记得有个sentinel....可以回滚失败的事务........
9楼 蜗牛也是牛 昨天22:15
没学过分布式，不过A作为订单服务器，不应该是接到订单后发给B处理，等B返回消息后才进行缓存吗
10楼 darius 昨天23:51
其实可以用消息队列来保证最终一致性就可以，b如果失败则发送消息到队列中a中订阅这个队列来做数据回滚，但是引入消息队又要妥善解决消息丢失，重复消费等问题，这也是一种方案
申明：本文内容由网友收集分享，仅供学习参考使用。如文中内容侵犯到您的利益，请在文章下方留言，本站会第一时间进行处理。