1、交換キューバインディングキールーティングキー概念と相互関係
1.queue：メッセージ・キューを記憶し、指定された名前は一意に決定することができます
2.exchange：プロデューサによって送信されたメッセージを受信するためのスイッチ（通常3つ）、及びマッチング関係がバインディング鍵によって決定されるが、指定されたキューにルーティング鍵メッセージ配布されます
直接（ルーティングモード）：完全一致>交換およびメッセージキュー完全一致との間のルーティングキーは、メッセージをキューに配信されたときにキー結合
ファンアウト（サブスクリプションモデル）：非結合キーとルーティングキー、キューに受信したメッセージは、（結合キーとルーティングキーが何であれ）すべてのバインディング関係を持っています
トピック（ワイルドカードモード）：ルールが満たされたバインディング鍵とメッセージキューの間でルーティング鍵交換を用いてパターンマッチングは、ルールは、すべてのキューを満たすために、分散します
2.なぜ使用のRabbitMQ
AMQP高度なメッセージキュープロトコルには、メッセージキュー技術を使用して
サービス間のデカップリングの高度を達成
有する分散システムにおいて、非同期拡張機能、クリッピング、負荷分散の一連。
2.メッセージを処理するための永続的な機構を有し、メッセージキューも維持することができます。
3.は、消費者と生産者の間で達成するためにデカップリング。
高度に並行シナリオ4.、クリップデータベースの操作に資する限度を、。
メッセージキューは、効果の非同期の受注、キュー、背景ロジックの受注を達成するために使用することができます。
3.使用RabbitMQのシーン
サービス間の1の非同期通信
消費のために2
3.定期的なタスク
4.リクエストクリッピング
メッセージが正しくRabbitMQのに送信されていることを確認する方法4.？メッセージの受信者がニュースを消費していることを確認するには？重複メッセージの配信や繰り返し消費を避けるためにどのように？
2つの方法があります永続 MQのものを（パフォーマンスのあまり消費、使用しないでください）とモードを確認します。
送信確認パターン：
チャンネル設定モード（送信確認モード）を確認するには、すべてのメッセージは、チャネルが固有のIDが割り当てられます掲載されています。
（永続メッセージがあってもよい）、メッセージが宛先キューに配信されると、メッセージがディスクに書き込まれた後、チャネルは、プロデューサ（一意のメッセージIDを含む）への肯定応答を送信します。
内部エラーが原因RabbitMQのメッセージが失われた発生した場合には、NACK（肯定応答されない、未確認の）メッセージを送信します。
送信確認パターンは、アプリケーションプロデューサー確認応答を待っている間に、メッセージを送信し続けることができ、非同期です。確認メッセージは、プロデューサアプリケーションを到着したとき、アプリケーションのコールバックメソッドのプロデューサは、確認メッセージを処理するようにトリガされます。
確認のメカニズムを受けます
機構確認メッセージの受信者：消費者は、（メッセージ受信確認応答メッセージは、2つの異なる動作している）各メッセージが肯定応答されなければならない受け取ります。消費者は唯一のRabbitMQは、安全にメッセージをキューから削除することができ、ニュースを確認しました。
ここでは、タイムアウトメカニズムを使用していなかった、RabbitMQのが唯一の必要性が消費者の割り込みを接続することで、メッセージを再送信することを確認します。換言すれば、限り、接続が中断されないように、時間の消費者に十分な長さのRabbitMQは、メッセージを処理します。最終的なデータの一貫ことを確認してください。
以下は、いくつかの特別な状況を示しています。
消費者が切断または解除メッセージを受信した場合、RabbitMQのは確定する前にそのメッセージが配信されなかった、サブスクリプションの下で消費者に再配布さだと思います。（再する必要があり、リスクのメッセージを繰り返し消費があるかもしれません）
消費者がメッセージの確認メッセージを受信していない場合は、接続が切断されていない、RabbitMQのは、消費者がビジー状態である、それは消費者に多くのニュース配信を与えていないと思います。
メッセージの生成は、内部MQメッセージは重量に対する基礎として、プロデューサ内-MSG-IDの各送信のために生成（およびメッセージ配信の失敗を再送信する）場合、キューに重複したメッセージを回避します。
在消息消费时，要求消息体中必须要有一个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 阿里出品，社区活跃度不是很高，技术实力强大的公司可选择。
