MQ的一些总结

原代码地址 <a href="https://www.cnblogs.com/wyy1234/p/10837615.html">快速掌握RabbitMQ(二)——四种Exchange介绍及代码演示 - 捞月亮的猴子 - 博客园 (cnblogs.com)</a> <a href="https://home.cnblogs.com/u/wyy1234/"><br></a>1 <br>四种交换规则
   1 direct类型
   根据不同的routingKey 和推送到不同的消费者
  2 fanout类型
   生产和消费 定义 对应交换机和队列，然后根据这两个 来确认关系和推送
3 topic路由规则
    模糊匹配
4  header类型
  通过 head提送数据
RabbitMQ的交换机(exchange)的作用是路由消息，我们可以根据应用场景的不同选择合适的交换机。如果需要精准路由到队列，
或者对消息进行单一维度分类(只对日志的严重程度这一维度进行分类)可以使用direct类型交换机；
如果需要广播消息，可以使用fanout类型的交换机；
如果对消息进行多维度分类(如例子中按照地区和消息内容类型两个维度进行分类)使用topic类型的交换机；
如果消息归类的逻辑包含了较多的AND/OR逻辑判断可以使用header类型交换机(开发中很少用到Header类型，官网上关于Header类型的介绍也不多)。
 
2
 1 消费模式
   1 TX机制
    类似数据库事务， 出错就回滚，
    2 Confirm模式
     这个有点像工作单元，消息处理全部ok,返回true,出错返回false,并抛出异常（这个和上面结合挺好）
 
   2 消费者消息确认（自动确认和显示确认）
     
  1 自动确认
    就是自动处理了，不会管你消息处理ok不ok，
 2  显示确认
    添加确认代码执行后才添加回执
       
 3 消息持久化
   就是保存到磁盘，mq挂了再取出来，不会丢失消息
 
 4 消息优先级
   就是消息排序，那个先发送
 
3
1 消费模式
    1 EventingBasicConsumer介绍
        这个就是发布订阅模式，可以一直推送，长连接
    2 BasicGet方法介绍
        这个只获取一次，类似http请求，请求一次返回一次
 
    3 QueueBaicConsumer  已过时
 
2   Qos 服务质量
    就是例如推了100条，消费者接受100条，但是中途服务器断了，就没了，(也可以显示确认，但是有缺点1 数据过多是内存爆了。2  单个消费者处理过慢时可添加消费者，但是这些消息都被原来的消费者接收了，状态为Unacked，所以这些消息不会再发送给新添加的消费者。针对这些问题怎么去解决呢？)
所有添加qos，分批次推送并确认
可以完美解决上边的问题，使用Qos时，Broker不会再把消息一股脑的发送给消费者，我们可以设置每次传输给消费者的消息条数n，消费者把这n条消息处理完成后，再获取n条数据进行处理，<br>这样就不用担心消息丢失、服务端内存爆满的问题了，因为没有发送的消息状态都是Ready，所以当我们新增一个消费者时，消息也可以立即发送给新增的消费者。注意Qos只有在消费端使用显示确认时才有效，<br>使用Qos的方式十分简单<br><br>4  <br>参考地址 <a href="https://www.cnblogs.com/wei325/p/15204179.html">RabbitMQ从零到集群高可用.NetCore(.NET5) - 死信队列，延时队列 - 包子wxl - 博客园 (cnblogs.com)</a><br> 1死信队列<br>  就是消息未处理，放到一个专门队列里，还可以使用<br> 2延迟队列<br>   延迟执行P(生产者)发送消息到Q1(延时队列)，Q1的消息有过期时间，比如10s，那10s后消息过期就会触发死信，从而把消息转发到Q2（死信队列）。<br>    <br><br><br>