消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。
消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，以阿里为例，其研发的消息队列（RocketMQ）在历次天猫 “双十一” 活动中支撑了万亿级的数据洪峰，为大规模交易提供了有力保障。
作为提升应用性能的重要手段，分布式消息队列技术在互联网领域得到了越来越广泛的关注 。在之前的博文中，我们介绍了四种常用的消息中间件：ActiveMQ、RabbitMQ、RocketMQ 及 Kafka的基础使用以及配置，本文将主要介绍这4中消息中间件的对比以及业务选型。
消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等等功能，其作为分布式系统架构中的一个重要组件，有着举足轻重的地位。
目前开源的消息中间件可谓是琳琅满目，能让大家耳熟能详的就有很多，比如 ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ 等。不管选择其中的哪一款，都会有用的不趁手的地方，毕竟不是为你量身定制的。有些大厂在长期的使用过程中积累了一定的经验，其消息队列的使用场景也相对稳定固化，或者目前市面上的消息中间件无法满足自身需求，并且也具备足够的精力和人力而选择自研来为自己量身打造一款消息中间件。但是绝大多数公司还是不会选择重复造轮子，那么选择一款合适自己的消息中间件显得尤为重要。就算是前者，那么在自研出稳定且可靠的相关产品之前还是会经历这样一个选型过程。
如上图所示，一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。
Kafka 是一个分布式的基于发布/订阅模式的消息队列，依靠其强悍的吞吐量，Kafka 主要应用于大数据实时处理领域。在数据采集、传输、存储的过程中发挥着举足轻重的作用。
在Kafka在0.8以前的版本中，是没有Replication的，一旦某一个Broker宕机，则其上所有的Partition数据都不可被消费，这与Kafka数据持久性及Delivery Guarantee的设计目标相悖。同时Producer都不能再将数据存于这些Partition中。
如果Producer使用同步模式则Producer会在尝试重新发送message.send.max.retries（默认值为3）次后抛出Exception，用户可以选择停止发送后续数据也可选择继续选择发送。而前者会造成数据的阻塞，后者会造成本应发往该Broker的数据的丢失。
version: '3'
services:
zookeeper:
image: 'bitnami/zookeeper:3.8.0'
container_name: zookeeper
ports:
- "2181:2181"
environment:
TZ: Asia/Shanghai
ALLOW_ANONYMOUS_LOGIN: "yes"
ZOO_SERVER_ID: 1
ZOO_PORT_NUMBER: 2181
# network_mode: "host"
kafka:
image: 'bitnami/kafka:3.2.0'
container_name: kafka
ports:
- "9092:9092"
environment:
TZ: Asia/Shanghai
# 更多变量 查看文档 https://github.com/bitnami/bitnami-docker-kafka/blob/master/README.md
KAFKA_BROKER_ID: 1
# 监听端口
KAFKA_CFG_LISTENERS: PLAINTEXT://:9092
# 实际访问ip 本地用 127 内网用 192 外网用 外网ip
KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://192.168.31.165:9092
KAFKA_CFG_ZOOKEEPER_CONNECT: 127.0.0.1:2181
ALLOW_PLAINTEXT_LISTENER: "yes"
volumes:
- ./data:/bitnami/kafka/data
depends_on:
- zookeeper
#network_mode: "host"
kafka-manager:
image: sheepkiller/kafka-manager:latest
container_name: kafka-manager
ports:
- "19092:19092"
environment:
ZK_HOSTS: 127.0.0.1:2181
APPLICATION_SECRET: letmein
KAFKA_MANAGER_USERNAME: ruoyi
KAFKA_MANAGER_PASSWORD: ruoyi123
KM_ARGS: -Dhttp.port=19092
depends_on:
- kafka
#network_mode: "host"Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
主要应用场景是：解决应用耦合、异步消息、流量削锋。
Kafka主要设计目标如下：
/brokers/topics/[topic] :
RabbitMQ 是 AMQP 协议的 Erlang 的实现（RabbitMQ 还支持 STOMP、MQTT 等协议）。
AMQP 的模型架构和 RabbitMQ 的模型架构是一样的：
RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都遵循 AMQP 协议中相应的概念。本书讲解的 RabbitMQ 版本对应的是 AMQP 0-9-1 版本协议。如无特指，则以该协议为基准介绍。
生产者将消息发送出去之后，消息到底有没有正确到达服务器？如果不进行特殊配置，默认情况下发送消息的操作是不会返回任何信息给生产者的。也就是说默认情况下，生产者不知道消息是否正确到达服务器。
RabbitMQ 针对这个问题，提供了两种解决方式：
RabbitMQ 客户端中与事物机制相关的方法有三个：
channel.txSelect：将当前的信道设置为 事物模式channel.txCommit：提交事物channel.txRollback：回滚事物