最近，这是一个悲伤的提醒。临近年底，作者维护的生产MQ集群中的一台物理机出现内存故障，导致操作系统异常重启。最后10分钟，很多应用发送客户端超时发送消息，导致意外，被认定为S1，我的“年终奖” 1.故障描述:RocketMQ集群采用的部署架构是两主两从，其部署架构如下图所示:此处插一张图描述其部署架构的一个非常显著的特点是在一台物理机上部署两个进程，nameserver和broker。 其中一台机器(192.168.3.100)出现内存故障，导致机器重启。但是Linux操作系统整个重启过程居然持续了近10分钟，用户端发送超时持续了10分钟，这显然是不可接受的！！！RocketMQ的高可用性设计是怎样的？接下来，我们将详细介绍分析过程。 2.故障分析。当我得知是机器故障导致故障持续10分钟时，我的第一反应是不应该。因为RocketMQ集群是分布式部署架构，天然支持故障发现和恢复，所以消息发送客户端自动感知代理异常的时间绝不会超过10分钟。故障是怎么发生的？首先，我们来回顾一下RocketMQ的路由注册和发现机制。 2.1 RocketMQ路由注册和拒绝机制这里插一张图描述一下它的路由注册和拒绝机制。描述如下:集群中的所有代理每30秒向集群中的所有名称服务器发送心跳包，注册主题路由信息。 当名称服务器接收到来自代理的心跳包时，它将首先更新路由表，并记录接收心跳包的时间。 名称服务器将启动一个计划任务，每10秒钟扫描一次代理。如果名称服务器在120秒内没有收到代理的心跳包，它将确定代理已经离线，并将代理从路由表中删除。 如果名称服务器和代理之间的长连接断开，名称服务器将立即检测到代理离线，并将代理从路由表中删除。 消息客户端(消息发送者和消息消费者)在任何时候都只与其中一个名称服务器建立连接，并且每30秒向名称服务器查询一次路由信息。如果找到查询结果，将更新发送方的本地路由信息。 从以上路由注册和拒绝的机制来看，当一个代理服务器宕机时，发送方需要多长时间才能感知到路由信息的变化？分以下两种情况讨论:当NameServer和Broker服务器之间的TCP连接断开时，NameServer可以立即感知到路由信息的变化，并将其从路由表中删除，这样消息发送方在30s左右就可以感知到路由的变化。在这30s内，消息发送失败会发生在发送方，但发送回避机制的组合不会给发送方带来严重的失败，这是可以接受的。 如果名称服务器和代理服务器之间的TCP连接没有断开，但代理无法再提供服务(例如假死)，则名称服务器需要120秒才能感知到代理宕机，消息发送方最多需要150秒才能感知到其路由信息的变化。 但问题是，为什么一个经纪人在实际生产过程中会因为内存故障重启，重启成功10分钟后业务才恢复，即业务真正感知到经纪人宕机？现在它出现了，我们需要分析它并给出解决方案，以避免在生产环境中出现相同类型的错误。 2.2故障排除后，首先查询客户端的日志(/home/{ user }/logs/rocketmqlogs/rocketmq _ client . log)，从中可以看到客户端发送第一条上报消息的时间是14:44，日志输出如下:此处插一张图描述192.168.3.100机器内存故障。因此，首先，检查集群中其他名称服务器的日志，看看普通机器中的名称服务器感知代理失败的时间。日志如下:此处插一张图描述192.138.3.101的名称服务器感知其宕机时间约为2分钟，即即使机器正在重启，然而由于其他原因，如操作系统的硬件自检，TCP连接并未断开，因此名称服务器直到120s才感知其宕机，并将代理从路由信息表中移除。按照路由淘汰机制，用户终端应该在150秒内感知到它的变化，为什么没有呢？继续查看用户的路由信息，查看用户感知路由信息发生变化的时间点，如下图:此处插一张图描述根据用户的日志，用户直到14:53:46才感知到变化。为什么？原来用户终端在升级路由信息时报告了异常超时，截图如下::此处插一张图描述用户终端从故障到故障恢复期间，一直试图从故障的名称服务器升级路由信息，但一直返回超时，导致用户终端无法获取最新的路由信息，因此一直无法感知下行代理。 从日志分析来看，到目前为止还是很清楚的。用户终端在120秒内没有感知到其路由信息变化的原因是，用户终端一直在尝试从down nameserver升级路由信息，但是由于请求一直无法成功，导致用户终端缓存的路由信息一直无法升级，导致了上述现象。这就是问题所在。根据我们对RocketMQ的理解，当名称服务器宕机时，客户端会自动从名称服务器列表中选择下一个名称服务器，那么为什么名称服务器切换没有发生在这里，而是等到14:53？接下来重点介绍一下NameServer的切换代码，其代码片段如下图所示:这里插一张图描述上图中的几个关键分析，如下:客户端可以通过缓存中的连接发送RPC请求的前提是channel的isActive方法返回true，即底层TCP连接被激活。 当客户端向服务器发起RPC请求时，如果有非超时异常，将执行closeChannel方法，这将关闭连接并将其从连接缓存表中删除。这一点非常重要，因为在切换名称服务器时，如果缓存中有连接并且该连接是活动的，则名称服务器不会被切换。 如果发送RPC超时，rocketmq会根据clientCloseSocketIfTimeout参数决定是否关闭连接，但很遗憾，这个参数默认为false，没有修改的条目。 这里对问题的分析非常清晰，因为机器内存故障触发重启，重启前需要自检，导致nameserver，broker无法解析请求，但是底层TCP连接没有断开，导致超时错误。但是，客户端不会关闭与故障机器名称服务器的TCP连接，导致无法切换。重启机器时，TCP连接断开，故障机器感知到重启后路由信息的变化，故障恢复。 经过对以上问题的分析，故障原因如下:192.168.3.100机器内存故障后重启，整个重启耗时10分钟，重启过程中没有断开TCP连接。192.168.3.101名称服务器直到发送故障约2分钟后才发现路由变化，但一些客户端连接到192.168.3.100。客户端试图从名称服务器查询路由信息，但它一直返回超时。因为连接没有关闭，所以客户端不会切换到3.101名称服务器，直到客户端和名称服务器之间的TCP连接断开，然后它切换到另一个3.101名称服务器，并且在指定的时间内恢复了故障。 根本原因:其实是nameserver的假死导致路由信息没有升级。 3.最佳实践经过上面的失败，我个人觉得不应该用broker部署nameserver。如果不将nameserver和broker部署在一起，可以有效避免上述问题，其部署架构如下图所示:这里插一张图描述这样的部署架构。如果面对以上失败，经纪人装死能有效避免吗？答案是肯定的。 如果192.168.3.100的broker假死，那么3.110和3.111的名称服务器都可以在2分钟内感知到broker-a宕机，然后客户端就可以成功从名称服务器获取最新的路由信息。如果nanmeserver，broker死亡并发生超时错误，它仍然可以通过缓存正常工作，但是如果Nanme Server和broker一起伪造死亡，它仍然可以正常工作。 因此，这个最佳实践主要包括以下两个方面:1 .名称服务器和代理必须单独部署并隔离。 2.名称服务器和客户端的连接应该在超时后关闭，这将触发名称服务器的漂移。源代码需要修改。作者:中间件兴趣圈参考链接:https://blog.csdn.net/prestige/article/details/11772703