MQ：RabbitMQ与Kafka的一些问题总结

一：MQ

1.1 为什么使用MQ？MQ的优点

简要回答

异步处理 ：相比于传统的串行、并行方式，提高了系统吞吐量。

应用解耦 ： 系统间通过消息通信，不用关心其他系统的处理。

流量削锋 ： 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。

日志处理 ： 解决大量日志传输。

消息通讯 ： 消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。

深入回答

主要是：解耦、异步、削峰。

解耦：

1. A 系统发送数据到 BCD 三个系统，通过接口调用发送。
2. 如果 E 系统也要 这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…
3. A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。
4. 如果使用 MQ，A 系统产生一条数据， 发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。
5. 这样下来，A 系统压根儿不需要去考虑要给谁发送数 据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 可以给它异步化解耦。

异步：避免同时写入需要等待前面的内容消费完了再开始消费后面的数据

1. A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、 200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户 感觉搞个什么东西，慢死了慢死了。
2. 用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从 接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。

削峰：减少高峰时期对服务器压力。

1.2 消息队列有什么优缺点

好处便是：解耦、异步、削峰

缺点：

1. 系统可用性降低

   现在系统加入了一个消息队列进去，那消息队列挂了，系统便不可用。因此，系统可用性会降低；

2. 系统复杂度提高

   加入了消息队列，便要考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂 性增大。

1.3 MQ的选择

一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用 的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，不推荐用这个了；

后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师 去深入研究和掌控它，对公司而言，几乎处于不可控的状态

中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是 不错的选择；

大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选 择。

如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高。

1.4 MQ 常见问题及解决方法？

常见问题1：消息的顺序问题

消息有序指的是可以按照消息的发送顺序来消费

解决方案： （1）保证生产者 - MQServer - 消费者是一对一对一的关系

常见问题2：消息的重复问题

造成消息重复的根本原因是：网络不可达。

所以解决这个问题的办法就是绕过这个问题。那么问题就变成了：如果消费端收到两条一样的消息，应该怎样处理？
消费端处理消息的业务逻辑保持幂等性。
只要保持幂等性，不管来多少条重复消息，最后处理的结果都一样。
保证每条消息都有唯一编号且

保证消息处理成功和去重表的日志同时出现。

利用一张日志表来记录已经处理成功的消息的 ID，如果新到的消息ID 已经在日志表中，那么就不再处理这条消息。

二：RabbitMQ

2.1 什么是RabbitMQ

RabbitMQ是一款开源的，Erlang编写的，基于AMQP协议的消息中间件

2.2 Rabbitmq 的使用场景

（1）服务间异步通信
（2）顺序消费
（3）定时任务
（4）请求削峰

2.3 RabbitMQ的工作模式

2.3.1 WorkQueue工作队列模式

1.生产者产生消息，将消息放入队列

2.消息的消费者(consumer) 监听消息队列，如果队列中有消息，就消费掉；消息被拿走后，自动从队列中删除

隐患：消息可能没有被消费者正确处理，已经从队列中消失了，造成消息的丢失

这里可以设置成手动的ack,但如果设置成手动ack，处理完后要及时发送ack消息给队列，否则会造成内存溢出

2.3.2 Pub/Sub订阅模式

1、每个消费者监听自己的队列；
2、生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息

Exchange (交换机)只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失!

2.3.3 Route路由模式

1.队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey (路由key)

2.消息的发送方在向Exchange发送消息时，也必须指定消息的RoutingKey

3.Exchange不再把消息交给每一个绑定的队列， 而是根据消息的Routing Key进行判断，只有队列的Routingkey与消息的Routing key完全一致, 才会接收到消息

图例说明：

P:生产者，向Exchange发送消息，发送消息时，会指定-个routing key
X: Exchange (交换机)，接收生产者的消息，然后把消息递交给与routing key完全匹配的队列
C1: 消费者，其所在队列指定了需要routing key为error的消息
C2:消费者,其所在队列指定了需要routing key为info、 error. warning的消

