事故起因

​ 目前公司生产环境的mq 是一主一从的方式，但是uat 还是单节点的方式做的，这也导致了uat不能完全模拟生产环境，其实正常的基建是还有一个sit环境的，但是奈何资源不够。目前的话，要将uat环境跟生产环境同步，所以uat 也需要从单节点切换到一主一从双节点，接下来就是枯燥的环境搭建了，参考的是此篇文章

​ 搭建完后，应用配置里设置好双节点的配置，启动应用，发现mq消费者在疯狂的消费，而且一些消息看样子是很古老的消息，与我们现有代码数据不对，导致疯狂的报错，因此，开启了长达3天的问题排查

排查

​ 首先，排查配置，反复与生产配置文件进行对比，发现配置一摸一样，没任何问题，同时，代码也没有任何的改变，所以不存在逻辑上的问题。

​ 其实这里我已经想到了Brock 持久化的问题，但是我的持久化都是新的，都不知道这些消息是哪里来的，我第一反应就是内存，但是按理来说，这么久之前的mq消息，不可能会存在内存里那么久，同时，配置文件中也配置了mq消息最长存放为48小时，但是我还是重启了mq的服务器，重新把mq服务拉起来了，服务重启后，依旧是疯狂的消费历史消息。

​ 仔细看了一下消息，发现一年前的消息都有，但是我的Brock 配置的持久化文件时空的，也就是新建的，这些消息也不存在内存中

​ 这时候，突然发现，单节点的rocketMq 会在 /root 目录下默认生成 store 文件夹，用于存储mq 消息，都做了持久化的操作，当我把这个文件删除之后，应用归于平静

总结

​ 我又重新找了两台空闲机器把之前服务器单节点的store 文件搬过来了，然后模拟整个单节点切换双节点的操作，成功复线了这个问题，同样，删除root目录下的store 文件后，恢复正常，并且后续所有的mq 都正常的实例化到节点配置的store-a和 store-b文件夹中