RabbitMQ消息队列
一：消息队列简介1：主流的消息队列
目前主流的几大消息队列有：RabitMQ、ActiveMQ、RocketMQ、Kafka、ZeroMQ等，也有一些小众的比如Beanstalk，固然我们之前学过的Redis也可以实现消息队列的功能。
（1）ActiveMQ
基于JAVA语言开辟，其社区算是比较成熟，但是目前来说，ActiveMQ的性能比较差，而且版本迭代很慢，不推荐使用。
（2）RocketMQ
阿里出品，Java系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，而且RocketMQ有阿里巴巴的实际业务场景的实战考验。RocketMQ社区活跃度相对较为一般，不外也还可以，文档相对来说简单一些，然后接口这块不是按照尺度JMS规范走的有些系统要迁移需要修改大量代码。另有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术气力我觉得用RocketMQ挺好的
（3）Kafka
由Scala和Java编写，其特点实在很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以恣意扩展。同时kafka最好是支撑较少的topic数目即可，包管其超高吞吐量。Kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其稍微的影响，在大数据领域中以及日志采会合，这点稍微影响可以忽略这个特性天然适合大数据实时盘算以及日志收集。
（4）RabbitMQ
在吞吐量方面固然稍逊于Kafka和RocketMQ ，但是由于它基于erlang开辟，以是并发能力很强，性能极其好，延时很低，达到微秒级。但是也由于RabbitMQ基于erlang开辟，以是国内很少有公司有气力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ肯定是你的首选。如果是大数据领域的实时盘算、日志采集等场景，用Kafka是业内尺度的，绝对没问题，社区活跃度很高，绝对不会黄，何况险些是全世界这个领域的事实性规范。
（5）ZeroMQ
只是一个网络编程的Pattern库，将常见的网络请求形式（分组管理，链接受理，发布订阅等）模式化、组件化，简而言之socket之上、MQ之下。对于MQ来说，网络传输只是它的一部分，更多需要处理的是消息存储、路由、Broker服务发现和查找、事务、消费模式（ack、重投等）、集群服务等。
2：各种差异消息队列的对比
(1) RabbitMQ/Kafka/ZeroMQ都能提供消息队列服务，但有很大的区别。
(2) 在面向服务架构中通过消息代理（比如 RabbitMQ / Kafka等），使用生产者/消费者模式在服务间举行异步通信是一种比较好的思想。
(3) ZeroMQ和RabbitMQ/Kafka 差异，它只是一个异步消息库，在套接字的基础上提供了雷同于消息代理的机制。使用ZeroMQ的话，需要对自己的业务代码举行改造，不利于服务解耦。
(4) RabbitMQ支持AMQP（二进制），STOMP（文本），MQTT（二进制），HTTP（里面包装其他协议）等协议。而Kafka使用自己的协议。
(5) Kafka自身服务和消费者都需要依赖Zookeeper。
(6) RabbitMQ在有大量消息堆积的情况下性能会下降，Kafka不会，毕竟AMQP筹划的初衷不是用来持久化海量消息的，而Kafka一开始是用来处理海量日志的。
总的来说，RabbitMQ和Kafka都是十分优秀的分布式的消息代理服务，只要合理摆设，不作，基本上可以满意生产条件下的任何需求。
3：消息队列中角色/名词
（1）Broker：
消息服务器，作为server提供消息核心折务
（2）Producer：
消息生产者，业务的发起方，负责生产消息传输给broker
（3）Consumer：
消息消费者，业务的处理方，负责从broker获取消息并举行业务逻辑处理
（4）Topic：
主题，发布订阅模式下的消息统一汇集地，差异生产者向topic发送消息，由MQ服务器分发到差异的订阅者，实现消息的广播
（5）Queue：
队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
（6）Message：
消息体，根据差异通信协议定义的固定格式举行编码的数据包，来封装业务数据，实现消息的传输
4：消息队列中两种工作模式
（1）Point-to-Point
实在就是点对点，其过程理解起来比较简单。它好比是两个人打电话，这两个人是独享这一条通信链路的。一方发送消息，另外一方接收，就这么简单。在点对点模式下，消息被保留在队列中。 一个或多个消费者可以斲丧队列中的消息，但是特定消息只能由最多一个消费者消费。 一旦消费者读取队列中的消息，它就从该队列中消散。 该模式的典型示例，如订单处理系统，此中每个订单将由一个订单处理器处理，但多个订单处理器也可以同时工作。
（2）Pub/Sub
即发布/订阅模式，该模式有点雷同于我们日常生活中订阅报纸。对于每一个订阅者来说，可以选择一份或者多份报纸。那么这些我们订阅的报纸，就相当于发布订阅模式里的topic。有很多个人订阅报纸，也有人可能和我订阅了相同的报纸。多人订阅了相同的报纸相当于多人在同一个topic里注册了。对于一份报纸发行方来说，它和全部的订阅者就构成了一个1对多的关系。在这种模式下，消息被保留在主题中。 与点对点模式差异，消费者可以订阅一个或多个主题并使用该主题中的全部消息。 该模式下消息生产者称为发布者，消息使用者称为订阅者。
5：消息队列缺点
由于消息队列的异步特性，直接提升了整个架构的处理效率，提升了用户体验。但凡事都有两面性，消息队列在带来性能提升的同时也伴随着缺陷。
（1）系统可用性降低
毕竟在整个架构中，我们单独加了一个消息队列中心件，以是增加了风险，如果消息队列服务挂掉，势必会影响到整个架构。
（2）系统复杂性提高
原来非常简单的一个逻辑筹划，但偏偏要在中心插入一个消息队列，以是这增加了步伐员的工作量，需要思量如何包管消息没有被重复消费、消息有没有丢失、消息顺序等细节问题。
（3）数据一致性无法包管
消息如果没有正确写入到消息队列里，或者说读取消息的服务并没有正确读取到消息，这都会影响到数据的一致性。
二：RabbitMQ先容
RabbitMQ是一款在环球范围内使用非常广泛的开源消息队列中心件。它轻量级、易摆设、并支持多种协议。它基于Erlang开辟，天生拥有高并发的能力。
1：RabbitMQ相干术语
（1）生产者
产生消息的进程或服务
（2）消费者
接收消息的进程或服务
（3）队列
RabbitMQ是消息队列中心件，而真正储存消息数据的就是队列，队列可以有很多。
（4）交换器
雷同于网络设备交换机，它可以根据差异的关键字，将消息发送到差异的队列。
https://i-blog.csdnimg.cn/direct/37e1b6e6c4f94ca7a57157cf2e96c856.png
（5）假造主机
假造主机雷同于Apache的假造主机，如果没有假造主机，当RabbitMQ中的数据越来越庞大，队列越来越多，随之而来的是令人头痛的管理问题，比如队列、交换器命名冲突，它们相互影响等等。假造主机能够办理这些问题，而不需要我们摆设多个RabbitMQ来负责差异的业务。
假造主机提供了资源的逻辑分组和分隔，每一个假造主机本质上是mini版的RabbitMQ服务器，他们有用自己的连接、队列、绑定、交换器，更紧张的是有用自己的权限机制，这有点雷同服务器和运行在服务器上的假造机一样。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]