摘要:将消息持久化成功之后,向发送方确认消息已经发送成功,此时消息为半消息。发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认,仍按照步骤对半消息进行操作。
1.应用场景解耦
异步
流量消峰
日志记录
消费端处理消息的业务逻辑保持幂等性
保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现
Producer对于需要顺序的消息发送到同一个queue中
Consumer使用MessageListenerOrderly来对消息进行有序消费
发送方向 MQ 服务端发送消息。
MQ Server 将消息持久化成功之后,向发送方 ACK 确认消息已经发送成功,此时消息为半消息。
发送方开始执行本地事务逻辑。
发送方根据本地事务执行结果向 MQ Server 提交二次确认(Commit 或是 Rollback),MQ Server 收到 Commit 状态则将半消息标记为可投递,订阅方最终将收到该消息;MQ Server 收到 Rollback 状态则删除半 消息,订阅方将不会接受该消息。
在断网或者是应用重启的特殊情况下,上述步骤4提交的二次确认最终未到达 MQ Server,经过固定时间后 MQ Server 将对该消息发起消息回查。
发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。
发送方根据检查得到的本地事务的最终状态再次提交二次确认,MQ Server 仍按照步骤4对半消息进行操作。
push模式:客户端与服务端建立连接后,当服务端有消息时,将消息推送到客户端。
pull模式:客户端不断的轮询请求服务端,来获取新的消息。
但在具体实现时,Push和Pull模式都是采用消费端主动拉取的方式,即consumer轮询从broker拉取消息。
长轮询即是在请求的过程中,若是服务器端数据并没有更新,那么则将这个连接挂起,直到服务器推送新的 数据,再返回,然后进入循环周期。 客户端像传统轮询一样从服务端请求数据,服务端会阻塞请求不会立刻返回,直到有数据或超时才返回给客 户端,然后关闭连接,客户端处理完响应信息后再向服务器发送新的请求。
7. 消息模式DefaultMQPushConsumer实现了自动保存offset值以及实现多个consumer的负载均衡。
//设置组名
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("HAOKE_IM")
通过groupname将多个consumer组合在一起,那么就会存在一个问题,消息发送到这个组后,消息怎么分配呢? 这个时候,就需要指定消息模式,分别有集群和广播模式。
集群模式
同一个 ConsumerGroup(GroupName相同) 里的每 个 Consumer 只消费所订阅消息的一部分内容, 同
一个 ConsumerGroup 里所有的 Consumer消费的内容合起来才是所订阅 Topic 内容的整体, 从而达到
负载均衡的目的 。
广播模式
同一个 ConsumerGroup里的每个 Consumer都 能消费到所订阅 Topic 的全部消息,也就是一个消息会
被多次分发,被多个 Consumer消费。
// 集群模式
consumer.setMessageModel(MessageModel.CLUSTERING);
// 广播模式
consumer.setMessageModel(MessageModel.BROADCASTING);
8. 存储机制
8.1 消息数据的存储
在RocketMQ中,消息数据是保存在磁盘文件中,为了保证写入的性能,RocketMQ尽可能保证顺序写入,顺序写入的效率比随机写入的效率高很多。
RocketMQ消息的存储是由ConsumeQueue和CommitLog配合完成的,CommitLog是真正存储数据的文件,
ConsumeQueue是索引文件,存储数据指向到物理文件的配置。
同步刷盘
在返回写成功状态时,消息已经被写入磁盘 。
具体流程是:消息写入内存的 PAGECACHE 后,立刻通知刷盘线程刷盘,然后等待刷盘完成,刷盘线程
执行完成后唤醒等待的线程,返回消息写成功的状态 。
异步刷盘
在返回写成功状态时,消息可能只是被写入了内存的 PAGECACHE,写操作的返回快,吞吐量大
当内存里的消息量积累到一定程度时,统一触发写磁盘动作,快速写入。
broker配置文件中指定刷盘方式
flushDiskType=ASYNC_FLUSH -- 异步
flushDiskType=SYNC_FLUSH -- 同步
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/7150.html
摘要:将消息持久化成功之后,向发送方确认消息已经发送成功,此时消息为半消息。发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认,仍按照步骤对半消息进行操作。1.应用场景 解耦 异步 流量消峰 日志记录 2.重复消息的解决方案 消费端处理消息的业务逻辑保持幂等性 保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现...
摘要:将消息持久化成功之后,向发送方确认消息已经发送成功,此时消息为半消息。发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。发送方根据检查得到的本地事务的最终状态再次提交二次确认,仍按照步骤对半消息进行操作。1.应用场景 解耦 异步 流量消峰 日志记录 2.重复消息的解决方案 消费端处理消息的业务逻辑保持幂等性 保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现...
摘要:具体可以参考消息队列之具体可以参考实战之快速入门十分钟入门阿里中间件团队博客是一个分布式的可分区的可复制的基于发布订阅的消息系统主要用于大数据领域当然在分布式系统中也有应用。目前市面上流行的消息队列就是阿里借鉴的原理用开发而得。 我自己总结的Java学习的系统知识点以及面试问题,目前已经开源,会一直完善下去,欢迎建议和指导欢迎Star: https://github.com/Snail...
摘要:降级往往会指定不同的级别,面临不同的异常等级执行不同的处理。谈谈你对和的认识两者关系具体可以看公众号阿里巴巴中间件的这篇文章独家解读从微服务框架到微服务生态与并不是竞争关系,作为成熟的框架,其易用性扩展性和健壮性已得到业界的认可。 该文已加入笔主的开源项目——JavaGuide(一份涵盖大部分Java程序员所需要掌握的核心知识的文档类项目),地址:https://github.com/...
摘要:降级往往会指定不同的级别,面临不同的异常等级执行不同的处理。谈谈你对和的认识两者关系具体可以看公众号阿里巴巴中间件的这篇文章独家解读从微服务框架到微服务生态与并不是竞争关系,作为成熟的框架,其易用性扩展性和健壮性已得到业界的认可。 该文已加入笔主的开源项目——JavaGuide(一份涵盖大部分Java程序员所需要掌握的核心知识的文档类项目),地址:https://github.com/...
阅读 690·2023-04-25 19:43
阅读 3881·2021-11-30 14:52
阅读 3736·2021-11-30 14:52
阅读 3802·2021-11-29 11:00
阅读 3752·2021-11-29 11:00
阅读 3819·2021-11-29 11:00
阅读 3535·2021-11-29 11:00
阅读 6023·2021-11-29 11:00