于企业级应用开发领域内，消息传递所具备的可靠性以及效率是极其关键重要的，然而JMS标准里的两种核心模型直至如今依旧是诸多系统架构的基石 。

两种消息模型的核心差异

基于点对点模型，发送者需把消息放进指定队列，队列里的每条消息，只能被一个监听此队列的消费者获取并处理，处理完之后，该消息一般来说会从队列除掉，以此保证任务不会被重复执行 。

围绕主题进行展开的是发布订阅模型 ，此模型中 ，发布者会朝着某个主题去发送消息 ，而所有订阅了该主题的订阅者 ，都能够收到一份消息副本 ，这种模式适用于那种需要朝着多个系统进行同一事件广播或者通知的场景 ，新闻推送或者系统状态更新这类情况便为实例 。

P2P模型的关键角色与流程

在这个模型当中，主要涉及着三个角色，分别是消息生产者，消息队列以及消费者。消息生产者承担着创建并且发送消息至特定队列的职责，它和消费者之间不存在直接的耦合或者依赖关系。

消费者会从指定队列之内拉取，或者接收被推送给自身的消息。待消费成功以后，消费者一般会给消息服务器返回一个确认信号，服务器依据此信号把消息标记成已处理，进而执行移除操作，以此来确保消息的可靠传递。

Pub/Sub模型的关键角色与流程

发布订阅模式把主题当作居间媒介给引入了，发布者是把消息发送到主题那儿，而非发给具体的消费的人，主题承担着把消息分发给每一个处于活跃状态的订阅者的职责。

先将订阅者得给主题把自身的订阅关系去注册好，之后才能够收得到消息，这表明订阅者需维持在线状况，不然的话可能会错过发布之际它处于不在线情形下的消息，这就要求在系统设计之时要把持久化订阅等机制给考虑进去 。

常见挑战之消息积压与重复

生产者发送消息的速率远远超过消费者的处理能力之际，消息积压就会出现，这常常是因为流量瞬间急剧增加，或者消费者端出现业务逻辑方面的故障，又或者陷入了死循环等缘故造成的。

提升吞吐可通过临时增加消费者实例数量来解决积压。重复消费问题常常是因为消费者处理成功后，确认信号没法成功送达服务器引致的。在消费者业务逻辑里实现幂等性设计是最为有效的防护举措。

常见挑战之消息丢失与顺序

消息有可能于生产那个端点处，因为网络方面出现的问题从而遗失不见，还有可能在消费的那个端点处，鉴于自动确认这种机制在处理失败之前就实施提交操作进而导致遗失不见。挑选让消费者在处理成功之后手动去发送确认，能够切实有效地规避后面这种情况 。

消息顺序性的保障，其复杂度是比较高的，许多消息中间件，仅仅只能实现单个分区或者单一队列内部的顺序，若要达成全局范围的严格有序，一般情况下，要么牺牲性能，要么引入复杂性设计，比如说让所有消息都经由单一通道 。

消息中间件的选型与实践

当下市场之中，存在着多种达成JMS规范或者类似概念的产品，举例来说，有、、以及Kafka等等。它们于事务支持方面，在吞吐量方面，在顺序保证方面，以及在分布式能力方面，各自有着侧重之点。

业务场景要与技术选型紧密关联，比如说，针对那种对顺序有着极高要求的金融交易，能够选用支持全局有序的组件，然而对于吞吐量要求更为高些的日志处理场景而言，像Kafka等这样的流式平台或许会更加适宜，明白其底层机制乃是正确使用的前提条件。

在实际项目期间，你有没有碰到过消息顺序出现错乱的那种问题？那个时候采用的是哪一种中间件以及方案去解决的？欢迎于评论区之中分享你的相关经验！要是感觉本文存在一定帮助的话，也请进行点赞予以支持。