MQ（消息队列）系列学习---MQ基础认识

前言

这是一个MQ的系列文章，主要由MQ的基础认识到深入了解，和针对不同业务对MQ的技术选型问题。通过文章了解不同MQ的各种区别，和使用MQ会存在的一些问题。

入门篇：MQ（消息队列）系列学习—MQ基础认识
基础篇：MQ（消息队列）系列学习—MQ组件优劣势比较
晋级篇：MQ（消息队列）系列学习—MQ如何保证消息队列高可用

MQ（消息队列）基础认识

1.MQ基础认识

1.1 概念

消息队列中间件是分布式系统中重要的组件，是一种异步的服务间通信方式，适用于无服务器和微服务架构。主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。

1.1.1 消息队列中间件

1.队列
数据结构中队列，先进先出。类似于地铁站排队进站
2.消息
"消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。
3.消息队列
消息队列消息在被处理和删除之前一直存储在队列上。每条消息仅可被一位用户处理一次。

1.2 通信模式

1、点对点模式：REQ/REP

最基本的模式，生产者发送一条消息，消费者去除并消费信息，给出响应后会从队列中删除该消息，所以不能重复发送，只能被一个消费者消费。（一对一私人）

2、发布/订阅模式：Pub/Sub

非常常见也是非常有用的一种模式，将发布者与订阅者进行解耦。发布者只负责生产数据，而不需要关心谁是订阅者，有多少订阅者。（类比于关注微信公众号）

3、推/拉模式：Push/Pull

也是一种比较重要的模式，无论是Push端还是Pull端都可以做服务器，绑定到特定的地址等待对方访问。

如果我们在Push端绑定地址，那么这是一个PushServer，对应的PullClient可以链接到这个PushServer往外拉数据；反之，如果建立一个PullServer，对应的PushClient就可以链接到PullServer并往里面压数据。（寄发快递）

4、路由/代理模式：Router/Dealer

是一种典型的中间人模式，比较适用于多对多的网络当中，双方在互相不认识的情况下达成共识并交易。类比于：顾客—>超时<–供应商。（租房中间商）

1.3 常用场景–主要能解决什么问题

1.3.1 异步消息/异步处理

一般的系统中，接口都为同步调用。系统之间进行接口中的相互调用，A方法调用B方法（50ms），B方法中又调用了C方法，有可能C方法处理需要（1000ms），那么整个流程下来就需要几个方法的处理时间总和。如果进行异步处理，先处理前两个方法A、B（100ms），在业务完成后再去调用C方法。那么对用户的体验就优化了不少，由最先的1100ms的等待至100ms的等待。

1.3.2 应用解耦

系统解耦：将不同业务代码进行分模块书写,
逻辑解耦:通过中间件（mq）来使业务逻辑进行分离，达到业务逻辑单独进行处理。

消息队列可以消除组件件的依赖关系，解耦后不会因为某系统的异常而造成整个业务流程的失败。
比如一般的订票系统，用户下单购买票据，里面会调用：订单系统–》库存系统–》积分系统。但如果积分系统出现问题就导致订票失败。
如果使用mq进行逻辑解耦
（1）订票和库存系统处理完成后直接进行持久化处理，将订票信息写入消息队列中，就不需要等待积分系统的处理。
（2）积分系统就监听消息队列的变化，写入了新的订票信息后就进行积分处理。

1.3.3 流量消峰

在MQ消息队列中可以设置缓存池，在碰见高秒杀并发的时候，流量过大导致应用挂掉。那么我们可以直接使用MQ来进行控制，到缓存池中到达了一定数量后，直接将请求抛弃掉然后返回错误页面。然后再将队列中的请求信息做后续处理

1.3.4 消息通讯

基于MQ的常用的通信模式来设计一些业务需求。比如使用

• publish-subscribe(发布订阅)，来进行多个服务处理同一条消息。
• Point To Point（点对点），来进行一对一通信。

1.4 MQ优劣势比较

优点

• 解耦
• 流量消峰
• 消息通讯
• 异步处理
• 高可用、高性能

缺点

• 对于一个系统引入了了新的中间件，都会造成系统的复杂度提高
• 这个中间件挂掉后会导致系统中有依赖的内容崩溃
• 会存在一些由该中间件引起的的特定问题：数据一致性、消息重复消费、消息丢失、如何保证消费顺序

解决这些问题需要花一定的篇幅来说明，我会单独开一篇文章。如果更新后我直接会在下面附上链接