最近某些依赖rabbitMq做业务分解，功能没有实现，对本次排查问题做一个简单的总结：
1，首先，理清思路，利用rabbitmq做业务分解的大体思路是（我理解是这样的）：核心业务处理完毕——>生产者生产消息——>然投递到消息队列——>消息队列有消息——>消费者将接收消息——>做相关业务处理。
2，理清思路后，接下来要做的是确认环境一致，这其中包括redis（用的是库1，还是库几）,mongoDB,rabbit（链接地址），有的还可能牵着数据库。
3，确定环境后，再把业务跑一遍，查看是否有问题。我发现还有问题。于是准备本地环境发现问题，这里需要把所有环境换成本地的。
4，既然还有问题，那么就有几种可能：a,生产者这边的业务代码有bug，导致没有生产消息
b,生产者生产了消息，但是发送到错误的队列
c,mq环境有问题，导致发出了消息，但是队列里为空
d,消费者从错误的队列接收消息
e,队列里的消息，被别的消费者消费了
f,消费者接收到了消息，但是消费者这边的代码有bug,导致没有正常处理
g,消息的格式有问题
5,基于上述的猜测，对于我这个特定的业务，生产者可能有多个(从不同的端发送消息)，消费者只有一个（其实大部分都是这样的）。显然我先从生产者入手，是不太明确的（如果测试已告知某些系统发过来是正常的，那么就可以从不正常的生产者入手可能是最快的）。所以我决定先从消费者入手，而消费者这边的情况可能是edf,接下来就查看该消费者监听的消息队列是什么，假设是test.queue,进一步确认它接收的mqMsg的格式是什么，并准备相应的msg,然后就去rabbitMq后台管理界面，找到对应的test.queue，发现他的消费者确实只有一个，排除情况e,如下图：
6，启动本地消费者项目，在消费者处理的地方debug,把准备好的mq消息格式在后台界面的test.queue队列发送一条消息（个人建议先发一条，便于调试），如下图：
7,观察消息队列test.queue的情况发现，排除情况c,如下图，
8，观察此时消费者接收到消息，消息的解析没有异常，排除情况g，接着一步步断点，到整个消费者代码完成，都没有出错，查看结果，业务成功完成，排除情况f。
9，那么消费者，队列都没有问题，那么问题显然是生产者的，我接下来先确定有哪些系统，每个系统有哪些地方在生产消息。
10，启动每个生产消息的项目，依次debug,相关业务代码（由于有多个生产者，这一步是很耗时的），最终发现在用户系统下面有个类似的判断if(xxOptional.isPresent){生产消息},而根据之前业务代码发现xxOptional，无论怎么样始终为空，最后导致生产不了消息，而这个判断本身是无用的，可能是同事之前未考虑到这个情况，最后跟同事确认这个判断可以删掉。
11，解决生产者这边的问题后，本地测试，问题解决，最后再部署到测试环境测试，问题解决。
12，有的时候，可能是几种情况一起发生，应对这些情况，先从消费者入手，利用rabbitMq后台能较快排查问题。
