m0_57015193的博客

之前很泛的介绍了消息队列常见的问题，本篇聚焦到 Kafka，记录 Kafka 相关知识：Kafka 是一款分布式发布、订阅消息系统，也就是常说的消息队列。目前市面上绝大多数业务系统使用消息队列的主要原因如下：解耦：当下游系统需要当前系统数据时，无需通过 RPC 或 HTTP 接口的方式传递，直接发送 MQ，下游需要时直接从队列消费即可可扩展：解耦提到的需求实际不属于当前系统业务，通过 MQ 将它“外包”出去，不影响当前系统业务缓冲（削峰）：对于突发性的流量，通过消息队列将请求先保存在队列，之后从队

导致消息积压的主要原因在于消费者出了问题，不能正常消费。这种情况下，首先恢复消费者正常服务，消费者恢复后就可以慢慢消化掉这部分积压。当消息积压太多时，可能需要大量的时间才能消化完，此时我们考虑临时扩容：首先恢复所有消费者，并停掉所有机器创建全新 topic，partition 是原来的10倍临时开发 Consumer 程序，该程序主要消费积压 MQ，消费逻辑不做耗时处理，直接轮询将积压的 MQ 写入前面新建的十倍的 partition 中临时征用十倍机器来部署 consumer，每一台 con

大多数场景下，消息队列是不要求有序的。只有部分后续 MQ 处理依赖前驱 MQ 数据的场景才需要有序，这里保证有序主要从两个方面展开：消息队列层面消费者处理逻辑层面RabbitMQ对于 Rabbit MQ 这种主从架构，如果多个消费者连接相同的 queue，其中这个 queue 上包含需要依次处理的 data1，data2，data3。不同消费者拉取不同的数据，由于处理的速度不同，后续处理完的顺序无法判断，此时就无法保证有序性此时我们可以拆分多个 queue，相同类型的 MQ 集中在一个 que

所谓可靠性传输是指：不能丢数据。这里丢数据分两种：生产者生产时丢数据消息队列本身丢数据消费者消费时丢数据RabbitMQRabbitMQ 有三种丢数据的情况：生产者传入过程中消息丢失RabbitMQ 收到消息，暂时保存内存，还没来得及消费，进程挂掉了，内存中数据丢失消费者消费 MQ 时，正准备处理，系统宕机了，RabbitMQ 认为这条 MQ 已经被消费RabbitMQ 生产者在发送数据前可以开启 RabbitMQ 事务，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收

Kafka 在每个 MQ 写入队列时，会给这条数据分配一个序号 offset，consumer 在消费数据时，定期会把自己消费过的 offset 提交一下，告诉消息队列：我已经消费过序号为 X 的 MQ 了，下次从序号 X+1 开始消费。Kafka 内部通过这种方式保证 MQ 不被重复消费。然而这种情况不能保证消费者一定不重复消费，假设生产者在准备上报前进程被杀死，下次系统恢复后就可能重复消费一部分 MQ。然而重复消费 MQ 并不一定会导致问题，我们可以在消费端增加额外处理解决重复消费问题：如果消费

不同的消息队列实现方式不同，保证高可用的方式也不同，这里我主要列举出比较有代表的两类：RabbitMQRabbitMQ 基于主从实现高可用，包含以下三种模式：单机模式普通集群模式镜像集群模式单机模式：一般企业不会用到，平时自己本地测试可以搞一下。普通集群模式：多台机器上部署多个 RabbitMQ 实例，每台机器部署启动一个。每个实例包含独立的队列数据以及同步的元数据，通过元数据可以找到具体队列。消费者连接其中一个实例，消费 MQ 时可能产生两种结果：要消费的数据就在当前实例，直接消费

使用消息队列主要保证以下场景：解耦异步削峰解耦假设 B、C、D 三个系统都依赖 A 系统某个数据，A 系统就需要考虑通过某种方式将这部分数据传递过去。传递的过程中还需要考虑数据丢失怎么办，下游系统挂掉怎么办等等问题，而实际上这部分功能实际不属于 A 系统本身的业务在这种情况下，使用消息队列，A 系统只需将数据放到消息队列中，谁需要自己去申请消费即可，数据消费，新增依赖，取消依赖在下游系统自己处理，至于消息的安全性和稳定性交给消息队列即可异步假设 A 系统的某个功能还需要 B、C、D 三

目前市面上常见的消息队列有以下几种：ActiveMQRabbitMQRocketMQKafka特性ActiveMQRabbitMQRocketMQKafka吞吐量万级万级十万级十万级时效性毫秒(ms)微秒(μs)毫秒(ms)毫秒(ms)可用性高，主从架构高，主从架构非常高，分布式架构非常高，分布式架构可靠性有较低概率丢失基本不丢优化参数，不丢优化参数，不丢如何选择：ActiveMQ：早期 MQ，目前更新维护已