前言:用CAP有一段时间了,这里简单记录一下,这么好用的东西,小伙伴们赶紧上车吧

一.CAP使用场景?

平时工作中经常使用到MQ,如(kafka,rabbitmq...),用来简单的发布/订阅,经常会遇到以下几个问题

常用方案,把SQL放前面,MQ放后面,MQ执行失败了,我们把整个SQL进行回滚,这种方案在单应用下是可行的,它的回滚成本并不高

我们模拟一个简单的分布式场景:上游下单->中台分单->下游发货

我非要回滚

站在业务角度分析,客户满足下单条件,已经下单成功了,但是上游服务在给中台发送MQ的时候失败了,这种情况很明显是不允许回滚的

补救的办法,就是标记这个订单的状态,给客户一个假成功的状态,后台再写个任务调度去处理,每个发送消息的地方都得这样处理,非常的麻烦费事,而且业务跟MQ耦合在一起了

有没有更好的解决方案?

二.CAP是干什么用的?

CAP提供分布式事务的最终一致性解决方案

这里简单说下强一致性,与最终一致性

三.CAP是如何实现最终一致性的?

CAP具备传统EventBus的全部功能,简单的发布/订阅非常好理解,CAP在此基础上持久化了消息(就是把每条消息保存到了数据库),我们还是拿下单场景来说明

当上游向中台发送消息失败时,CAP还是会标注该业务执行成功,但是持久化在数据库里的消息状态是失败的,它会执行重试策略,重试策略执行完后,还是失败,就不会重试了

CAP是基于数据库的强一致性来实现最终一致性的,简单来说,就是执行业务的SQL,跟持久化消息的SQL在一个事务里

当中台接到上游订单后,执行分单的SQL错误了,怎么搞呢?

CAP 在发布/订阅的基础上新增了一个回调,中台会把任务的执行结果通知给上游, 回调相当于中台给上游发消息,上游根据回调的结果决定接下来怎么做

极端情况,中台的数据库挂了,至少上游缓存了所有发送的消息,我们也可以通过这些消息进行溯源,重新消费这些消息即可

作者原文博客地址(建议完整的看一遍,你品,你细品):

https://www.cnblogs.com/savorboard/p/cap-document.html

四.CAP简单入门?

做为一个萌新,怎么优(jian)雅(dan)的使用CAP呢

http://cap.dotnetcore.xyz/user-guide/zh/getting-started/quick-start/

五.CAP使用中遇到的问题?

原文链接：https://www.cnblogs.com/tibos/p/11858095.html

---

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com