消息中间件

Posted 2021-03-02 wqbin

本文将从三步讲述消息中间件

• 从生产消费者模型到消息中间件
  • 生产消费者模型的作用以及适用场景
  • 手动实现消费生产者模型的缺陷
• 消息队列
• 消息中间件
  • 消息中间件的定义与常用类型
  • 消息中间价的操作
  • 消息中间件的选型
  • 消息中间的优缺点

 

消息队列

定义

消息队列，一般我们会简称它为MQ(Message Queue)，直白的说就是储存消息与释放消息的先进先出结构。

那么把数据放到消息队列叫做生产者，从消息队列里边取数据则被叫做消费者。

三大属性

作为消息队列一般具备如下3大属性：

• 消息顺序

　　　　分区有序的队列通过分布式处理，支持更高的并发，但由于队列的分布式特性，DMS无法保证能够以接收消息的精确顺序进行消费。如果用户要求保持顺序，建议在每条消息中放置排序信息，以便在收到消息时对消息重新排序。

全局有序的队列对消息消费遵循先入先出规则（FIFO），适用于对消费顺序要求较高的场景。

• 至少一次传递

　　　　在极少数情况下，当用户接收或删除消息时，存储消息副本的服务器之一可能不可用。如果出现这种情况，则该不可用服务器上的消息副本将不会被删除，并且在接收消息时可能会再次获得该消息副本。

这被称为“至少一次传递”，因此，用户的应用程序应该设计为幂等的应用程序（即，如果应用程序多次处理同一条消息，则不得受到不利影响）。

• 消息较少时单次消费不能获取指定数量的消息

　　　　从消息队列中消费消息时，DMS每次从部分消息存储分区中读取消息返回消息给消费者，如果队列中的消息数比较少，则单次消费可能会少于指定条数，但多次消费最终可获取全部消息。

功能与优点

• 解耦
• 弹性伸缩
• 冗余存储
• 流量削峰
• 异步通信
• 数据同步

1，解耦

我们作为A系统开发，当A系统处于1时刻的时候他只需需要向系统B与系统C提供相应的数据，但是因为某些原因B系统需要被D系统替代，那么我们要在A代码中去掉B系统的换成C系统。比如后来下游数据系统又出现问题，那么我们是不是又要更改代码。

但是我们可以直接发数据发送给相应的消息队列，然后让BCD。。。Z系统自己去改相应的代码，作为A系统开发的我们无需修改代码。这不仅是解耦。

同时也是一种数据使用规则，当上游系统已经提供相应的数据时，上游系统只提供相应的内聚接口，而下游对数据是否使用如何使用使用什么是由下游代码决定，而上游代码尽量无需修改。

2.异步

假设我们系统A还是直接向系统B、C、D传输相应的数据并没有使用消息队列且A系统只能使用单进程单线程，

当我们产生数据而且还要传输数据到B，可能系统B此时没有相应的资源去消费数据，那么我们的这个传输过程将会处于阻塞一直等待B系统有资源去消费数据,而且消费过程也是会占用我们的时间（同步）

，然后我们才能继续往CD等系统传输数据。

但是我们采用消息队列的方式，我们A系统只用负责往队列中填放数据即可,同时数据会被队列存贮（持久性），然后继续往队列中生产数据。与此同时，BCD系统可以自己从队列中直接取数据。

整个过程我们无须等待，所以是异步的。

 

3.流量削峰

假设我们作为系统A最高可以到每秒3000个请求，我们下游现在两个系统BC处理只能每次处理1000个请求，当我们因为业务原因导致下游要接受>1000的请求，就会导致下游系统的崩溃。

但是我们采用消息队列的方式，我们会把所有的请求都放在队列中，队列作为缓冲，下游只需要维持相应的不超过自身阈值的处理的速度即可，无需承担相应的压力。

 介绍完核心功能我们介绍以下几个非特性功能

 4.冗余存储

 

 

 

 

消息中间件

定义

官方的解释：

Middleware is computer software that provides services to software applications beyond those available from the operating system. 
It can be described as "software glue".
Middleware makes it easier for software developers to implement communication and input/output, so they can focus on the specific purpose of their application.

 

消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，

它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。

各类消息队列

ActiveMQ是Apache出品的、采用Java语言编写的完全基于JMS1.1规范的面向消息的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。不过由于历史原因包袱太重，目前市场份额没有后面三种消息中间件多，其最新架构被命名为Apollo，号称下一代ActiveMQ，有兴趣的同学可行了解。

RabbitMQ是采用Erlang语言实现的AMQP协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。RabbitMQ发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。

Kafka起初是由LinkedIn公司采用Scala语言开发的一个分布式、多分区、多副本且基于zookeeper协调的分布式消息系统，现已捐献给Apache基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark、Flink等都支持与Kafka集成。

RocketMQ是阿里开源的消息中间件，目前已经捐献个Apache基金会，它是由Java语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点，经历过双11的洗礼，实力不容小觑。

ZeroMQ号称史上最快的消息队列，基于C语言开发。ZeroMQ是一个消息处理队列库，可在多线程、多内核和主机之间弹性伸缩，虽然大多数时候我们习惯将其归入消息队列家族之中，但是其和前面的几款有着本质的区别，ZeroMQ本身就不是一个消息队列服务器，更像是一组底层网络通讯库，对原有的Socket API上加上一层封装而已。

目前市面上的消息中间件还有很多，比如腾讯系的PhxQueue、CMQ、CKafka，又比如基于Go语言的NSQ，有时人们也把类似Redis的产品也看做消息中间件的一种，当然它们都很优秀，但是本文篇幅限制无法穷极所有，下面会针对性的挑选RabbitMQ和Kafka两款典型的消息中间件来做分析，力求站在一个公平公正的立场来阐述消息中间件选型中的各个要点。