投递状态
发送消息时，将得到包含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
