MQ的一些总结

原代码地址 快速掌握RabbitMQ(二)——四种Exchange介绍及代码演示 - 捞月亮的猴子 - 博客园 (cnblogs.com) 

1 
四种交换规则
   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条数据进行处理，
这样就不用担心消息丢失、服务端内存爆满的问题了，因为没有发送的消息状态都是Ready，所以当我们新增一个消费者时，消息也可以立即发送给新增的消费者。注意Qos只有在消费端使用显示确认时才有效，
使用Qos的方式十分简单

4  
参考地址 RabbitMQ从零到集群高可用.NetCore(.NET5) - 死信队列，延时队列 - 包子wxl - 博客园 (cnblogs.com)
 1死信队列
  就是消息未处理，放到一个专门队列里，还可以使用
 2延迟队列
   延迟执行P(生产者)发送消息到Q1(延时队列)，Q1的消息有过期时间，比如10s，那10s后消息过期就会触发死信，从而把消息转发到Q2（死信队列）。