关于程序员:MQ-有什么作用你都用过哪些-MQ-中间件

前言

第一次听到“音讯队列”这个词时，不知你是不是和我反馈一样，感觉很高阶很厉害的样子，其实当咱们理解了音讯队列之后，发现它与一般的技术相似，当咱们相熟之后，也能很快地上手并应用。
本文将会深刻的解说 MQ（Message Queue，音讯队列）中间件，以及这些热门中间件的具体应用。

MQ 常见的应用场景有哪些？你都用过哪些 MQ 中间件？

典型答复

音讯队列的 应用场景 有很多，最常见的应用场景有以下几个。

1. 商品秒杀

比方，咱们在做秒杀流动时，会产生短时间内呈现爆发式的用户申请，如果不采取相干的措施，会导致服务器忙不过来，响应超时的问题，轻则会导致服务假死，重则会让服务器间接宕机，给用户带来的体验也十分不好。如果这个时候加上了音讯队列，服务器接管到用户的所有申请后，先把这些申请全副写入到音讯队列中再排队解决，这样就不会导致同时解决多个申请的状况；如果音讯队列长度超过能够承载的最大数量，那么咱们能够摈弃以后用户的申请，告诉前台用户“页面出错啦，请从新刷新”等提醒，这样就会有更好的交互体验。

如下图所示：

2. 零碎解耦

应用了音讯队列之后，咱们能够把零碎的业务性能模块化，实现零碎的解耦。例如，在没有应用音讯队列之前，以后台用户欠缺了个人信息之后，首先咱们须要更新用户的材料，再增加一条用户信息批改日志。但忽然有一天产品经理提了一个需要，在前台用户信息更新之后，须要给此用户的减少肯定的积分处分，而后没过几天产品经理又提了一个需要，在前台用户信息更新之后，岂但要减少积分处分，还要减少用户的经验值，但没过几天产品经理的需要又变了，他要求欠缺材料无需减少用户的积分了，这样反反复复、来来回回的折腾，我想研发的同学肯定受不了，但这是互联网公司的常态，那咱们有没有一劳永逸的方法呢？

没错，这个时候咱们想到了应用音讯队列来实现零碎的解耦，每个性能的实现独立开，只须要一个订阅或者勾销订阅的开关就能够了，当须要减少性能时，只须要关上订阅“用户信息欠缺”的队列就行，如果过两天不必了，再把订阅的开关关掉就行了，这样咱们就不必来来回回的改业务代码了，也就轻松的实现了零碎模块间的解耦。

3. 日志记录

咱们大部分的日志记录行为其实是和前台用户操作的主业务没有间接关系的，只是咱们的经营人和经营人员须要拿到这部分用户操作的日志信息，来进行用户行为剖析或行为监控。在咱们没有应用音讯队列之前，抽象的做法是当有用户申请时，先解决用户的申请再记录日志，这两个操作是放在一起的，而前台用户也须要期待日志增加实现之后能力拿到后盾的响应信息，这样其实节约了前台用户的局部工夫。此时咱们能够应用音讯队列，当响应完用户申请之后，只须要把这个操作信息放入音讯队列之后，就能够间接返回后果给前台用户了，毋庸期待日志解决和日志增加实现，从而缩短了前台用户的等待时间。

如下图所示：

4. 音讯通信

应用 MQ 能够作为音讯通信的实现伎俩，利用它能够实现点对点的通信或者多对多的聊天室性能。

点对点的音讯通信如下图所示：

多对多的音讯通信如下图所示：

罕用的 MQ 中间件
有 RabbitMQ、RocketMQ、Kafka 和 Redis 等，其中 Redis 属于轻量级的音讯队列，而 RabbitMQ、RocketMQ、Kafka 属于比拟成熟且比较稳定和高效的 MQ 中间件。

考点剖析

MQ 属于中高级或优良的程序员必备的技能，对于 MQ 中间件把握的数量则是你技术广度和编程教训的间接体现信息之一。值得庆幸的是，对于 MQ 中间件的实现原理和应用形式都比拟相似，因而如果开发者把握一项 MQ 中间件再去相熟其余 MQ 中间件时，会十分的容易。

MQ 相干的面试题还有这些：

• MQ 的特点是什么？引入 MQ 中间件会带来哪些问题？
• 常见的 MQ 中间件的优缺点剖析。

常识扩大

MQ 的特点及注意事项

MQ 具备以下 5 个特点。

