1, the relationship between the exchange queue binding-key routing-key concepts and mutual
1.queue: storing the message queue, the specified name can be uniquely determined
2.exchange: switches (commonly three) for receiving a message sent by the producers, and the matching relationship is determined by the binding-key will be distributed routing-key message to a specified queue
Direct (routing mode): exact match> binding-key when the routing-key between the exchange and message queue exact match, the message is distributed to the queue
Fanout (subscription model): Non-binding-key and routing-key, the received messages to the queue have all the binding relationship (whatever binding-key and routing-key is)
Topic (Wildcard mode): pattern matching with the routing-key exchange between the binding-key and the message queue, when the rule is satisfied, the rule distributed to satisfy all queues
2. Why use rabbitmq
AMQP Advanced Message Queuing Protocol using a message queue technology,
Achieve a high degree of decoupling between service
1. In a distributed system with asynchronous series of advanced functions, clipping, load balancing;
2. has a persistent mechanism to process the message, a message queue can also be preserved.
3. To achieve between consumers and producers decoupled .
4. For a highly concurrent scenario, clipping limit, conducive to the operation of the database.
The message queue can be used to achieve the effect asynchronous orders, queue, the background logic orders.
3. Use rabbitmq scene
1. asynchronous communication between services
2. The order of consumption
3. regular tasks
4. Request clipping
4. How to ensure that messages are correctly transmitted to RabbitMQ? How to ensure that the message recipient consume the news? How to avoid duplicate message delivery or repeated consumption?
There are two ways persistence MQ things (too much consumption of performance, do not use) and confirm mode .
Transmission confirmation pattern:
To confirm the channel setting mode (transmission confirmation mode), all messages are posted channel is assigned a unique ID.
Once the message is delivered to the destination queue, or after the message is written to disk (persistent message may be), the channel sends an acknowledgment to the producer (containing the unique message ID).
If an internal error occurred causing RabbitMQ message is lost, it sends a nack (not acknowledged, unacknowledged) messages.
Transmission confirmation pattern is asynchronous, while waiting for the application producer acknowledgment, can continue to send the message. When the confirmation message arrives producer application, the application callback method producers will be triggered to process the confirmation message.
Receiving confirmation mechanism
Mechanism acknowledgment message recipient: the consumer receives each message must be acknowledged (message reception and acknowledgment message are two different operating). Consumers only confirmed the news, RabbitMQ can safely delete the message from the queue.
Here and did not use a timeout mechanism, RabbitMQ only to confirm that the need to re-send the message by connecting the Consumer interrupt. In other words, as long as the connection is not interrupted, RabbitMQ to the Consumer sufficient length of time to process the message. Ensure that the final data consistency;
The following lists some special circumstances:
If the consumer receives a message, disconnected or unsubscribe, RabbitMQ think that message was not distributed, then re-distributed to consumers under a subscription before confirming. (There may be a message repeated consumption of risks, need to re)
If the consumer has not received the message confirmation message, the connection has not disconnected, the RabbitMQ think the consumer is busy, it will not give the consumer more news distribution.
When message production, internal MQ message generated for each transmission of a producer inner-msg-id, as a basis to weight (and retransmits the message delivery failure), to avoid duplicate message into the queue;
在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。
消息持久化，当然前提是队列、交换机必须持久化
RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。
消息持久化
ACK确认机制
设置集群镜像模式
消息补偿机制
ACK确认机制
设置集群镜像模式
消息补偿机制
5.消息基于什么传输？
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
6.消息如何分发？
若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。
通过路由可实现多消费的功能
7.消息怎么路由？
消息提供方->路由->一至多个队列
消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
通过队列路由键，可以把队列绑定到交换器上。
消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；
常用的交换器主要分为一下三种：
fanout：如果交换器收到消息，将会广播到所有绑定的队列上
direct：如果路由键完全匹配，消息就被投递到相应的队列
topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符
8.使用RabbitMQ有什么好处？
服务间高度解耦，
异步通信性能高，
流量削峰
缺点：增加了系统复杂度，系统可用性低，外部依赖过多，一致性问题。
持久化的缺地就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。
9.rabbitmq的集群
主备模式：
普通集群模式：节点数据不复制，消息在某一台中，节点间通信，一台挂了 就不可用了。
镜像集群模式：
你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
10、Kafka的高可用
Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据。
这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。
写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。
11、什么情况下会出现 blackholed 问题？
答：blackholed 问题是指，向 exchange 投递了 message ，而由于各种原因导致该 message 丢失，但发送者却不知道。可导致 blackholed 的情况：1.向未绑定 queue 的 exchange 发送 message；2.exchange 以 binding_key key_A绑定了 queue queue_A，但向该 exchange 发送 message 使用的 routing_key 却是 key_B。
12、如何防止出现 blackholed 问题？
答：没有特别好的办法，只能在具体实践中通过各种方式保证相关 fabric 的存在。另外，如果在执行 Basic.Publish 时设置 mandatory=true ，则在遇到可能出现 blackholed 情况时，服务器会通过返回 Basic.Return 告之当前 message 无法被正确投递（内含原因 312 NO_ROUTE）。
13、Consumer Cancellation Notification 机制用于什么场景？
答：用于保证当镜像 queue 中 master 挂掉时，连接到 slave 上的 consumer 可以收到自身 consume 被取消的通知，进而可以重新执行 consume 动作从新选出的 master 出获得消息。若不采用该机制，连接到 slave 上的 consumer 将不会感知 master 挂掉这个事情，导致后续无法再收到新 master 广播出来的 message 。另外，因为在镜像 queue 模式下，存在将 message 进行 requeue 的可能，所以实现 consumer 的逻辑时需要能够正确处理出现重复 message 的情况。
14、Basic.Reject 的用法是什么？
答：该信令可用于 consumer 对收到的 message 进行 reject 。若在该信令中设置 requeue=true，则当 RabbitMQ server 收到该拒绝信令后，会将该 message 重新发送到下一个处于 consume 状态的 consumer 处（理论上仍可能将该消息发送给当前 consumer）。若设置 requeue=false ，则 RabbitMQ server 在收到拒绝信令后，将直接将该 message 从 queue 中移除。
另外一种移除 queue 中 message 的小技巧是，consumer 回复 Basic.Ack 但不对获取到的 message 做任何处理。
而 Basic.Nack 是对 Basic.Reject 的扩展，以支持一次拒绝多条 message 的能力。
15、什么是死信呢？什么样的消息会变成死信呢？
方便我们查看消息失败的原因了
消息被拒绝（basic.reject或basic.nack）并且requeue=false.
消息TTL过期
队列达到最大长度（队列满了，无法再添加数据到mq中）
16、如果让你写一个消息队列，该如何进行架构设计？说一下你的思路。
快速扩容, 分布式, 数据持久化, 磁盘顺序读写, 高可用, 消息0丢失(ack)
17、rabbitMQ怎么做的持久化
写入文件前会有一个Buffer，大小为1M（1048576），数据在写入文件时，首先会写入到这个Buffer，如果Buffer已满，则会将Buffer写入到文件（未必刷到磁盘）
有个固定的刷盘时间：25ms，也就是不管Buffer满不满，每隔25ms，Buffer里的数据及未刷新到磁盘的文件内容必定会刷到磁盘
每次消息写入后，如果没有后续写入请求，则会直接将已写入的消息刷到磁盘：使用Erlang的receive x after 0来实现，只要进程的信箱里没有消息，则产生一个timeout消息，而timeout会触发刷盘操作
18、RabbitMQ、kafka之间的比较
1、 RabbitMq比kafka成熟，在可用性上，稳定性上，可靠性上，RabbitMq超过kafka。rabbitMq 延迟度低。
2、 Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性(不支持事物)
3、 Kafka的性能（吞吐量、tps）比RabbitMq要强，这篇文章的作者认为，两者在这方面没有可比性。
4.技术上面，使用rabbitMq比kafka 长，两者社区活跃度都高。
5.RocketMQ 阿里出品，社区活跃度不是很高，技术实力强大的公司可选择。
