RabbitMQ消息队列

消息队列概念

什么是消息队列

• 消息是指应用减传送的数据
• 消息队列是一种应用间的通信方式解决方法，确保消息的可靠传递

主流消息队列

• 主流的包含：RabitMQ、ActiveMQ、RocketMQ、kafka、ZeroMQ等，小众的比如Beanstalk
• ActiveMQ
  • 基于JAVA语言开发，其社区算是比较成熟，但是目前来说，ActiveMQ的性能比较差，而且版本迭代很慢，不推荐使用。
• RocketMQ
  • 阿里出品，Java系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，并且RocketMQ有阿里巴巴的实际业务场景的实战考验。RocketMQ社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的
• Kafka
  • 由Scala和Java编写，其特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量。Kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。
• RabbitMQ
  • 在吞吐量方面虽然稍逊于Kafka和RocketMQ ，但是由于它基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为RabbitMQ基于erlang开发，所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
• ZeroMQ
  • 只是一个网络编程的Pattern库，将常见的网络请求形式（分组管理，链接管理，发布订阅等）模式化、组件化，简而言之socket之上、MQ之下。对于MQ来说，网络传输只是它的一部分，更多需要处理的是消息存储、路由、Broker服务发现和查找、事务、消费模式（ack、重投等）、集群服务等。

消息队列的术语

• Broker
  • 集群包含一个或多个服务器，每个服务器被称为broker
• Topic
  • 每条发布到Kafka集群的消息都有一个分类，这个类别被称为Topic（主题）
• Producer
  • 消息的生产者，负责发布消息到Kafka broker
• Consumer
  • 消息的消费者，从Kafka broker拉取数据，并消费这些已发布的消息
• Partition
  • 物理上的概念，每个Topic包含一个或多个Partition，每个partition都是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）
• Consumer Group
  • 消费者组，可以给每个consumer指定消费组，若不指定消费组，则属于默认的group
• Message
  • 消息，通信的基本单位，每个producer可以想一个topic发布一些消息

消息队列中两种工作模式

• Point-to-Point
  • 一方发送消息，另一方接受
• Pub/Sub
  • 即发布/订阅模式，消费者可以订阅一个或多个主题并使用该主题中的所有消息

消息队列的缺点

• 可用性降低

• 复杂性提高

• 数据一直性无法保证

• RabbitMQ相关术语

  • 生产者：产生消息的进程或服务
  • 消费者：接受消息的进程或服务
  • 队列：RabbitMQ是消息队列中间件，而真正存储消息数据的就是队列，队列可以有很多
  • 交换器：类似于网络设备交换机，它可以根据不同的关键字，将消息发送到不同的队列
  • 虚拟主机：虚拟主机提供了资源的逻辑分组和分割，每一个虚拟主机本质上是mini版的RabbitMQ服务器

Rabbit架构