共计 3139 个字符，预计需要花费 8 分钟才能阅读完成。
咱们明天再来进一步学习一下 RabbitMQ 的知识点，整顿了如下相干知识点
- RabbitMQ 音讯流向是如何走的
- 交换机相干的知识点
- 队列相干的知识点
- 死信队列，提早队列，长久化
- 队列中传输音讯的保障机制有哪些
- 生产者确认的问题有哪些
- 消费者生产的模式有哪些
RabbitMQ 音讯流向是如何走的？
生产者发送音讯的时候
- 生产者连贯到 RabbitMQ Broker，建设一个连贯，开启一个信道
- 生产者申明一个交换机，并设置相干属性，例如交换机类型、是否长久化等
- 生产者申明一个队列并设置相干属性，例如是否排他、是否长久化、是否主动删除等
- 生产者通过路由键将交换机和队列绑定起来
- 生产者发送音讯至 RabbitMQ Broker，其中蕴含路由键、交换机等信息
- 相应的交换机依据接管到的路由键查找相匹配的队列
- 如果找到，则从生产者发送过去的音讯存入相应的队列中
- 如果没有找到，则依据生产者配置的属性抉择抛弃还是回退给生产者
- 敞开信号
- 敞开连贯
消费者接管音讯的过程
- 消费者连贯到 RabbitMQ Broker，建设一个连贯，开启一个信道
- 消费者向 RabbitMQ Broker申请生产相应队列中的音讯，可能会设置相应的回调函数，以及做一些筹备工作
- 期待 RabbitMQ Broker 回应并投递相应队列中的音讯，消费者接管音讯
- 消费者确认接管到的音讯
- RabbitMQ 从队列中删除相应曾经被确认的音讯
- 敞开信道
- 敞开连贯
罕用的交换机都有哪些？
不同交换机有不同交换机的个性
- fanout
适宜公布订阅式，播送的形式来传递音讯
- direct
适宜路由到指定队列的传输音讯
- topic
与上述交换机相似，只是多了通配符
- headers
会匹配音讯的 headers，易用性较差
fanout exchange 能够做成备份的交换机，因为 fanout 的音讯是播送的形式
若 A 生产者 A 音讯发送到 A 交换机，路由到 A 队列，若 A 音讯填写的路由 key 与 A 队列的绑定 key 不对齐，则会被从新发送到 另外一个备份 fanout 交换机上
- 如果设置的备份交换机不存在，音讯会失落
- 如果设置的备份交换机没有绑定任何队列，音讯会失落
- 如果设置的备份交换机没有任何匹配的队列，音讯会失落
队列相干知识点有哪些？
设置 音讯的 TTL
- 通过队列属性
x-message-ttl（单位毫秒）设置，队列中所有音讯都有雷同的过期工夫 - 对音讯自身进行独自设置，每条音讯的 TTL 能够不同
若两种形式一起应用，则音讯的 TTL 以两者之间较小的那个数值为准
音讯在队列中的生存工夫一旦超过设置的 TTL 值时，就会变成 死信，消费者将无奈再收到该音讯
另外对于 TTL 的 2 种状况：
- 如果不设置 TTL，则示意此音讯不会过期
- 如果将 TTL 设置为 0，则示意除非此时能够间接将音讯投递到消费者，否则该音讯会被立刻抛弃
设置队列的 TTL
通过队列属性 x-expires 能够管制队列被主动删除前处于未应用状态的工夫，未应用状态的工夫 有如下含意：
- 队列上没有任何的消费者
- 队列也没有被从新申明
死信队列是什么
当音讯在一个队列中变成死信之后，它能从新被发送到另一个交换机中，这个交换机就是 死信交换机，绑定死信交换机 的队列就称之为死信队列
音讯变成死信有这几种状况：
- 音讯被回绝了
- 音讯过期了
- 队列达到了最大的长度
这个 死信交换机，也是一个失常的交换机
能够被任何一个队列指定，被指定成死信交换机的时候，会设置 x-dead-letter-exchange属性，并且会设置对应的路由键 x-dead-letter-routing-key
死信队列的利用场景有哪些
- 解决异常情况
音讯不可能被消费者正确生产而被置入死信队列中的状况，后续分析程序能够通过生产这个死信队列中的内容来剖析过后所遇到的异常情况，进而能够改善和优化零碎
- 搭配 TTL 模仿提早队列
提早队列是什么？
音讯发送到队列之后，并不冀望消费者能马上生产，也是提早一段时间之后，才拿到该音讯进行生产。
提早队列咱们是 应用 死信队列 和 TTL 来模仿 提早队列 的
提早队列应用的场景举个栗子：
- 下单了一个外卖，须要在 15 分钟以内实现领取，若未按时实现，则属于异样解决，须要提早队列来解决这些音讯
本例子中，用户下单，将音讯丢入队列中，TTL 为 15 分钟，若 15 还未实现领取，则音讯会被丢入对应的 死信队列中进行解决
优先级队列是什么？
指的是 具备高优先级的队列具备最高的优先权，优先级高的音讯具备优先被生产的特权
能够通过 设置 x-max-priority 来设置 优先级队列
当然，如果在消费者的 生产速度远大于生产者的速度，且 Broker 没有音讯沉积的状况下，对发送的音讯设置优先级没有什么实际意义，因为生产者生产的音讯，都能很快的被消费者立即毁灭掉
长久化都有哪些？
为了进步 RabbitMQ 的可靠性，RabbitMQ 做了长久化，长久化有这三局部：
- 交换机的长久化
RabbitMQ 服务重启，若交换机不设置长久化，交换机的元数据会失落，音讯不会失落，不过音讯再也不能发送到这个交换机中了
- 队列的长久化
RabbitMQ 服务重启，若队列不设置长久化，元数据会失落，数据也会失落
- 音讯的长久化
设置所有的音讯长久化，可靠性会大大提高，可是对于性能上是一个微小的影响，这是一个可靠性和吞吐量之间做一个衡量
队列中传输音讯有哪些保障的机制？
音讯的传输保障，对于个别的消息中间件来说，会思考这三个层级
- 最多一次
音讯可能会失落，但不会反复
其中最多一次投递实现须要思考以下几个方面的内容：
- 音讯生产者须要开启 事务机制 或者 确认机制，以确保音讯能够牢靠地传输到 RabbitMQ 中
- 音讯生产者须要配合应用 备份交换机 来确保音讯可能从交换机路由到队列中，进而可能保留下来而不会被抛弃
- 音讯和队列都须要进行 长久化 解决，以确保 RabbitMQ 服务器在遇到异常情况时不会造成音讯失落
- 消费者在生产音讯的同时须要将autoAck 设置为 false，而后通过手动确认的形式去确认曾经正确生产的音讯，以防止在生产端引起不必要的音讯失落
- 起码一次
音讯可能会反复，但不会失落
生产者随便发送，消费者随便生产
- 恰好一次
每条音讯肯定只会被传输一次
RabbitMQ 这边 反对最多一次和至多一次
恰好一次是 RabbitMQ 无奈保障的，会有这样几个起因
消费者在生产完一条音讯之后向 RabbitMQ 发送确认命令
此时因为异样起因（网络，或宕机）造成 RabbitMQ 并没有收到这个确认命令，RabbitMQ 不会将此条音讯标记删除。
在从新连贯之后，消费者还是会生产到这一条音讯，这就造成了反复生产
生产者在应用 确认机制 的时候，发送完一条音讯期待 RabbitMQ 返回确认告诉
此时正好网络断开，生产者捕捉到异常情况
为了确保音讯可靠性抉择从新发送，这样 RabbitMQ 中就有两条同样的音讯，在生产的时候，消费者就会反复生产
那么生产者确认问题呢？
RabbitMQ 中的生产者确认机制有 两种模式
- 事务模式
事务模式性能非常低，不倡议应用。
事务机制在一条音讯发送之后会使发送端阻塞，以期待 RabbitMQ 的回应，之后能力持续放下一条音讯，这种形式会影响性能，所以不倡议应用
- 发送方确认模式 confirm 模式
发送方确认机制最大的益处在于它是异步的，一旦公布一条音讯，生产者就能够在等信道返回确认的同时持续发送下一条音讯
当音讯最终失去确认之后，生产者便能够通过回调形式来解决该确认音讯，哪怕是 RabbitMQ 本人外部呈现了谬误，也会回复响应的应答给到生产者 例如Nack
消费者解决音讯的模式有哪些？
- 推模式
消费者失常启动程序之后，会是推模式
- 拉模式
在消费者程序第一次起来的时候，是拉模式
参考资料：
RabbitMQ Tutorials
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 小魔童哪吒，欢送点赞关注珍藏，下次见~
