一.摘要 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 1.消息的顺序问题 2.消息的重复问题 二.关键特性以及其实现原理 2.1.顺序消息 要实现严格的顺序消息,简单且可行的办法就是: 保证生产者 - MQServer - 消费者是一对一对一的关系 这样的设计虽然简单易行,但也会存在一些很严重的问题,比如: 1.并行度就会成为消息系统的瓶颈(吞吐量不够) 2.更多的异常处理,比如:只要消费端出现问题,就会…

一.消息的顺序性 1.延迟队列:设置一个全局变量index,根据实际情况一次按照index++的逻辑一次给消息队列设置延迟时间段,可以是0.5s,甚至1s; 弊端:如果A,B,C..消息队列消费时间不一致或者出现网络延迟,就会存在后者比前者先消费完的场景: 2.统一消费端:当A消费成功后,通过ACK或者consummer-success通知B进行消费 弊端:降低了系统的吞吐量,需要更多的异常处理机制 3.RocketMQ采用轮询所有队列的方式来确定消息被发送到哪一个队列(负载均衡),比如下面示例…

1.为什么要保证顺序 消息队列中的若干消息如果是对同一个数据进行操作,这些操作具有前后的关系,必须要按前后的顺序执行,否则就会造成数据异常.举例: 比如通过mysql binlog进行两个数据库的数据同步,由于对数据库的数据操作是具有顺序性的,如果操作顺序搞反,就会造成不可估量的错误.比如数据库对一条数据依次进行了 插入->更新->删除操作,这个顺序必须是这样,如果在同步过程中,消息的顺序变成了 删除->插入->更新,那么原本应该被删除的数据,就没有被删除,造成数据的不一致问题.…

rocketmq总结(消息的顺序.重复.事务.消费模式) 参考: http://www.cnblogs.com/wxd0108/p/6038543.html https://www.cnblogs.com/520playboy/p/6750023.html https://blog.csdn.net/chunlongyu/article/details/53977819 https://blog.csdn.net/zhanglianhai555/article/details/77604582?…

备注:1.如果您此前未接触过RocketMQ,请先阅读附录部分,以便了解RocketMQ的整体架构和相关术语2.文中的MQServer与Broker表示同一概念 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了三个问题: 消息的顺序问题 消息的重复问题 消息的可靠性 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性…

最近遇到一个问题,服务站点上线之前,先去新建需要的rabbitmq并绑定关系,此时 如果发送消息方运行, 那边会造成新建的q消息部分堆积得不到及时消费 那么问题来了? 在消息堆积情况下,服务站点无法启动,导致一直卡在那里的情况. 而消费端干了什么呢? 1.调用第三方服务查询数据 2.查询数据库数据并更新操作 经过调试我们分析下,在调用第三方服务的时候,卡在那里 了 那么什么原因导致呢? spring在启动的时候,会监听q 执行消费,而消费里面的逻辑代码中的相关组件还没初始化导致. 怎么解决这个问…

1.大量消息在mq里积压了几个小时了还没解决 场景:几千万条数据在MQ里积压了七八个小时,从下午4点多,积压到了晚上很晚,10点多,11点多.线上故障了,这个时候要不然就是修复consumer的问题,让他恢复消费速度,然后傻傻的等待几个小时消费完毕.这个肯定不行.一个消费者一秒是1000条,一秒3个消费者是3000条,一分钟是18万条,1000多万条. 所以如果你积压了几百万到上千万的数据,即使消费者恢复了,也需要大概1小时的时间才能恢复过来. 解决方案:" 这种时候只能操作临时扩容,以更快的速…

最近起了个项目消息中心,用来中转各个系统中产生的消息,用到的是RabbitMQ,由于UAT环境.生产环境每台消费者服务都是多台,有些消息要求按顺序消费,所以需要采取一定的措施保证消息的顺序消费,下面讲下我们不断优化的三种方法: 1.我们最开始考虑的比较简单,采用的direct交换机,指定特定消费者服务器监听队列,其他消费者服务器不监听.比如现在有C1.C2.C3三台消费者机器,我们决定C1消费消息,C2.C3不监听.我们在启动C1的时候,启动脚本中添加C1_IP,在代码中做处理,消费者服务器启动…

1.如何保证消息的顺序 原因:生产者将消息发给topic,topic分发给不同的队列再给多个消费者并发消费,难以保证顺序. 方案:topic和队列之间加入MessageQueueSelector.将一组业务的消息发给同一个队列,并锁住发给某一个消费者消费. 2.如何保证消息不被重复消费 原因:由于网络波动或者消费者本地事务耗时长,让MQ认为失败,从而重复推送消息,但此时消费者的事务是成功了的. 方案:所有MQ都没有提供解决消息重复消费的方案. 需要消费者自行去重,如将RocketMQ给每个消息产…

在说到消息中间件的时候,我们通常都会谈到一个特性:消息的顺序消费问题.这个问题看起来很简单:Producer发送消息1, 2, 3... Consumer按1, 2, 3...顺序消费. 但实际情况却是:无论RocketMQ,还是Kafka,缺省都不保证消息的严格有序消费! 这个特性看起来很简单,但为什么缺省他们都不保证呢? “严格的顺序消费”有多么困难 下面就从3个方面来分析一下,对于一个消息中间件来说,”严格的顺序消费”有多么困难,或者说不可能. 发送端 发送端不能异步发送,异步发送在发送失…