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

前言:用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