生产者最佳实践

一些对用户有用的提示。

SendStatus

发送消息时，您将得到包含SendStatus的SendResult。 首先，我们假设Message的isWaitStoreMsgOK = true（默认为true）。 如果没有，我们将永远得到SEND_OK，如果没有例外抛出。 以下是关于每个状态的说明列表：

FLUSH_DISK_TIMEOUT

如果代理设置MessageStoreConfig的FlushDiskType = SYNC_FLUSH（默认为ASYNC_FLUSH），并且代理在MessageStoreConfig的syncFlushTimeout（默认为5秒）内没有完成刷新磁盘，则会得到该状态。

FLUSH_SLAVE_TIMEOUT

如果Broker的角色是SYNC_MASTER（默认为ASYNC_MASTER），并且从代理未在MessageStoreConfig的syncFlushTimeout（默认为5秒）内完成与主代理的同步，则将获得此状态。

SLAVE_NOT_AVAILABLE

如果Broker的角色是SYNC_MASTER（默认为ASYNC_MASTER），但没有配置从代理，则会得到此状态。

SEND_OK

SEND_OK并不意味着它是可靠的。 为了确保不会丢失任何消息，您还应该启用SYNC_MASTER或SYNC_FLUSH。

重复或丢失

如果您获得FLUSH_DISK_TIMEOUT，FLUSH_SLAVE_TIMEOUT和经纪人正好关闭的那一刻，您可以找到您的消息丢失。 在这个时候，你有两个选择，一个是让它走，这可能会导致这个消息丢失; 另一个是重新发送消息，这可能会导致消息重复。 我们经常建议重新发送，并找到一种方法来处理消费时的重复删除。 除非你觉得丢失一些信息并不重要。 但请记住，重新获得SLAVE_NOT_AVAILABLE时没有用处。 如果发生这种情况，您应该保持现场并提醒群集管理器。

超时

客户端向Broker发送请求并等待响应，但如果最大等待时间已过，并且没有响应返回，则客户端将引发RemotingTimeoutException。 默认的等待时间是3秒。 您也可以使用send（msg，timeout）而不是send（msg）传递timeout参数。 请注意，我们不建议等待时间太短，因为代理需要一些时间来刷新磁盘或与从服务器同步。 此外，如果超过syncFlushTimeout的值可能会影响很小，因为在超时之前，代理可能会返回带有FLUSH_SLAVE_TIMEOUT或FLUSH_SLAVE_TIMEOUT的响应。

消息大小

我们建议消息的大小不能超过512K。

异步发送

默认发送（msg）会阻塞，直到返回响应。 所以如果你关心性能，我们建议你使用send（msg，callback），它将以异步的方式工作。

生产者 Group

通常情况下，生产者组没有任何效果。 但如果你涉及到事务，你应该注意它。 默认情况下，只能在同一个JVM中仅创建一个具有相同生产者组的生产者，这通常就足够了。

线程安全

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

性能

如果您想让一个JVM中的多个生产者进行大数据处理，我们建议：

  • 与少数生产者使用异步发送（3〜5就够了）
  • 为每个生产者setInstanceName

results matching ""

    No results matching ""