投递状态

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

• FLUSH_DISK_TIMEOUT

  如果 Broker 设置MessageStoreConfig的FlushDiskType=SYNC_FLUSH(默认是ASYNC_FLUSH)，并且代理没有在MessageStoreConfig的syncFlushTimeout(默认是5秒)时间内完成刷盘，您将获得这个状态。

• FLUSH_SLAVE_TIMEOUT

  如果 Broker 的角色是 SYNC_MASTER (默认是ASYNC_MASTER)，并且 Slave Broker 没有在MessageStoreConfig的syncFlushTimeout(默认是5秒)时间内完成同步，您将得到这个状态。

• SLAVE_NOT_AVAILABLE

  如果代理的角色是SYNC_MASTER(默认是ASYNC_MASTER)，但是没有配置 Slave Broker ，您将获得这个状态。

• SEND_OK

  SEND_OK 并不意味着它是可靠的。为了确保没有信息会丢失，应启用 SYNC_MASTER 或 SYNC_FLUSH

重复或者丢失消息

如果您得到FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT并且 Broker 恰好在此时意外宕机，您会发现你的消息丢失。此时，您有两个选择，一个是不管它，这可能导致这个消息丢失；另一个是重新发送消息，这可能会导致消息重复。我们经常建议重新发送，然后再消费时使用某个方法移除重复的消息。除非你觉得一些信息丢失并不重要。但是请记住，当您得到 SLAVE_NOT_AVAILABLE 状态时，重新发送是没有用的。如果出现这种情况，您应该保存场景并通知集群管理

超时

客户端发送请求到 Broker ，并等待响应，但如果最大等待时间过去了，没有返回响应，客户端就会抛出一个RemotingTimeoutException。默认的等待时间是3秒。您还可以使用 send(msg, timeout) 代替 send(msg) 来传递超时参数。注意，我们不建议等待时间过小，因为 Broker 需要一些时间来刷新磁盘或与 Slave 进行同步。而且，如果它超过 syncFlushTimeout，那么它的值可能不会有多大的影响，因为在超时之前，代理可能会以FLUSH_SLAVE_TIMEOUT或FLUSH_SLAVE_TIMEOUT返回响应。

消息大小

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

异步发送

默认 send(msg) 将阻塞直到返回的响应。所以如果你关心的是性能，我们建议你使用 send(msg, callback) ，这将会以异步方式发送。

生产者组

正常情况下，生产者组没有影响。但如果你开启了事物，你应该注意它。默认情况下，您只能在同一个JVM中只创建同一个生产者组，这通常是足够的。

线程安全

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

性能

如果您希望在一个JVM中有多个生产者进行大数据处理，我们建议：

• 与一些生产者一起使用异步发送(3 ~ 5就足够了)
• 为每个生产者setInstanceName