40 RocketMQ的生产实践总结

1.灵活的运用tags来过滤数据

MQ中基于tags来过滤数据的功能,在真正的项目中,要合理的规划Topic和里面的tags,一个Topic代表了一类业务消息数据,然后对于这类业务消息数据,如果你希望能划分一些类别的话,可以在发送消息的时候设置 tags。

案例:如外卖平台有美团外卖、饿了么外卖等外卖,如果系统要发送外卖订单数据到MQ里去,就可以针对性的设置 tags ,比如不同的外卖数据都到一个 “WaimaiOrderTopic” 里去。

但是不同类型的外卖可以有不同的 tags : “meituan_waimai” 、“eleme_waimai”、"other_waimai" 等等。然后在消费“WaimaiOrderTopic” 的系统,可以根据 tags 来筛选。

2.基于消息 key 来定位消息是否丢失

前面讲过如何解决消息是否丢失的问题,如果消息真的丢失了,那么该怎么去排查该消息是否丢失?

MQ中可以基于消息key来实现查看消息是否丢失,比如通过设置一个消息的 key 为订单id: message.setKeys(orderId),这样这个消息就具备一个key了。

接着这个消息放到 broker 上,会基于 key 构建 hash 索引,这个 hash 索引就存放在 IndexFile 索引文件里。

后面就可以通过MQ提供的命令去根据 key 查询这个消息,类似这样:

mqadmin queryMsgByKey -n 127.0.0.1:9876 -t SCANRECORD -k orderId。

3. 消息零丢失方案的补充

在消息零丢失方案中,如果MQ集群整体故障了,那么该方案就不可用了。这时候,就需要有更高级别的高可用保障机制。

假设MQ集群彻底崩溃了,生产者应该把消息写入本地磁盘文件里去进行持久化,或者是写入数据库去暂存起来,等待MQ恢复后,再把持久化的消息继续投递到MQ里去。

4.提高消费者的吞吐量

如果生产的消息太多,或者消费的时候消费比较慢,就应该提高消费者的并行度,常见的就是部署更多的consumer机器。

要注意的是,Topic的MessageQueue数量不能少于consumer 数量,否则会有 consumer获取不到消息。

然后就是增加consumer的线程数量,可以设置 consumer端的参数: consumeThreadMin、consumeThreadMax,这样一台consumer机器上的消费线程越多,消费的速度就越快。

还可以开启消费者的批量消费功能,就是设置 consumeMessageBatchMaxSize参数,默认值是1,可以设置的多一些,那么一次就会交给消费者的回调函数一批消息来进行处理了,此时可以通过SQL语句一次性批量处理一些数据,比如: update xxx set xxx where id in (xx,xx,xx)。

5.要不要消费历史消息

consumer是支持设置从哪里开始消费消息的,常见的有两种:一个是从Topic的第一条数据开始消费,一个是从最后一次消费国的消息之后开始消费。对应的是:

CONSUME_FROM_LAST_OFFSET,

CONSUME_FROM_FIRST_OFFSET

一般来说,会选择 CONSUME_FROM_FIRST_OFFSET,这样刚开始就从Topic的第一条消息开始消费,但是以后每次重启,都是从上一次消费到的位置继续往后进行消费的。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值