4.7.1版
功能特性
官方网站说明Producer的send方法本身支持内部重试。 重试逻辑如下。
最多重试两次。 如果同步模式发送失败，旋转将移动到下一个Broker，如果异步模式发送失败，则仅在当前Broker上重试。 此方法的总时间不超过sendMsgTimeout设置的值，默认值为10s。 如果自己向broker发送消息，导致超时异常，则不会重试。
以上策略也在一定程度上保证了消息的发送成功。 如果业务要求消息可靠，建议添加相应的重试逻辑。 例如，如果调用send同步方法发送失败，请将消息保存在db中，然后定期在后台线程上重试，以确保消息始终到达Broker。注意
异步发送将在发送期间发生异常并重试。 在分析请求的结果时，在响应状态代码中发现了其他异常。 消息可能未在浏览器中正确处理。 重试将保持选择当前broker。 但是，如果响应结果不为空，则即使在响应处理中发生异常也不进行重试。 同步发送时，如果发送过程中没有异常，但发送结果不OK，请选择其他broker继续重试。 需要打开这个设定项目。 retryanotherbrokerwhennotstoreok。 序列消息是同步和发送异步指定消息队列的方式的发送，不认为是序列发送。 由于异步发送不能保证信息的顺序，所以尽管发送中发生异常而不进行重试，但发送完成后的处理逻辑和异步方式一样，如果发送状态不满足指定条件，则继续重试。 与one-way方式相比，异步发送流程更为特殊，不等待结果，因此与其他方式不同，在返回不存在等结果后考虑是否继续重试，但发送时与同步发送相同。 例外情况是源代码org.Apache.rocket MQ.client.impl.producer.defaultmqproducerimpl # senddefaultimpl (finalcommunicationmmon )
发送消息的过程：发送消息- senddefaultimpl-sendkernelimpl，重试逻辑位于senddefaultimpl中，发送失败，重试，然后再次调用sendkernelimpl以返回消息
序列消息不重试的原因：序列发送进程：发送消息-sendKernelImpl，因此没有重试逻辑
选择发送消息的重试队列时，如果有多个broker master，则下次重试的broker与上次重试的broker不同
生产者的重试由于重试失败的消息，所以不进行重试。 以下是从官方文件中摘录的说明
因为broker的处理能力成为瓶颈，生产者消费者的消费能力成为瓶颈。 生产者：
如果commitLog文件的锁定时间超过osPageCacheBusyTimeOutMills，则参数将默认设置为1000ms，并返回流量控制。 打开transientStorePoolEnable==true，如果broker是异步画笔主机，且transientStorePool缺少资源，则拒绝当前的send请求并返回到流控制。 broker每10ms检查一次send请求队列中第一个请求的等待时间，如果超过waitTimeMillsInSendQueue，则默认为200ms，拒绝当前的send请求，并返回流控制。 broker通过拒绝send请求实现流量控制。 请小心。 生产者不会尝试重新发布消息。 消费者：如果消费者的本地缓存消息数超过pullThresholdForQueue，则默认值为1000。 如果消费者本地缓存消息的大小超过pullThresholdSizeForQueue，则缺省值为100MB。 如果消费者本地缓存消息的跨度超过consumeConcurrentlyMaxSpan，则默认值为2000。 消费者的结果是取现频率下降。 发送时允许重试的异常remotingexceptionmqclientexceptionmqbrokerexception不会重试以下响应代码。 caseresponsecode.topic _ not _ exist : caseresponsecode.service _ not _ available 3360 caseresponsecode.sys ponse permme 0 caseresponsecode.not _ in _ current _ unit :否则，不重试mqbrOKerexcepper的发送状态不是ok (状态代码为response code.flush
所以，这是不重试的原因，broker将返回状态代码remotingsysresponsecode.system _ busy