1 如何保证消息顺序?
如何实现消息有序?实现顺序消息所必要的条件:顺序发送、顺序存储、顺序消费。
在MQ模型中,顺序需由3个阶段去保障
顺序发送: 发送时保持顺序一致
顺序存储: broker 存储时保持 顺序一致
顺序消费: 消费时 保持 顺序一致
2 消息有序的两大类型
有序消息,又叫顺序消息(FIFO消息),指消息的消费顺序和产生顺序相同。
如订单的生成、付款、发货,这串消息必须按序处理。
顺序消息又可分为全局有序和局部有序:
全局有序:整个MQ系统的所有消息严格按照队列先入先出顺序进行消费
局部有序:只保证一部分关键信息的消费顺序
2.1 全局顺序
一个Topic内所有的消息都发布到同一Q,按FIFO顺序进行发布和消费:
落地到RocketMQ,如何保证全局有序?
为了 保证Topic全局消息有序的方式,就是将Topic配置成只有一个唯一的MessageQueue队列, 默认是4个MessageQueue。
RocketMQ中,可以在发送者发送消息时指定一个MessageSelector对象,让这个对象来决定消息发入哪一个MessageQueue。这样就可以保证一组有序的消息能够发到同一个MessageQueue里。
适用场景
性能要求不高,所有消息严格按照FIFO进行消息发布和消费的场景。
2.2 分区顺序
对于指定的一个Topic,所有消息按sharding key进行区块(queue)分区,同一Queue内的消息严格按FIFO发布和消费。
Sharding key是顺序消息中用来区分不同分区的关键字段,和普通消息的Key完全不同。
落地到RocketMQ。而MessageQueue是RocketMQ存储消息的最小单元,他们之间的消息都是互相隔离的,在这种情况下,是无法保证消息全局有序的,但是可以保证局部有序。
默认的做法是,发送消息时,会通过MessageQueue轮询的方式保证消息尽量均匀分布到所有的MessageQueue上,而消费者也就同样需要从多个MessageQueue上消费消息。这就做不到局部有序。
对于局部有序的要求,只需要将有序的一组消息都存入同一个MessageQueue里,这样MessageQueue的FIFO设计天生就可以保证这一组消息的有序。
适用场景
性能要求高,根据消息中的sharding key去决定消息发送到哪个queue。
其实大部分的MQ业务场景,我们只需要保证局部有序就可以了。
例如
我们用QQ聊天,只需要保证一个聊天窗口里的消息有序就可以了。
而对于电商订单场景,也只要保证一个订单的所有消息是有序的就可以了。
2.3 对比
发送方式对比
存储方式对比
无
消费方式对比
有序消费的消费者类型:ConsumeMessageConcurrentlyService 并发消费服务
无序消费的消费者类型:ConsumeMessageOrderlyService
3 应用开发维度的实现消息有序需要做的工作:
实现顺序消息所必要的条件:顺序发送、顺序存储、顺序消费。 顺序存储环节,RocketMQ 里的分区队列 MessageQueue 本身是能保证 FIFO 的。
所以,在应用开发过程中,不能顺序消费消息主要有两个原因:
顺序发送环节,消息发生没有序:Producer 发送消息到 MessageQueue 时是轮询发送的,消息被发送到不同的分区队列,就不能保证 FIFO 了。
顺序消费环节,消息消费无序:Consumer 默认是多线程并发消费同一个 MessageQueue 的,即使消息是顺序到达的,也不能保证消息顺序消费。
我们知道了实现顺序消息所必要的条件:顺序发送、顺序存储、顺序消费。
顺序存储 由 Rocketmq 完成,所以,在应用开发层, 消息的顺序需要由两个阶段保证:
消息发送有序
消息消费有序
4:canal+MQ,如何实现有序?
Canal 是阿里巴巴开源的一个增量订阅和消费的中间件,用于基于 MySQL 的数据库增量日志解析(Binlog)。通过 Canal,可以实现对数据库的实时监控和数据同步。
我们在通过Canal把MySQL的Binlog数据发送到MQ(kafak/rocketmq)时,需要关注好几个环节:
Cannal 的有序监听。 Binlog本身是有序的,写入到mq之后如何保障顺序
Cannal 的有序发送。
顺序存储: broker 存储时保持 顺序一致
顺序消费: 消费时 保持 顺序一致
4.1 Cannal 的有序发送
canal目前支持kafka和rocketmq,在使用 Canal 进行数据同步时,保证数据的有序性是一个重要的问题,尤其是在分布式环境中。在 Kafka 或 RocketMQ 等消息队列中,消息的顺序性和分区策略至关重要。
canal 本质上都是基于本地文件的方式来支持分区级别的顺序消息,也就是binlog写入mq是可以有一定的顺序性保障,这个保障级别取决于用户的两个配置项:
canal.mq.partitionsNum
canal.mq.partitionHash
两个配置项 用于控制消息的分区和顺序。两个配置项介绍如下:
canal.mq.partitionsNum:
描述:设置消息队列的分区数量。
作用:决定了消息在消息队列中被分区的数量。不同的分区可以并行处理,但需要注意同一个分区内的消息是有序的。
canal.mq.partitionHash:
描述:设置消息分区的哈希规则。
作用:用于指定分区的哈希策略,可以根据特定的字段进行分区。例如,可以根据表名、主键等字段进行分区,以保证某些关键数据的有序性。
4.2 Cannal 的有序发送示例
假设我们希望将数据同步到 Kafka,并且需要保证某张表的数据是有序的,可以使用以下配置:
canal.mq.partitionsNum=10
canal.mq.partitionHash=my_database.my_table:id
配置解释
canal.mq.partitionsNum=10:
表示消息会被分成 10 个分区。每个分区可以并行处理,从而提高处理效率。
canal.mq.partitionHash=my_database.my_table
针对 my_database.my_table 表的数据,根据 id 字段进行哈希分区。
这样可以确保同一个 id 的所有变更都进入同一个分区,从而保证该 id 的变更顺序不变。
通过配置 canal.mq.partitionHash,分区内的消息是有序的,因此只要保证同一实体(如同一行数据)的变更进入同一个分区,就能保证其有序性。
4.3 Cannal 的使用场景
实时数据同步:将数据库的变更实时同步到其他系统,如搜索引擎、缓存等。
数据备份:实现数据库的实时备份,确保数据的一致性和完整性。
事件驱动架构:在事件驱动架构中,利用 Canal 将数据库变更作为事件发布到消息队列,供其他系统消费。
通过合理配置 canal.mq.partitionsNum 和 canal.mq.partitionHash,可以在数据同步中既保证有序性,又提高处理效率。