因为一台物理机内存故障导致操作系统异常重启，我的年终奖怕是悬了

前段时间发生一次很“悲催”的事，临近年末我维护的生产MQ集群中的一台物理机内存故障导致操作系统异常重启，在10分钟内众多的应用发送客户端出现消息发送超时，事故并定性为S1，而我今年的“年终奖”怕是悬了。。。

1、故障描述

RocketMQ 集群采取的部署架构为2主2从，其部署架构如下图所示：

其部署架构中一个非常明显的特点是一台物理机上分别部署了 nameserver，broker 两个进程。

其中一台机器(192.168.3.100)的内存出现故障，导致机器重启，但Linux操作系统由于重启需要自检等因素，整个重启过程竟然持续了将近10分钟，客户端的发送超时持续10分钟，这显然是不能接受的！！！

RocketMQ的高可用设计何在？接下来我们将详细介绍其分析过程。

2、故障分析

当得知一台机器故障导致消息发送超时持续10分钟，我的第一反应是不应该呀，因为 RocketMQ 集群是分布式部署架构，天然支持故障发现与故障恢复，消息发送客户端能自动感知 Broker 异常的的时间绝对不会超过10分钟，那故障又是怎么发生的呢？

首先我们来回顾一下RocketMQ的路由注册与发现机制。

2.1 R