朝着先能干活的方向努力。。。奥利给！！！06

上篇文章了解了什么是中间件。了解了消息中间件，本来应该从开源的mq开始学习，但是时间紧凑，直接从公司的mq开搞！

中间件mq

公司提供了mq服务。因此mq服务不用我们下载软件手动安装了。我们直接使用mq服务即可。

首先先了解一下一些基本的产品名词

基础概念相关名词

生产者producer：消息的发送端。向broker发送消息的端

消费者consumer：消息的订阅端。从broker订阅消息的端

broker：mq消息中间件的服务端实例，就是消息中间件服务本身

消息体message：业务方通过mq服务传递的消息内容。在发送时客户端会对消息进行压缩

主题topic：代表一种消息类型，是全局惟一的。

队列：队列是存储消息的一种数据结构，四最基本的消息服务单元。先进先出。

队列数：mq服务在创建主题之后，默认会给该主题在每个broker上分配n个队列。每个队列内的消息先进先出。

连接数：客户端与服务端的连接数。

分片：每个分片包含一主一从两个broker实例，主从自动同步，八保存一份相同的数据

消息类型相关名词

普通消息：生产者发送一条消息后，具有订阅关系的所有消费者的某一个实例能够消费该消息。

普通顺序消息、严格顺序消息：生产者发送一系列消息后，消费端严格按照发送的顺序进行消费

广播消息：生产者发送一条消息后，具有订阅关系的所有消费者的所有实例都能够消费该消息

事务消息：生产者发送一条消息后，可以控制是否提交，是否回滚

功能特性相关名词

积压：消费端处理不过来入队数所导致的消息堆积。积压数=入队数-出队数。消息的消费速度小于消息的生产速度

重试：消费失败后，消息会被重试。

批量消费：消费端对队列中的消息进行批量消费。队列中的消息被拉取后，队列会被锁。这样就导致了消费的并发受队列数的限制

延迟消费：broker服务端收到消息延迟一段时间才允许消费端进行消费。

并行消费：正常的消费因为队列被锁，所以并发性不高。通过增加消费窗口，来提高拉取消息的策略为并行消费

归档：消息被成功消费后，若开启归档，消息将异步归档到云存储。

就近发送：生产消息时，生产端的消息会优先发送给与客户端同机房的broker

消息模型

一般消息中间件的消息模型是“发布--订阅模型“””

主题是一组同样消息的集合，是发布和订阅消息的基本单位

生产者是生产并发送消息的应用程序，消费者是接收并消费消息的应用程序

接入mq的客户端无论是生产者还是消费者都需要先订阅主题，订阅主题后才有权限对主题生产消息或消费消息

通常一个主题包含多个mq分片（一个分片包含一主一从两个broker，主broker用于收发消息，从broker用于备份数据）

用户实例

其实就是生产者和消费者。一个主题下面可以有多个生产者实例，每个实例都可以向主题的所有队列发送消息，但消息仅能被发送到一个队列。

消费者也可以包含多个实例，每个实例都可以从主题的所有队列接收消息，但一个消息仅能被消费一次

高可用

一般公司自己内部封装的mq都不是一个单点服务，一般都是高可用集群。高可用的体现，一个主题下的消息通常都分布在多个broker上。并且每个broker都是采用一主一从的架构。这样即使一主坏了，一从也可以进行数据的接收和消费。

高可靠

一般的mq服务，都能保证消息的不丢失。。。。。

消息的有序性

消息的有序性是通过主题保证的。

一般普通主题不能保证消息顺序。

顺序主题能保证消息有序。

归档

当主题开启归档时，mq尽可能将数据写入归档数据。但是归档的优先级低于mq收发消息的优先级

了解完mq知识之后，由于已经有现成的mq高可用高可靠的集群服务了。因此我们并不负责整个mq集群的搭建，只需使用现成的mq服务即可。一般大厂都是术业有专攻，运维会将提供中间件的服务，像mysql集群、redis集群、nginx的lvs、再到mq集群服务。我们只负责用就可以了。。。。。。。

好，接下来，学会将mq集成到服务中吧，奥利给！！！！！

接入实践

之前mysql、redis等中间件的接入都不是我接入的，这次我直接上mq，我要把它先在测试环境接入了，大厂一般像这种中间件服务都是会提供两套环境的（测试和线上）。这样能保证数据隔离，保证开发测试与预发生产的正常。

基本就是测试环境接入申请，之后编写看客户端代码即可，之后测试一下，第一阶段对自己的要求就是能完成mq的生产和消费即可。

整个接入流程我不细讲，主要就是编写生产者和消费者代码以及mq集成到代码。

编程的大致流程就是：客户端和服务端建立连接、生产者向主题发送消息、消费者从主题消费消息