Routing模式要求队列在绑定交换机时要指定routing key,消息会转发到符命routing key的队列。

2.3.4 Topic通配符模式

Topic类型与Direct相比，都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routing key 的时候使用通配符！

Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert

通配符规则：

#：匹配一个或多个词
*：匹配不多不少恰好1个词

举例：

item.#：能够匹配item.insert.abc 或者 item.insert
item.*：只能匹配item.insert

图解：

• 红色Queue：绑定的是usa.# ，因此凡是以 usa.开头的routing key 都会被匹配到
• 黄色Queue：绑定的是#.news ，因此凡是以 .news结尾的 routing key 都会被匹配

2.4 如何保证RabbitMQ消息的顺序性

拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已；

或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

2.5 消息如何分发

若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。

通过路由可实现多消费的功能

2.6 消息怎么路由

消息提供方->路由->一至多个队列消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。

通过队列路由键，可以把队列绑定到交换器上。

消息到达交换器后，RabbitMQ 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；常用的交换器主要分为一下三种：

1. fanout：如果交换器收到消息，将会广播到所有绑定的队列上
2. direct：如果路由键完全匹配，消息就被投递到相应的队列
3. topic：可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时，可以使用通配符

2.7 消息基于什么传输

由于 TCP 连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。

RabbitMQ 使用信道的方式来传输数据。

信道是建立在真实的 TCP 连接内的虚拟连接，且每条 TCP 连接上的信道数量没有限制

2.8 如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？

出现重复消费：

正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；
但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。

一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；

比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；

1. 假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？
2. 但是你要是消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。

2.9 如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？

发送方确认模式将信道设置成 confirm 模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的 ID。

1. 一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一 ID）
2. 如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条nack（notacknowledged，未确认）消息。

发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。

1. 当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
2. 接收方确认机制消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。
3. 只有消费者确认了消息，RabbitMQ 才能安全地把消息从队列中删除。

这里并没有用到超时机制，RabbitMQ 仅通过 Consumer 的连接中断来确认是否需要重新发送消息。

也就是说，只要连接不中断，RabbitMQ 给了Consumer 足够长的时间来处理消息。

2.10 如何保证RabbitMQ消息的可靠传输

消息不可靠的情况可能是消息丢失，劫持等原因；丢失又分为：

1. 生产者丢失消息、
2. 消息列表丢失消息、
3. 消费者丢失消息；
4. 生产者丢失消息：

从生产者弄丢数据这个角度来看，RabbitMQ提供 transaction和confirm模式来确保生产者不丢消息；

2.10.1 transaction机制

transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚

（channel.txRollback()）,如果发送成功则提交事务

（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降；

2.10.2 confirm模式

confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；

rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；

如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作

2.10.3 消息队列丢数据

息队列丢数据：需要开启消息持久化。
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。

这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

2.10.4 如何持久化

1. 将queue的持久化标识durable设置为true,则代表是一个持久的队列
2. 发送消息的时候将deliveryMode=2

这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据

2.10.5 消费者丢失消息：

消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！

消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；如果这时处理消息失败，就会丢失该消息；

解决方案：处理消息成功后，手动回复确认消息。

2.11 为什么不应该对所有的 message 都使用持久化机制

首先：必然导致性能的下降，

因为写磁盘比写 RAM 慢的多，message 的吞吐量可能有 10 倍的差距。

其次：message 的持久化机制用在 RabbitMQ 的内置 cluster 方案时会出现“坑爹”问题

若 message 设置了 persistent 属性，但 queue 未设置 durable 属性，那么当该 queue 的 owner node 出现异常后，在未重建该 queue 前，发往该 queue 的 message 将被 blackholed ；
若 message 设置了 persistent 属性，同时 queue 也设置了durable 属性，那么当 queue 的 owner node 异常且无法重启的情况下，则该 queue 无法在其他 node 上重建，只能等待其 owner node 重启后，才能恢复该 queue 的使用，而在这段时间内发送给该 queue 的 message 将被 blackholed 。

