RocketMQ概念详细之Producer

本文详细解析了消息发送过程中的各种状态,包括FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT、SLAVE_NOT_AVAILABLE及SEND_OK等,探讨了如何处理消息丢失或重复问题,并提供了优化建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

发送状态

当你发送一个消息,你将会获得包含SendStatus的SendResult。首先,我们假设消息 isWaitStoreMsgOK=true(默认true)。如果没有,我们会得到 SEND_OK,没有异常抛出的话。
下面是每个状态的描述列表:

FLUSH_DISK_TIMEOUT

如果broker设置 MessageStoreConfig’s 的 FlushDiskType=SYNC_FLUSH(默认ASYNC_FLUSH),在MessageStoreConfig’s 的syncFlushTimeoutbroker(默认5秒)内没有完成刷盘,你会获得此状态。

FLUSH_SLAVE_TIMEOUT

如果broker的角色是SYNC_MASTER(默认ASYNC_MASTER),在MessageStoreConfig’s 的syncFlushTimeoutbroker(默认5秒)内从Broker没有完成与主同步,你会获得此状态。

SLAVE_NOT_AVAILABLE

如果broker的角色是SYNC_MASTER(默认ASYNC_MASTER),但是配置的从Broker不存在,你会获得此状态。

SEND_OK

SEND_OK也不意味着可靠。为了确保没有消息丢失,还应该启用 SYNC_MASTER或SYNC_FLUSH。

Duplication or Missing

如果得到FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT 和Broker正好关闭,你可以发现消息丢失。此时,你有两种选择,一个是放手可能引起消息丢失;另一个是重发消息,可能会使消息重复。通常我们建议重发和寻找一种方式处理消费时的重复删除。除非你感觉丢失的消息不重要。但请记住,当SLAVE_NOT_AVAILABLE时,重发时无用的。
如果发生,你应该保留场景同时警告集群管理者。

超时

客户端发送请求到broker,然后等待响应,但如果等待时间过久且没有响应返回,客户端将会抛出RemotingTimeoutException异常。默认等待时间3秒。你可以使用send(msg, timeout) 代替 send(msg)传递超时参数。
我们不建议等待时间太短,因为broker需要时间刷盘或与从同步。
如果该值超过syncFlushTimeout,则该值可能影响不大,因为Broker可能会在超时之前返回FLUSH_SLAVE_TIMEOUT或FLUSH_SLAVE_TIMEOUT的响应。

消息大小

建议消息的大小不能超过512k。

异步发送

默认send(msg) 将会阻塞,直到响应返回。因此如果你关系性能,我们建议使用 send(msg, callback)以异步方式执行。

生产者群组

通常,生产者群组没有任何效果。但是如果你涉及事务,你应该注意。默认情况下,你只需要在同一个JVM上创建一个具有相同群组的生产者,就足够啦。

线程安全

生产者是线程安全的,你可以在业务解决方案中使用。

性能

如果在一个JVM上你需要多个producer用于大数据处理,我们建议:

  • 这些(3~5够用)生产者使用异步发送
  • 每个生产者设置实例名称
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值