图 3.2 快速失败和重试示意图
从使用方视角来看，业务的超时时间等同于整个完整 RR 调用的超时时间在线课堂。一次 RR 调用内部会涉及 2 次消息的发送，当 Broker 有故障时，可能会出现消息发送超时。因此，内部发送消息的超时时间设置会根据业务超时时间自动调整为较小的值，为失败重试留足更多的时间。比如业务超时时间为 3s ，则设置发送消息的超时为 1s 。通过调整消息发送超时时间来快速发现 Broker 的故障。当发现 Broker 的故障后， Producer 会立即重试另外一个 Broker ，并隔离失败的 Broker 。在隔离结束前， Producer 不会再将消息发到隔离的 Broker 上。
熔断机制
图 3.3 熔断示意图
熔断机制是指当某个队列消息堆积达到指定阈值后，不再往这个队列发送消息，使得这个队列对应的服务实例暂时熔断在线课堂。
为了实现熔断机制，队列增加了 “队列深度” 属性在线课堂。队列深度指一个队列中堆积在 Broker 上未被 Consumer 拉取的消息量。当 Consumer 发生故障或者处理异常，首先触发客户端的流控机制，随后拉消息请求会被不断地延迟，此时消息会堆积在 Broker 上。当 Broker 发现某个队列堆积的消息量超过阈值，会标记队列为熔断。Producer 发送消息时如果目标队列已经熔断，则会收到队列熔断的响应码，并立即重试，发送消息到另外的队列，同时将熔断的队列标记为隔离。在隔离解除前， Producer 不会再往隔离的队列发送消息。
隔离机制
队列级别的隔离机制主要用于 Producer 的重试和服务的熔断机制在线课堂。
图 3.4 隔离示意图
当 Broker 故障时， Consumer 拉消息会触发隔离机制在线课堂。原生 RocketMQ 的 Consumer 实现中，由 PullMessageService 单个线程向所有 Broker 发送拉消息请求。当这些 Broker 中有节点故障时， PullMessageService 线程会因为与故障 broker 建立连接或者请求响应变慢，导致线程暂时阻塞，这会让其它正常 Broker 的消息处理耗时变高甚至超时。因此，开发者为拉消息增加了一个备用线程，一旦发现拉消息的请求执行时间超过阈值，则标记这个 Broker 为隔离，对应的所有拉消息的请求转交给备用线程执行，保证 PullMessageService 执行的都是正常的 Broker 的请求。通过线程隔离来保证部分 Broker 的故障不会影响 Consumer 实例拉消息的时效。