这篇文章将为大家详细讲解有关RabbitMQ怎么应用，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

成都创新互联是一家集网站建设,南平企业网站建设,南平品牌网站建设,网站定制,南平网站建设报价,网络营销,网络优化,南平网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

异步处理

场景：发送手机验证码，邮件

传统古老处理方式如下图

这个流程，全部在主线程完成，注册-》入库-》发送邮件-》发送短信，由于都在主线程，所以要等待每一步完成才能继续执行。由于每一步的操作时间响应时间不固定，所以主线程的请求耗时可能会非常长，如果请求过多，会导致IIS站点巨慢，排队请求，甚至宕机，严重影响用户体验。

现在大多数的处理方式如下图

这个流程是，主线程依旧处理耗时低的入库操作，然后把需要处理的消息写进消息队列中，这个写入耗时可以忽略不计，非常快，然后，独立的发邮件子系统，和独立的发短信子系统，同时订阅消息队列，进行单独处理。处理好之后，向队列发送ACK确认，消息队列整条数据删除。这个流程也是现在各大公司都在用的方式，以SOA服务化各个系统，把耗时操作，单独交给独立的业务系统，通过消息队列作为中间件，达到应用解耦的目的，并且消耗的资源很低，单台服务器能承受更大的并发请求。

应用解耦

以电商的下订单为例子，假设中间的流程为下单=》减库存=》发货

第一种方式，通过连续操作表，在单一系统中，通过主线程，连续操作。呵呵哒，这种做法，相信很多人刚入门，甚至几年经验了，由于项目小，也在继续使用吧。用户量少，或者都是内部人使用，必然没问题，因为不会在意出的问题，这种做法，只要一个环节出问题，请求直接报错，导致用户懵逼，假设在执行到减库存操作报错了，整个流程没有用事务回滚的话，还会造成数据不一致。

第二种方式，把这三个业务，拆成三个独立系统，通过JSON方式相互调用请求。这个做法，其实已经很不错了，起码独立出来，各自做各自的事情，一定程度上减小了整个系统的耦合性。但是问题是，就算是通过API形式请求，发送请求的系统一般情况下会等待被请求方的响应，如果响应错了，整个程序还是会终止，前面的业务系统假如已经做了入库操作，就必须要混滚了。很麻烦。如果说不等待被请求方响应的话，如果出错，如果还要保证数据一致性，就要做更多的操作，去补全数据，比如，下单成功，减库存失败，发货成功，这样当减库存系统修复后，就要通过订单数据，去补库存表的对应数据。先对麻烦，难处理。

第三种方式，

把消息队列作为中间件，当订单系统下完单后，把数据消息写入消息队列中，库存系统和发货系统同时订阅这个消息队列，思想上和纯API系统调用类似，但是，消息队列RabbitMq本身的强大功能，会帮我们做大量的出错善后处理，还是，假设下单成功，库存失败，发货成功，当我们修复库存的时候，不需要任何管数据的不一致性，因为库存队列未被处理的消息，会直接发送到库存系统，库存系统会进行处理。实现了应用的大幅度解耦。

流量削峰

这个主要用在团购，秒杀活动中

这个主要原理就是，控制队列长度，当请求来了，往队列里写入，超过队列的长度，就返回失败，给用户报一个可爱的错误页的等等。

日志处理

这个场景应该都很熟悉，一个系统有大量的业务需要各种日志来保证后续的分析工作，而且实时性要求不高，用队列处理再好不过了

消息通讯

现在上线的各大社交通讯项目中，实际上是没有用消息队列做即时通讯的，但是它确实可以用来做，有兴趣的不妨去试试吧

这个是点对点通信，消费者A和B同时订阅消息队列，又同时是制造者，就能实现点对点通信

群聊的做法，所有客户端同时订阅队列，又同时是发送，制造者。

区别

上述大致的5种RabbitMq的应用场景，下面来介绍几个消息队列的区别

ActiveMq:这个应用于JAVA中间件较多

ZeroMq:这个是分发效率最高的队列，是其他队列的十倍以上，缺点是不能数据持久化。

kafka：这是一种高吞吐量的发布订阅消息系统，当每秒达到10W+的分发要求时，可以用这个尝试，新浪微博就是用这个做分发。

RabbitMQ 上的一个 queue 中存放的 message 是否有数量限制？

可以认为是无限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降。

RabbitMQ 概念里的 channel、exchange 和 queue 这些东东是逻辑概念，还是对应着进程实体？这些东东分别起什么作用？

queue 具有自己的 erlang 进程；exchange 内部实现为保存 binding 关系的查找表；channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue 。由 AMQP 协议描述可知，channel 是真实 TCP 连接之上的虚拟连接，所有 AMQP 命令都是通过 channel 发送的，且每一个 channel 有唯一的 ID。一个 channel 只能被单独一个操作系统线程使用，故投递到特定 channel 上的 message 是有顺序的。但一个操作系统线程上允许使用多个 channel 。channel 号为 0 的 channel 用于处理所有对于当前 connection 全局有效的帧，而 1-65535 号 channel 用于处理和特定 channel 相关的帧。AMQP 协议给出的 channel 复用模型如下

其中每一个 channel 运行在一个独立的线程上，多线程共享同一个 socket。

关于“RabbitMQ怎么应用”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。

分享题目：RabbitMQ怎么应用
浏览路径：http://csdahua.cn/article/gjdejj.html