php微服务中MQ聊聊必问MQ

这篇文章，我重点突出行列步队选型，弱化每种行列步队内部的实现细节，精华提炼，可读性更强！

常用的行列步队紧张这 4 种，分别为 Kafka、RabbitMQ、RocketMQ 和 ActiveMQ，紧张先容前三，不BB，上思维导图！

行列步队根本什么是行列步队？

行列步队是在的传输过程中保存的容器，用于吸收并以文件的办法存储，一个行列步队可以被一个也可以被多个消费者消费，包含以下 3 元素：

Producer：生产者，卖力产生和发送到 Broker；Broker：处理中央，卖力存储、确认、重试等，一样平常个中会包含多个 Queue；Consumer：消费者，卖力从 Broker 中获取消息，并进行相应处理。

行列步队模式点对点模式：多个生产者可以向同一个行列步队发送，一个详细的只能由一个消费者消费。

发布/订阅模式：单个可以被多个订阅者并发的获取和处理。

行列步队运用处景运用解耦：行列步队减少了做事之间的耦合性，不同的做事可以通过行列步队进行通信，而不用关心彼此的实现细节。
异步处理：行列步队本身是异步的，它许可吸收者在发送很永劫光后再取回。
流量削锋：当高下游系统处理能力存在差距的时候，利用行列步队做一个通用的”载体”，不才游有能力处理的时候，再进行分发与处理。
日志处理：日志处理是指将行列步队用在日志处理中，比如 Kafka 的运用，办理大量日志传输的问题。
通讯：行列步队一样平常都内置了高效的通信机制，因此也可以用在纯的通讯，比如实现点对点行列步队，或者谈天室等。
广播：如果没有行列步队，每当一个新的业务方接入，我们都要接入一次新接口。
有了行列步队，我们只须要关心是否投递了行列步队，至于谁希望订阅，是下贱的事情，无疑极大地减少了开拓和联调的事情量。
常用行列步队

由于官方社区现在对 ActiveMQ 5.x 掩护越来越少，较少在大规模吞吐的场景中利用，以是我们紧张讲解 Kafka、RabbitMQ 和 RocketMQ。

Kafka

Apache Kafka 最初由 LinkedIn 公司基于独特的设计实现为一个分布式的提交日志系统，之后成为 Apache 项目的一部分，号称大数据的杀手锏，在数据采集、传输、存储的过程中发挥着举足轻重的浸染。

它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式流平台，它同时也是一款开源的基于发布订阅模式的引擎系统。

主要观点主题（Topic）：的种类称为主题，可以说一个主题代表了一类，相称于是对进行分类，主题就像是数据库中的表。
分区（partition）：主题可以被分为多少个分区，同一个主题中的分区可以不在一个机器上，有可能会支配在多个机器上，由此来实现 kafka 的伸缩性。
批次：为了提高效率， 会分批次写入 Kafka，批次就代指的是一组。
消费者群组（Consumer Group）：消费者群组指的便是由一个或多个消费者组成的群体。
Broker: 一个独立的 Kafka 做事器就被称为 broker，broker 吸收来自生产者的，为设置偏移量，并提交到磁盘保存。
Broker 集群：broker 集群由一个或多个 broker 组成。
重平衡（Rebalance）：消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。
Kafka 架构

一个范例的 Kafka 集群中包含 Producer、broker、Consumer Group、Zookeeper 集群。

Kafka 通过 Zookeeper 管理集群配置，选举 leader，以及在 Consumer Group 发生变革时进行 rebalance。
Producer 利用 push 模式将发布到 broker，Consumer 利用 pull 模式从 broker 订阅并消费。

Kafka 事情事理

经由序列化后，通过不同的分区策略，找到对应的分区。

相同主题和分区的，会被存放在同一个批次里，然后由一个独立的线程卖力把它们发到 Kafka Broker 上。

分区的策略包括顺序轮询、随机轮询和 key hash 这 3 种办法，那什么是分区呢？

分区是 Kafka 读写数据的最小粒度，比如主题 A 有 15 条，有 5 个分区，如果采取顺序轮询的办法，15 条会顺序分配给这 5 个分区，后续消费的时候，也是按照分区粒度消费。

由于分区可以支配在多个不同的机器上，以是可以通过分区实现 Kafka 的伸缩性，比如主题 A 的 5 个分区，分别支配在 5 台机器上，如果下线一台，分区就变为 4。

