CAP的学习和应用

性能优化真言:队列缓存分布式  异步调优堆配置

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

一.CAP使用场景?

平时工做中常用到MQ,如(kafka,rabbitmq...),用来简单的发布/订阅,常常会遇到如下几个问题
A.SQL执行成功了,消息发送失败了
B.SQL执行失败了,消息发送成功了

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

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

我非要回滚

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

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

有没有更好的解决方案?

二.CAP是干什么用的?

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

这里简单说下强一致性,与最终一致性
强一致性,数据库里的CAID就是强一致性,它们对外永远只有一个状态,要么成功,要么失败
最终一致性,能容忍应用部分红功,在一段时间后,能达到所有成功状态
很明显在分布式环境里,任何东西都有可能宕机,如数据库,缓存,MQ都有可能出现问题,任何一个组件出现问题,都不影响业务最终执行的结果,这就是系统的稳定性

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

CAP具有传统EventBus的所有功能,简单的发布/订阅很是好理解,CAP在此基础上持久化了消息(就是把每条消息保存到了数据库),咱们仍是拿下单场景来讲明

当上游向中台发送消息失败时,CAP仍是会标注该业务执行成功,可是持久化在数据库里的消息状态是失败的,它会执行重试策略,重试策略执行完后,仍是失败,就不会重试了
这个时候很明显就是MQ挂了,修复MQ后,取出这些重试策略执行后任失败消息重新录入MQ便可

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

当中台接到上游订单后,执行分单的SQL错误了,怎么搞呢?
这个时候咱们应该把这个异常告诉它的上游, 简单来讲,就是当前服务已经GG了,请你不要给我再给我任务了,请把任务转给其余服务,若是没有任何服务可以执行任务,那么你帮我把消息缓存起来,等我修复好了,再执行这些任务

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

极端状况,中台的数据库挂了,至少上游缓存了全部发送的消息,咱们也能够经过这些消息进行溯源,从新消费这些消息便可

做者原文博客地址(建议完整的看一遍,你品,你细品):
https://www.cnblogs.com/savorboard/p/cap.html
https://www.cnblogs.com/savorboard/p/cap-document.html

四.CAP简单入门?

作为一个萌新,怎么优(jian)雅(dan)的使用CAP呢
首先你得须要一个MQ,这里推荐rabbitmq,操做简单,可视化页面功能强大,其次就是一个数据库(sqlserver,mysql,postgresql,mongodb)
而后就简单的配置一下链接就能够用了,帮助文档写的很是详细,这里就再也不赘述了,直接贴上地址

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

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

我在使用过程当中遇到的问题,大多数都很low,除了docker里装的kafka坑了我,其它基本上都没啥子问题
CAP使用过程当中遇到问题,能够去github上先搜下issues,任没法解决能够提issues