是否要对 message 进行持久化，需要综合考虑性能需要，以及可能遇到的问题。

若想达到 100,000 条/秒以上的消息吞吐量（单 RabbitMQ 服务器），

1. 使用其他的方式来确保 message 的可靠 delivery ，
2. 使用非常快速的存储系统以支持全持久化（例如使用 SSD）。
3. 另外一种处理原则是：仅对关键消息作持久化处理（根据业务重要程度），且应该保证关键消息的量不会导致性能瓶颈。

三：Kafka

3.1 什么是Apache Kafka

Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。

是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，

3.2 什么是传统的消息传递方法

传统的消息传递方法包括两种

1. 排队：在队列中，一组用户可以从服务器中读取消息，每条消息都发送给其中一个人
2. 发布-订阅：在这个模型中，消息被广播给所有的用户。

3.3 Kafka相对传统技术有什么优势

快速：单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。

可伸缩：在一组机器上对数据进行分区和简化，以支持更大的数据

持久：消息是持久性的，并在集群中进行复制，以防止数据丢失

设计：它提供了容错保证和持久性

3.4 broker的意义是什么

Kafka集群中包含的一个或多个服务器，服务器节点称为Broke

3.5 Kafka服务器能接收到的最大信息是多少

Kafka服务器可以接收到的消息的最大大小是一百万字节

3.6 Kafka的Zookeeper是什什么？可以在没有Zookeeper的情况下使用Kafka吗?

Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用

不可以在没有Zookeeper的情况下使用Kafka

Zookeeper主要用于在集群中不同节点之间进行通信

1. 在Kafka中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取
2. 除此之外，它还执行其他活动，如: leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。

3.7 Kafka的用户如何消费信息

在Kafka中传递消息是通过使用sendfile API完成的。

它支持将字节从套接口转移到磁盘，通过内核空间保存副本，并在内核用户之间调用内核。

3.8 如何提高远程用户的吞吐量

如果用户位于与broker不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。

3.9 在数据制作过程中，如何能从Kafka得到准确的信息

在数据中，为了精确地获得Kafka的消息，你必须遵循两件事: 在数据消耗期间避免重复，在数据生产过程中避免重复。

有两种方法，可以在数据生成时准确地获得一个语义

1. 每个分区使用一个单独的写入器，每当你发现一个网络错误，检查该分区中的最后一条消息，以查看您的最后一次写入是否成功
2. 在消息中包含一个主键(UUID或其他)，并在用户中进行反复制

3.10broker什么时候离开ISR

如果一个副本从leader中脱离出来，将会
从ISR中删除

3.11 Kafka为什么需要复制

确保了任何已发布的消息不会丢失，并且可以在机器错误、程序错误或更常见些的软件升级中使用。

3.12 如果副本在ISR中停留了很长时间表明什么?

如果一个副本在ISR中保留了很长一段时间，那么它就表明，跟踪器无法像在leader收集数据那样快速地获取数据。

3.14 如果首选的副本不在ISR中会发生什么?

如果首选的副本不在ISR中，控制器将无法将leadership转移到首选的副本。

3.15 有可能在生产后发生消息偏移吗

在大多数队列系统中，作为生产者的类无法做到这一点，它的作用是触发并忘记消息。broker将完成剩下的工作，比如使用id进行适当的元数据处理、偏移量等。

作为消息的用户，你可以从Kafka broker中获得补偿。如果你注视SimpleConsumer类，你会注意到它会获取包括偏移量作为列表的MultiFetchResponse对象。

此外，当对Kafka消息进行迭代时，你会拥有包括偏移量和消息发送的MessageAndOffset对象。

3.16 Kafka部分名词解释

Broker：消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。

Topic：一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。

Partition：topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。

Segment：partition物理上由多个segment组成，