Kafka 消费是通过消费群组完成，同一个消费者群组，一个消费者可以消费多个分区，但是一个分区，只能被一个消费者消费。

如果消费者增加，会触发 Rebalance，也便是分区和消费者须要重新配对。

不同的消费群组互不干涉，比如下图的 2 个消费群组，可以分别消费这 4 个分区的，互不影响。

更多知识，详见 《事理初探之 Kafka》

RocketMQ

RocketMQ 是阿里开源的中间件，它是纯 Java 开拓，具有高性能、高可靠、高实时、适宜大规模分布式系统运用的特点。

RocketMQ 思路起源于 Kafka，但并不是 Kafka 的一个 Copy，它对的可靠传输及事务性做了优化，目前在阿里集团被广泛运用于交易、充值、流打算、推送、日志流式处理、binglog 分发等场景。

主要观点Name 做事器（NameServer）：充当注册中央，类似 Kafka 中的 Zookeeper。
Broker: 一个独立的 RocketMQ 做事器就被称为 broker，broker 吸收来自生产者的，为设置偏移量。
主题（Topic）：的第一级类型，一条必须有一个 Topic。
子主题（Tag）：的第二级类型，同一业务模块不同目的的就可以用相同 Topic 和不同的 Tag 来标识。
分组（Group）：一个组可以订阅多个 Topic，包括生产者组（Producer Group）和消费者组（Consumer Group）。
行列步队（Queue）：可以类比 Kafka 的分区 Partition。
RocketMQ 事情事理

RockerMQ 中的模型便是按照主题模型所实现的，包括 Producer Group、Topic、Consumer Group 三个角色。

为了提高并发能力，一个 Topic 包含多个 Queue，生产者组根据主题将放入对应的 Topic，下图是采取轮询的办法找到里面的 Queue。

RockerMQ 中的消费群组和 Queue，可以类比 Kafka 中的消费群组和 Partition：不同的消费者组互不滋扰，一个 Queue 只能被一个消费者消费，一个消费者可以消费多个 Queue。

消费 Queue 的过程中，通过偏移量记录消费的位置。

RocketMQ 架构

RocketMQ 技能架构中有四大角色 NameServer、Broker、Producer 和 Consumer，下面紧张先容 Broker。

Broker 用于存放 Queue，一个 Broker 可以配置多个 Topic，一个 Topic 中存在多个 Queue。

如果某个 Topic 量很大，该当给它多配置几个 Queue，并且只管即便多分布在不同 broker 上，以减轻某个 broker 的压力。
Topic 量都比较均匀的情形下，如果某个 broker 上的行列步队越多，则该 broker 压力越大。

大略提一下，Broker 通过集群支配，并且供应了 master/slave 的构造，salve 定时从 master 同步数据（同步刷盘或者异步刷盘），如果 master 宕机，则 slave 供应消费做事，但是不能写入。

看到这里，大家该当可以创造，RocketMQ 的设计和 Kafka 真的很像！

更多知识，详见 《事理初探之 RocketMQ》

RabbitMQ

RabbitMQ 2007 年发布，是利用 Erlang 措辞开拓的开源行列步队系统，基于 AMQP 协议来实现。

AMQP 的紧张特色是面向、行列步队、路由、可靠性、安全。
AMQP 协议更多用在企业系统内，对数据同等性、稳定性和可靠性哀求很高的场景，对性能和吞吐量的哀求还在其次。

主要观点信道（Channel）：读写等操作在信道中进行，客户端可以建立多个信道，每个信道代表一个会话任务。
交流器（Exchange）：吸收，按照路由规则将路由到一个或者多个行列步队；如果路由不到，或者返回给生产者，或者直接丢弃。
路由键（RoutingKey）：生产者将发送给交流器的时候，会发送一个 RoutingKey，用来指定路由规则，这样交流器就知道把发送到哪个行列步队。
绑定（Binding）：交流器和行列步队之间的虚拟连接，绑定中可以包含一个或者多个 RoutingKey。
RabbitMQ 事情事理

AMQP 协议模型由三部分组成：生产者、消费者和做事端，实行流程如下：

生产者是连接到 Server，建立一个连接，开启一个信道。
生产者声明交流器和行列步队，设置干系属性，并通过路由键将交流器和行列步队进行绑定。
消费者也须要进行建立连接，开启信道等操作，便于吸收。
生产者发送，发送到做事端中的虚拟主机。
虚拟主机中的交流器根据路由键选择路由规则，发送到不同的行列步队中。
订阅了行列步队的消费者就可以获取到，进行消费。

