MQ：RabbitMQ与Kafka的一些问题总结
一：MQ
1.1 为什么使用MQ？MQ的优点
简要回答
异步处理 ：相比于传统的串行、并行方式，提高了系统吞吐量。
应用解耦 ： 系统间通过消息通信，不用关心其他系统的处理。
流量削锋 ： 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。
日志处理 ： 解决大量日志传输。
消息通讯 ： 消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。
深入回答
主要是：解耦、异步、削峰。
解耦：
- A 系统发送数据到 BCD 三个系统，通过接口调用发送。
- 如果 E 系统也要 这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃…
- A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，
很多系统都需要 A 系统将这个数据发送过来。 - 如果使用 MQ，A 系统产生一条数据， 发送到 MQ 里面去，
哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。 - 这样下来，A 系统压根儿不需要去考虑要给谁发送数 据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 可以给它异步化解耦。
异步：避免同时写入需要等待前面的内容消费完了再开始消费后面的数据
- A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、 200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户 感觉搞个什么东西，慢死了慢死了。
- 用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从 接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。
削峰：减少高峰时期对服务器压力。
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 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；常用的交换器主要分为一下三种：
fanout：如果交换器收到消息，将会广播到所有绑定的队列上direct：如果路由键完全匹配，消息就被投递到相应的队列topic：可以使来自不同源头的消息能够到达同一个队列。使用 topic 交换器时，可以使用通配符
2.7 消息基于什么传输
由于 TCP 连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。
RabbitMQ 使用信道的方式来传输数据。
信道是建立在真实的 TCP 连接内的虚拟连接，且每条 TCP 连接上的信道数量没有限制
2.8 如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？
出现重复消费：
正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；
但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。
一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；
比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；
- 假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？
- 但是你要是
消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。
2.9 如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？
发送方确认模式将信道设置成 confirm 模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的 ID。
- 一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一 ID）
- 如果 RabbitMQ 发生内部错误从而导致消息丢失，会发送一条nack（notacknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。
- 当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
- 接收方确认机制消费者接收每一条消息后都必须进行确认（
消息接收和消息确认是两个不同操作）。 - 只有消费者确认了消息，RabbitMQ 才能安全地把消息从队列中删除。
这里并没有用到超时机制，RabbitMQ 仅通过 Consumer 的连接中断来确认是否需要重新发送消息。
也就是说，只要连接不中断，RabbitMQ 给了Consumer 足够长的时间来处理消息。
2.10 如何保证RabbitMQ消息的可靠传输
消息不可靠的情况可能是消息丢失，劫持等原因；丢失又分为：
- 生产者丢失消息、
- 消息列表丢失消息、
- 消费者丢失消息；
- 生产者丢失消息：
从生产者弄丢数据这个角度来看，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 如何持久化
- 将queue的持久化标识
durable设置为true,则代表是一个持久的队列 发送消息的时候将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 服务器），
- 使用其他的方式来确保 message 的可靠 delivery ，
- 使用非常快速的存储系统以支持全持久化（例如使用 SSD）。
- 另外一种处理原则是：仅对关键消息作持久化处理（根据业务重要程度），且应该保证关键消息的量不会导致性能瓶颈。
三：Kafka
3.1 什么是Apache Kafka
Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的和重复的日志服务。
是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，
3.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主要用于在集群中不同节点之间进行通信
- 在Kafka中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取
- 除此之外，它还执行其他活动，如: leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
3.7 Kafka的用户如何消费信息
在Kafka中传递消息是通过使用sendfile API完成的。
它支持将字节从套接口转移到磁盘，通过内核空间保存副本，并在内核用户之间调用内核。
3.8 如何提高远程用户的吞吐量
如果用户位于与broker不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。
3.9 在数据制作过程中，如何能从Kafka得到准确的信息
在数据中，为了精确地获得Kafka的消息，你必须遵循两件事: 在数据消耗期间避免重复，在数据生产过程中避免重复。
有两种方法，可以在数据生成时准确地获得一个语义
每个分区使用一个单独的写入器，每当你发现一个网络错误，检查该分区中的最后一条消息，以查看您的最后一次写入是否成功在消息中包含一个主键(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个步骤
- topic中partition存储分布
- partition中文件存储方式
- partition中segment文件存储结构
- 在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中文件存储方式
- 每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。
- 每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。
这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。
3.17.3 partiton中segment文件存储结构
Kafka文件系统partition存储方式
深入分析partion中segment file组成和物理结构
- segment file组成：由2大部分组成，分别为
index file和data file，此2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件 - segment文件命名规则：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小，19位数字字符长度，没有数字用0填充。
3.17.4 在partition中如何通过offset查找message
例如读取offset=368776的message，需要通过下面2个步骤查找。
第一步查找segment file
其中00000000000000000000.index表示最开始的文件，起始偏移量(offset)为0.第二个文件00000000000000368769.index的消息量起始偏移量为368770= 368769 + 1.
同样，第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1，其他后续文件依次类推，以起始偏移量命名并排序这些文件，只要根据offset 二分查找文件列表，就可以快速定位到具体文件。
当offset=368776时定位到00000000000000368769.index|log第二步通过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包含了以下三个属性：
- offset
offset为long型 - MessageSize
MessageSize为int32，表示data有多大 - data
data为message的具体内容
Partition的数据文件则包含了若干条上述格式的Message，按offset由小到大排列在一起。它的实现类为FileMessageSet，
3.20 Kafka是如何解决查找效率的的问题
有两种方法：1) 分段 2) 索引。
3.20.1 数据文件的分段
比如有100条Message，它们的offset是从0到99。
- 假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的offset命名。
- 这样在查找指定offset的Message的时候，
用二分查找就可以定位到该Message在哪个段中。
3.20.2 为数据文件建索引
数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，为进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。
索引文件中包含若干个索引条目，每个条目表示数据文件中一条Message的索引。索引包含两个部分（均为4个字节的数字），分别为相对offset和position。
-
相对offset：因为数据文件分段以后，每个数据文件的起始offset不为0，相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。举例，分段后的一个数据文件的offset是从20开始，那么offset为25的Message在index文件中的相对offset就是25-20 = 5。
存储相对offset可以减小索引文件占用的空间。 -
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 不断在循环中轮询，直到新消息到 达