主流的消息队列MQ比较，详解MQ的4类应用场景，Java开发从零开始

最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。

当然有个时间限制，理论上越快越好，但实际上在各种异常的情况下，可能会有一定延迟达到最终一致状态，但最后两个系统的状态是一样的。

业界有一些为“最终一致性”而生的消息队列，如：

Notify（阿里）

QMQ（去哪儿）等

其设计初衷，就是为了交易系统中的高可靠通知。

以一个银行的转账过程来理解最终一致性，转账的需求很简单，如果A系统扣钱成功，则B系统加钱一定成功。反之则一起回滚，像什么都没发生一样。

然而，这个过程中存在很多可能的意外：

A扣钱成功，调用B加钱接口失败。

A扣钱成功，调用B加钱接口虽然成功，但获取最终结果时网络异常引起超时。

A扣钱成功，B加钱失败，A想回滚扣的钱，但A机器down机。

可见，想把这件看似简单的事真正做成，真的不那么容易。

所有跨VM的一致性问题，从技术的角度讲通用的解决方案是：

强一致性，分布式事务，但落地太难且成本太高，后文会具体提到。

最终一致性，主要是用“记录”和“补偿”的方式。在做所有的不确定的事情之前，先把事情记录下来，然后去做不确定的事情，结果可能是：成功、失败或是不确定，“不确定”（例如超时等）可以等价为失败。成功就可以把记录的东西清理掉了，对于失败和不确定，可以依靠定时任务等方式把所有失败的事情重新搞一遍，直到成功为止。

回到刚才的例子，系统在A扣钱成功的情况下，把要给B“通知”这件事记录在库里（为了保证最高的可靠性可以把通知B系统加钱和扣钱成功这两件事维护在一个本地事务里），通知成功则删除这条记录，通知失败或不确定则依靠定时任务补偿性地通知我们，直到我们把状态更新成正确的为止。

整个这个模型依然可以基于RPC来做，但可以抽象成一个统一的模型，基于消息队列来做一个“企业总线”。

具体来说，本地事务维护业务变化和通知消息，一起落地（失败则一起回滚），然后RPC到达broker，在broker成功落地后，RPC返回成功，本地消息可以删除。否则本地消息一直靠定时任务轮询不断重发，这样就保证了消息可靠落地broker。

broker往consumer发送消息的过程类似，一直发送消息，直到consumer发送消费成功确认。

我们先不理会重复消息的问题，通过两次消息落地加补偿，下游是一定可以收到消息的。然后依赖状态机版本号等方式做判重，更新自己的业务，就实现了最终一致性。

最终一致性不是消息队列的必备特性，但确实可以依靠消息队列来做最终一致性的事情。

另外，所有不保证100%不丢消息的消息队列，理论上无法实现最终一致性。好吧，应该说理论上的100%，排除系统严重故障和bug。

像Kafka一类的设计，在设计层面上就有丢消息的可能（比如定时刷盘，如果掉电就会丢消息）。哪怕只丢千分之一的消息，业务也必须用其他的手段来保证结果正确。

2.广播

消息队列的基本功能之一是进行广播。

如果没有消息队列，每当一个新的业务方接入，我们都要联调一次新接口。有了消息队列，我们只需要关心消息是否送达了队列，至于谁希望订阅，是下游的事情，无疑极大地减少了开发和联调的工作量。

比如本文开始提到的产品中心发布产品变更的消息，以及景点库很多去重更新的消息，可能“关心”方有很多个，但产品中心和景点库只需要发布变更消息即可，谁关心谁接入。

3.错峰与流控

试想上下游对于事情的处理能力是不同的。

比如，Web前端每秒承受上千万的请求，并不是什么神奇的事情，只需要加多一点机器，再搭建一些LVS负载均衡设备和Nginx等即可。

但数据库的处理能力却十分有限，即使使用SSD加分库分表，单机的处理能力仍然在万级。由于成本的考虑，我们不能奢求数据库的机器数量追上前端。

这种问题同样存在于系统和系统之间，如短信系统可能由于短板效应，速度卡在网关上（每秒几百次请求），跟前端的并发量不是一个数量级。

但用户晚上个半分钟左右收到短信，一般是不会有太大问题的。如果没有消息队列，两个系统之间通过协商、滑动窗口等复杂的方案也不是说不能实现。

但系统复杂性指数级增长，势必在上游或者下游做存储，并且要处理定时、拥塞等一系列问题。而且每当有处理能力有差距的时候，都需要单独开发一套逻辑来维护这套逻辑。所以，利用中间系统转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候，再处理这些消息，是一套相对较通用的方式。

消息队列使用总结

1.消息队列不是万能的，对于需要强事务保证而且延迟敏感的，RPC是优于消息队列的。

2.对于一些无关痛痒，或者对于别人非常重要但是对于自己不是那么关心的事情，可以利用消息队列去做。

3.支持最终一致性的消息队列，能够用来处理延迟不那么敏感的“分布式事务”场景，而且相对于笨重的分布式事务，可能是更优的处理方式。

4.当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的“漏斗”，在下游有能力处理的时候，再进行分发。
5.如果下游有很多系统关心你的系统发出的通知的时候，果断地使用消息队列吧。
以上是消息队列的讲解，以下是架构进阶资料，需要学习免费课程的狂戳。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

最后

俗话说，好学者临池学书，不过网络时代，对于大多数的我们来说，我倒是觉得学习意识的觉醒很重要，这是开始学习的转折点，比如看到对自己方向发展有用的信息，先收藏一波是一波，比如如果你觉得我这篇文章ok，先点赞收藏一波。这样，等真的沉下心来学习，不至于被找资料分散了心神。慢慢来，先从点赞收藏做起，加油吧！

另外，给大家安排了一波学习面试资料：

以上就是本文的全部内容，希望对大家的面试有所帮助，祝大家早日升职加薪迎娶白富美走上人生巅峰！

至于被找资料分散了心神。慢慢来，先从点赞收藏做起，加油吧！

另外，给大家安排了一波学习面试资料：

[外链图片转存中…(img-hbnuWutW-1711096727049)]

[外链图片转存中…(img-7uP38p9i-1711096727049)]

以上就是本文的全部内容，希望对大家的面试有所帮助，祝大家早日升职加薪迎娶白富美走上人生巅峰！

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录