常用交流器

RabbitMQ 常用的交流器类型有 direct、topic、fanout、headers 四种，每种方法的详细先容看这篇《入门RabbitMQ，这一篇绝对够！
》。

详细的利用方法，可以参考官网：

官网入口：https://www.rabbitmq.com/getstarted.html

更多知识，详见 《入门RabbitMQ，这一篇绝对够！
》

行列步队比拟&选型

行列步队比拟Kafka

优点：

高吞吐、低延迟：Kafka 最大的特点便是收发非常快，Kafka 每秒可以处理几十万条，它的最低延迟只有几毫秒；高伸缩性：每个主题（topic）包含多个分区（partition），主题中的分区可以分布在不同的主机（broker）中；高稳定性：Kafka 是分布式的，一个数据多个副本，某个节点宕机，Kafka 集群能够正常事情；持久性、可靠性、可回溯：Kafka 能够许可数据的持久化存储，被持久化到磁盘，并支持数据备份防止数据丢失，支持回溯；有序：通过掌握能够担保所有被消费且仅被消费一次；有精良的第三方 Kafka Web 管理界面 Kafka-Manager，在日志领域比较成熟，被多家公司和多个开源项目利用。

缺陷：

Kafka 单机超过 64 个行列步队/分区，Load 会发生明显的飙高征象，行列步队越多，load 越高，发送相应韶光变长；不支持路由，不支持延迟发送，不支持重试；社区更新较慢。
RocketMQ

优点：

高吞吐：借鉴 Kafka 的设计，单一行列步队百万的堆积能力；高伸缩性：灵巧的分布式横向扩展支配架构，整体架构实在和 kafka 很像；高容错性：通过ACK机制，担保一定能正常消费；持久化、可回溯：可以持久化到磁盘中，支持回溯；有序：在一个行列步队中可靠的前辈先出（FIFO）和严格的顺序通报；支持发布/订阅和点对点模型，支持拉、推两种模式；供应 docker 镜像用于隔离测试和云集群支配，供应配置、指标和监控等功能丰富的 Dashboard。

缺陷：

不支持路由，支持的客户端措辞不多，目前是 java 及 c++，个中 c++ 不成熟；部分支持有序：须要将同一类的 hash 到同一个行列步队 Queue 中，才能支持的顺序，如果同一类散落到不同的 Queue中，就不能支持的顺序。
社区生动度一样平常。
RabbitMQ

优点：

支持险些所有最受欢迎的编程措辞：Java，C，C ++，C＃，Ruby，Perl，Python，PHP等等；支持路由：RabbitMQ 可以通过不同的交流器支持不同种类的路由；时序：通过延时行列步队，可以指定的延时时间，过期韶光TTL等；支持容错处理：通过交付重试和去世信交流器（DLX）来处理处理故障；供应了一个易用的用户界面，使得用户可以监控和管理 Broker；社区生动度高。

缺陷：

Erlang 开拓，很难去看懂源码，不利于做二次开拓和掩护，基本职能依赖于开源社区的快速掩护和修复 bug；RabbitMQ 吞吐量会低一些，这是由于他做的实现机制比较重；不支持有序、持久化不好、不支持回溯、伸缩性一样平常。
行列步队选型Kafka：追求高吞吐量，一开始的目的便是用于日志网络和传输，适宜产生大量数据的互联网做事的数据网络业务，大型公司建议可以选用，如果有日志采集功能，肯定是首选 kafka。
RocketMQ：天生为金融互联网领域而生，对付可靠性哀求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情形。
RoketMQ 在稳定性上可能更值得相信，这些业务场景在阿里双 11 已经经历了多次磨练，如果你的业务有上述并发场景，建议可以选择 RocketMQ。
RabbitMQ：结合 erlang 措辞本身的并发上风，性能较好，社区生动度也比较高，但是不利于做二次开拓和掩护，不过 RabbitMQ 的社区十分生动，可以办理开拓过程中碰着的 bug。
如果你的数据量没有那么大，小公司优先选择功能比较完备的 RabbitMQ。
ActiveMQ：官方社区现在对 ActiveMQ 5.x 掩护越来越少，较少在大规模吞吐的场景中利用。