越努力越幸运的博客

发送成功后，我们获取我们的Message可以看到，此时的content_type是 application/json，而消息的可读性也变高了，细心的小伙伴应该也可以看到，这里需要的字节数也变少了。为了看我们发送到rabbitMq的消息的形式，这里，我们还是把消费者服务先停掉，然后重新运行我们刚才发送User对象的测试方法。编写完成后，我们运行该方法。因此，我们正常使用的情况下，我们不会使用默认的JDK的序列化，而是会用我们的。为了观察我们发送到RabbitMQ的对象，我们这里先把监听服务关掉。

这种写法的好处就是，以后假如我们多了来自中国的其他东西，比如china.science，以及加拿大的新闻，我们的监听者都不需要修改任何代码。代码走一波，我们修改一下我们的发布者的代码。如此，如果我们现在要监听的是中国的所有消息，那么我们的routingKey就是。，如果我们想监听的是所有国家的新闻，那么我们的routingKey就是。可以看到，这里计算我们新加了其他的消息，我们的。的监听者成功监听了来自中国的新闻和天气预报。的监听者监听到了来自全世界的新闻。把消息路由到不同的队列。的所有消息，而我们的。

编写完代码，我们重启一下我们的消费者服务，然后我们看一下我们的RabbitMQ。可以看到，此时我们的交换机中，绑定的有两个queue，其中queue1监听的RoutingKey有blue和red、queue2监听的RoutingKey有yellow和red。可以看到，direct.queue1 监听到的消息有 Hello, Red 和 Hello, Blue，而direct.queue2 监听到的消息有 Hello, Red 和 Hello, Yellow.

*步骤二、在消费者服务中，编写两个消费者方法，分别监听 fanout.queue1 和 fanout.queue2。可以看到，只发布了一条消息，但是通过交换机发布给两个Queue后，我们消费者的两个方法都监听到了我们同一条消息。写完配置类，我们重启一下我们的消费者服务类，然后我们到RabbitMQ上看一下我们的交换机和队列。监听的方法，现在应该已经写得滚瓜烂熟了吧，这里就直接贴代码了。我们再看一下队列，可以看到，我们两个队列也都注册成功了。OK，这么解释肯定是不够的，下面我们就来说一下。

但是，如果现在我们的发布者他每秒发布100条数据，而我们的消费者每秒只能处理90条数据，那么每秒我们的队列将有10条数据被卡在队列中，而队列的容量是有限的，随着累计的时间长了，我们的消息也会因为来不及处理，导致后面发送的消息没来得及被接收就被销毁掉了。看到这里，有些人可能会好奇，怎么消费者1执行的都是奇数的消息，消费者2执行的都是偶数的消息，其实这个不是偶然哈，这个是必然的，现在我们把消费者1的睡眠时间改成5，消费者2的睡眠时间改为50，再看一眼结果。然后，我们编写我们的两个消费者。废话少说，代码走起！

然后，我们创建两个Module，一个叫publisher（发布者），一个叫consumer（消费者），为了尽可能地干净，我用IDEA，直接创建了两个空白的Maven工程。这里，我又跑去发送了两次，可以看到，我们都可以正常的接收到消息。下面，我们来写一个最简单的实例，首先，创建一个空白的Module作为父工程。里面一共有7个Demo，下面我们就根据他给的Demo进行实操，熟悉一下我们的RabbitMq。前面的两种，是最基本的，只有发布者和订阅者和一个队列，并没有我们的交换机。OK，发送我们会了，那么接收呢？

同步通讯：就像打电话，需要实时响应。异步通信：就像发微信，不需要马上回复。两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发微信可以同时与多个人收发信息，但是往往响应会有延迟。学SpringCloud的时候，我们的Feign 其实就是同步通讯的，他其实有以下这几个缺点耦合度高：（每次有新的需求，都需要更改代码）性能下降：（消费者需要等待提供者响应，如果调用链过长，那么响应的时间等于每次调用的时间之和）资源浪费。