offset：每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息

3.17 分析过程

分析过程分为以下4个步骤

1. topic中partition存储分布
2. partition中文件存储方式
3. partition中segment文件存储结构
4. 在partition中如何通过offset查找messag

3.17.1 topic中partition存储分布

在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，

partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。

实验环境中Kafka集群只有一个broker，xxx/message-folder为数据文件存储根目录，

在Kafka broker中server.properties文件配置(参数log.dirs=xxx/message-folder)，

例如创建2个topic名称分别为report_push、launch_info, partitions数量都为partitions=4
存储路径和目录规则为：xxx/message-folder

	|--report_push-0
    |--report_push-1
    |--report_push-2
    |--report_push-3
    |--launch_info-0
    |--launch_info-1
    |--launch_info-2
    |--launch_info-3

3.17.2 partition中文件存储方式

partition中文件存储方式

1. 每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。
2. 每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。

这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。

3.17.3 partiton中segment文件存储结构

Kafka文件系统partition存储方式
深入分析partion中segment file组成和物理结构

1. segment file组成：由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件
2. segment文件命名规则：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。

3.17.4 在partition中如何通过offset查找message

例如读取offset=368776的message，需要通过下面2个步骤查找。

1. 第一步查找segment file
   其中00000000000000000000.index表示最开始的文件，起始偏移量(offset)为0.第二个文件00000000000000368769.index的消息量起始偏移量为368770= 368769 + 1.
   同样，第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1，其他后续文件依次类推，以起始偏移量命名并排序这些文件，只要根据offset 二分查找文件列表，就可以快速定位到具体文件。
   当offset=368776时定位到00000000000000368769.index|log
2. 第二步通过segment file查找message
   通过第一步定位到segment file，当offset=368776时，依次定位到 00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址，然后再通过 00000000000000368769.log顺序查找直到offset=368776为止。

3.18 Kafka高效文件存储设计特点

Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。

通过索引信息可以快速定位message和确定response的最大大小。

通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。

通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。

3.19 topic的分区partition分段segment以及索引

Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。

每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定
的)，每个partition存储一部分Message。

3.19.1 Partition的数据文件

Partition中的每条Message由offset来表示它在这个partition中的偏移量

offset不是该Message在partition数据文件中的实际存储位置，而是逻辑上一个值，它唯一确定了partition中的一条Message

可以认为offset是partition中Message的id，partition中的每条Message包含了以下三个属性：

1. offset
   offset为long型
2. MessageSize
   MessageSize为int32，表示data有多大
3. data
   data为message的具体内容

Partition的数据文件则包含了若干条上述格式的Message，按offset由小到大排列在一起。它的实现类为FileMessageSet，

3.20 Kafka是如何解决查找效率的的问题

有两种方法：1) 分段 2) 索引。

3.20.1 数据文件的分段

比如有100条Message，它们的offset是从0到99。

1. 假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的offset命名。
2. 这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。

3.20.2 为数据文件建索引

数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，为进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。

索引文件中包含若干个索引条目，每个条目表示数据文件中一条Message的索引。索引包含两个部分（均为4个字节的数字），分别为相对offset和position。

1. 相对offset：因为数据文件分段以后，每个数据文件的起始offset不为0，相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。

   举例，分段后的一个数据文件的offset是从20开始，那么offset为25的Message在index文件中的相对offset就是25-20 = 5。
   存储相对offset可以减小索引文件占用的空间。

2. position，表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。

3.21 Kafka 新建的分区会在哪个目录下创建

在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，

这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。

3.22 Kafka 与传统消息系统之间有三个关键区别

(1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
(3).Kafka 支持实时的流式处理

3.23 Kafka 消息是采用 Pull 模式，还是 Push 模式？

Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从 broker 拉取消息

Kafka 选取了传统的 pull 模式

Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据。

Pull 有个缺点是，如果 broker 没有可供消费的消息，将导致consumer 不断在循环中轮询，直到新消息到 达