1. 先进先出：音讯队列的程序个别在入列时就根本确定了，最先达到音讯队列的信息，个别状况下也会先转发给订阅的消费者，咱们把这种实现了先进先出的数据结构称之为队列。
2. 公布、订阅工作模式：生产者也就是音讯的创建者，负责创立和推送数据到音讯服务器；消费者也就是音讯的接管方，用于解决数据和确认音讯的生产；音讯队列也是 MQ 服务器中最重要的组成元素之一，它负责音讯的存储，这三者是 MQ 中的三个重要角色。而它们之间的消息传递与转发都是通过公布以及订阅的工作模式来进行的，即生产者把音讯推送到音讯队列，消费者订阅到相干的音讯后进行生产，在音讯非阻塞的状况下，此模式根本能够实现同步操作的成果。并且此种工作模式会把申请的压力转移给 MQ 服务器，以缩小了应用服务器自身的并发压力。
3. 长久化：长久化是把音讯从内存存储到磁盘的过程，并且在服务器重启或者产生宕机的状况下，重新启动服务器之后是保证数据不会失落的一种伎俩，也是目前支流 MQ 中间件都会提供的重要性能。
4. 分布式：MQ 的一个次要个性就是要应答大流量、大数据的高并发环境，一个单体的 MQ 服务器是很难应答这种高并发的压力的，所以 MQ 服务器都会反对分布式应用的部署，以摊派和升高高并发对 MQ 零碎的冲击。
5. 音讯确认：音讯生产确认是程序稳定性和安全性的一个重要考核指标，如果消费者在拿到音讯之后忽然宕机了，那么 MQ 服务器会误认为此音讯曾经被消费者生产了，从而造成音讯失落的问题，而目前市面上的支流 MQ 都实现了音讯确认的性能，保障了音讯不会失落，从而保障了零碎的稳定性。

引入 MQ 零碎会带来的问题

任何零碎的引入都是有两面性的，MQ 也不例外，在引入 MQ 之后，可能会带来以下两个问题。

1. 减少了零碎的运行危险：引入 MQ 零碎，则意味着新增了一套零碎，并且其余的业务零碎会对 MQ 零碎进行深度依赖，零碎部署的越多则意味着产生故障的可能性就越大，如果 MQ 零碎挂掉的话可能会导致整个业务零碎瘫痪。
2. 减少了零碎的复杂度：引入 MQ 零碎后，须要思考音讯失落、音讯反复生产、音讯的程序生产等问题，同时还须要引入新的客户端来解决 MQ 的业务，减少了编程的运维门槛，减少了零碎的复杂性。

应用 MQ 须要留神的问题，不要适度依赖 MQ，比方发送短信验证码或邮件等性能，这种低频但有可能比拟耗时的性能能够应用多线程异步解决即可，不必任何的性能都依赖 MQ 中间件来实现，但像秒杀抢购可能会导致超卖（也就是把货卖多了，库存变成正数了）等短时间内高并发的申请，此时倡议应用 MQ 中间件。

罕用的 MQ 中间件

罕用的 MQ 中间件有 Redis、RabbitMQ、RocketMQ、Kafka，下来咱们别离来看看各自的作用。

Redis 轻量级的消息中间件

Redis 是一个高效的内存性数据库中间件，但应用 Redis 也能够实现音讯队列的性能。

晚期的 Redis（Redis 5.0 之前）是不反对音讯确认的，那时候咱们能够通过 List 数据类型的 lpush 和 rpop 办法来实现队列音讯的存入和读取性能，或者应用 Redis 提供的公布订阅（pub/sub）性能来实现音讯队列，但这种模式不反对长久化，List 尽管反对长久化但不能设置简单的路由规定来匹配多个音讯，并且他们二者都不反对音讯生产确认。

于是在 Redis 5.0 之后提供了新的数据类型 Stream 解决了音讯确认的问题，但它同样不能提供简单的路由匹配规定，因而在业务不简单的场景下能够尝试性的应用 Redis 提供的音讯队列。

RabbitMQ

RabbitMQ 是一个实现了规范的高级音讯队列协定（AMQP，Advanced Message Queuing Protocol）的老牌开源消息中间件，最后起源于金融零碎，起初被广泛利用在了其余分布式系统中，它反对集群部署，和多种客户端调用。

RabbitMQ 的长处：

• 反对长久化，RabbitMQ 反对磁盘长久化性能，保障了音讯不会失落；
• 高并发，RabbitMQ 应用了 Erlang 开发语言，Erlang 是为电话交换机开发的语言，天生自带高并发光环和高可用个性；
• 反对分布式集群，正是因为 Erlang 语言实现的，因而 RabbitMQ 集群部署也非常简单，只须要启动每个节点并应用 –link 把节点退出到集群中即可，并且 RabbitMQ 反对主动选主和主动容灾；
• 反对多种语言，比方 Java、.NET、PHP、Python、JavaScript、Ruby、Go 等；
• 反对音讯确认，反对音讯生产确认（ack）保障了每条音讯能够被失常生产；
• 它反对很多插件，比方网页控制台音讯治理插件、音讯提早插件等，RabbitMQ 的插件很多并且应用都很不便。

RabbitMQ 运行流程，如下图所示：

RabbitMQ 集群分两种：一般集群、镜像集群

• 一般集群模式：

不同的节点之间只会互相同步元数据，队列不同步，只在本人的 broker 中，一般集群模式不能保障队列的高可用性，因为队列内容不会复制。如果节点生效将导致相干队列不可用

• 镜像队列模式：

音讯内容会在镜像节点间同步，保障 100% 数据不失落。在理论工作中也是用得最多的，并且实现十分的简略，个别互联网大厂都会构建这种镜像集群模式。

mirror 镜像队列，目标是为了保障 rabbitMQ 数据的高可靠性解决方案，次要就是实现数据的同步，一般来讲是 2- 3 个节点实现数据同步。对于 100% 数据可靠性解决方案，个别是采纳 3 个节点。

RocketMQ

RocketMQ 是由阿里捐献给 Apache 的一款低提早、高并发、高可用、高牢靠的分布式消息中间件。经验了淘宝双十一的洗礼。RocketMQ 既可为分布式应用零碎提供异步解耦和削峰填谷的能力，同时也具备互联网利用所需的海量音讯沉积、高吞吐、牢靠重试等个性。

RocketMQ 作为一款纯 java、分布式、队列模型的开源消息中间件，反对事务音讯、程序音讯、批量音讯、定时音讯、音讯回溯等。

RocketMQ 的劣势：

• 反对事务型音讯（音讯发送和 DB 操作放弃两方的最终一致性，RabbitMQ 和 Kafka 不反对）
• 反对联合 RocketMQ 的多个零碎之间数据最终一致性（多方事务，二方事务是前提）
• 反对 18 个级别的提早音讯（Kafka 不反对）
• 反对指定次数和工夫距离的失败音讯重发（Kafka 不反对，RabbitMQ 须要手动确认）
• 反对 Consumer 端 Tag 过滤，缩小不必要的网络传输（即过滤由 MQ 实现，而不是由消费者实现。RabbitMQ 和 Kafka 不反对）
• 反对反复生产（RabbitMQ 不反对，Kafka 反对）

Kafka

Kafka 是 LinkedIn 公司开发的基于 ZooKeeper 的多分区、多正本的分布式音讯零碎，它于 2010 年奉献给了 Apache 基金会，并且成为了 Apache 的顶级开源我的项目。其中 ZooKeeper 的作用是用来为 Kafka 提供集群元数据管理以及节点的选举和发现等性能。

与 RabbitMQ 比拟相似，一个典型的 Kafka 是由多个 Broker、多个生产者和消费者，以及 ZooKeeper 集群组成的，其中 Broker 能够了解为一个代理，Kafka 集群中的一台服务器称之为一个 Broker，其组成框架图如下所示：

Kafka VS RabbitMQ VS RocketMQ

性能

消息中间件的性能次要掂量吞吐量，Kafka 的吞吐量比 RabbitMQ 要高出 1~2 个数量级，RabbitMQ 的单机 QPS 在万级别，Kafka 的单机 QPS 可能达到百万级别。RocketMQ 单机写入 TPS 单实例约 7 万条 / 秒，单机部署 3 个 Broker，能够跑到最高 12 万条 / 秒，音讯大小 10 个字节，Kafka 如果开启幂等、事务等性能，性能也会有所升高。

数据可靠性

Kafka 与 RabbitMQ 都具备多正本机制，数据可靠性较高。RocketMQ 反对异步实时刷盘，同步刷盘，同步 Replication，异步 Replication。

服务可用性

Kafka 采纳集群部署，分区与多正本的设计，使得单节点宕机对服务无影响，且反对音讯容量的线性晋升。RabbitMQ 反对集群部署，集群节点数量有多种规格。RocketMQ 是分布式架构，可用性高。

性能

Kafka 与 RabbitMQ 都是比拟支流的两款消息中间件，具备消息传递的基本功能，但在一些非凡的性能方面存在差别，RocketMQ 在阿里团体外部有大量的利用在应用。

Kafka 和 RabbitMQ，RocketMQ 都反对分布式集群部署，并且都反对数据长久化和音讯生产确认等 MQ 的外围性能，对于 MQ 的选型要联合本人团队自身的状况，从性能、稳定性及二次开发的难易水平等维度来进行综合的考量并抉择。

总结

本文讲了 MQ 的常见应用场景，以及常见的 MQ 中间件（Redis、RabbitMQ、Kafka）及其优缺点剖析；同时还理解了 MQ 的五大特点：先进先出、公布和订阅的模式、长久化、分布式和音讯确认等；接着讲了 MQ 引入对系统可能带来的危险；最初讲了 MQ 在应用时须要留神的问题。心愿对整体理解 MQ 零碎有所帮忙。

😃感兴趣，请关注公众号：< 架构师成长之路 > 浏览更多精彩文章👍

本文由 mdnice 多平台公布