RabbitMQ_rabbitmq 监控模板 表格详细说明
赞
踩
前言
一、MQ是什么？
用高效可靠的消息机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。
二、为什么要用MQ？
、如上图所示，可以将各个系统之间的交互拆开，通过消息队列去做访问，也就是实现了系统之间的解耦。
当某一时刻的访问量急剧增加的时候，如淘宝双十一，秒杀活动等。在一个时段有大量的访问者，可能会导致服务器处理不过来，导致服务器宕机。但是通过MQ去做处理的话，就不会出现突然间的大量数据的涌入，而是根据MQ的处理机制，以该有的速度匀速发布给各个处理服务器，也就保证了服务器的处理保持相对稳定的状态。
3.异步通信
通过MQ实现异步通信，提高用户的体验，以及效率，无需同步通信，一直等待，直到获取结果，才可以进行下一条数据的处理。
三、带来的问题
1.如果MQ挂了那么整个系统就不能用了
2.复杂度提高了
3.消息在链路中会出现一致性问题
提示：以下是本篇文章正文内容，下面案例可供参考
一、RabbitMQ的基本特性
高可靠、灵活路由、支持多客户端、集群与扩展性、高可用队列、权限管理、插件系统、与Spring集成Spring AMQP等等。
二、工作模型
1、broker：中间件（MQ）、存储转发
2、Connection： TCP长连接，长连接比较消耗性能，所以用在TCP里面用channel（虚拟信道）
3、Queue：真正存储东西的，有自己的进程
4、基于实践，对队列进行监听，只要有数据到达队列，就会去消费消息，并返回一个应答，queue删除取走的消息，并推送下一条
5、RabbitMQ的消息会先发送到交换机，而不会直接发送到queue，Exchange是以绑定列表，与队列是一个多对多的关系，交换机用来给不同的queue发送消息，依据绑定规则，与不同的队列绑定，交换器是为了灵活的分发
6、支持虚拟主机，可以在同一个RabbitMQ，运用于多个项目，通过虚拟主机来隔离
三、Exchange路由消息
1. Direct直连
会将该消息发送给路由key等于绑定key的queue。
2.Topic主题
图中相关元素说明：
1、 * 一个单词
netty.*
表示以netty开头，后面刚好是一个单词可以匹配
*.jvm
表示以jvm结尾，并且以一个单词开头
2、# 0个或者多个单词
junior.#
表示只要是以junior开头，后面有没有单词都可以匹配上
3、单词就是以“.”隔开的字符
3.Fanout广播
不需要使用绑定建，也不用路由键
会把消息分发给所有和它绑定的队列
使用的时候，消息是先到交换机然后再到队列，没有指定交换机的时候会发送到默认的交换机，然后再根据绑定键发送到queue上
四、高级特性
1、死信队列
1）TTL：可以设置队列消息统一的过期时间，也可以为每一个消息设置一个单独的过期时间，如果两种都设置了TTL，则以小的那个时间为准。
2）死信交换机就是用来转发死信的交换机，接收死信的队列就是死信队列。
3）死信：死信就是超过了TTL的时间还没有被消费的消息，出现死信之后，会将该死信发送给死信交换机。
被消费者拒绝了，并且不重回队列也是死信；
如果设置了max length（条数） / max length bytes （字节数），那么即使没有过期时间，当超过了这个最大值，会把先进入队列的消息成为死信。
4）死信交换机：死信交换机就是用来转发死信的交换机
5）死信队列：接收死信的队列就是死信队列
2、延迟队列
1）需要插件，x-delayed-message type（插件提供的类型）
2）定时器，可以通过定时任务实现
3、流量控制
1）服务端限流
x-max-length：
可以接收最大的条数（超过了会删除最先进的一条，保证队列条数的恒定）
x-max-length-bytes：
可以接收最大的字节大小（超过了会删除最先进的一条，保证队列字节大小的恒定）
内存控制：
Conn vm_memory-high-watermark，设置当达到当前硬件内存多少的时候将block，不在接收消息
磁盘控制：
disk_free_limi._relative=0.3，相对值（达到磁盘的百分之30就不可用了）
disk_free_limit.absolute=2GB，绝对值（只剩下2GB不可用）
2）消费端限流
关闭自动应答，当处理完消息，手动给服务端发送应答。channel设置了basicQos后，当服务端发送了设置的数量而没有收到消费端的ACK应答的时候，就不会再给该消费端发送消息了
SpringAMQP
Spring boot集成（详细过程暂不介绍）
对象定义：创建交换机、队列、绑定
监听关系：消费者类监听队列
发送消息：注入模板发送消息
五、消息可靠性投递
RabbitMQ在消息投递的过程中有四个环节可能会导致消息的可靠性问题：
1：生产者到Exchange
（1）服务端确认-Transaction模式：
问题：同步操作，第一条没有完成，会阻塞第二条消息，并且交互指令过多，资源消耗过大，生产环境不建议使用这种模式。
（2）服务端确认-Confirm模式：
问题：同样也是发一条，确认一条，效率不高
（3）服务端确认-BatchConfirm模式：
批量确认
问题：数量如何控制，如果某一条出现问题，会导致整批失败，全部重发
服务端确认-AsyncConfirm模式
异步确认，允许批量以及单条数据的确认
使用set集合来存放需要确认的消息，确认一条消息就从set集合中删除一条。如果是批量的返回的数值就是前多少条都被确认了；如果是单条，则代表第几条消息被确认了
2：Exchange到Queue，路由保证
（1）mandatory（参数设置为true） = true + ReturnListener
回发监听，当交换机无法路由到正确的队列的时候，回发给一个生产者
（2）指定交换机的备份交换机
当消息无法路由的时候，就会把消息转发给设置的备份的交换机。通过设置alternate-exchange属性实现
3：消息在queue中的储存
（1）如果出现了故障宕机，消息有可能会从队列中丢失
（2）交换机和队列以及消息的持久化
4：消息从queue投递到消费者
（1）消费者从队列中拿到了消息，但是处理的时候出现了问题，最终还是失败了
（2）AutoACK，默认消费者一拿到消息马上返回确认消息，但是如果此时处理的过程中出错，还是导致最终的失败
解决办法：将自动的ACK设置为手动ACK（autoACK设置为false），在处理成功之后，再手动调用ACK的方法。如果失败的话，返回确认失败。也可以拒收。
注意：必须要在finally中做一个处理，以免出现异常不返回确认导致消息堆积
六、集群与高可用
1、目的：
高可用
负载均衡
2、前提：
/var/lib/rabbitmq/.erlang.cookie 要保持一致，一致才会认为在一个集群里
25672端口给集群提供通信
3、节点类型
disc（默认，如果集群里只有一个节点一定是disc）：存在磁盘里
RAM：同时把数据存储在内存和磁盘里，读写在内存操作，持久化在磁盘操作。效率比较高，集群架构一般用RAM提供对外服务，disc来做数据存储
4、普通集群
只同步元数据，不同步队列的内容，相当于一个指针，指向一个真实的节点
节省垂直空间，网络开销，但是不能保证高可用
5、镜像队列集群
数据会在节点之间同步，可用性更高，就是会消耗一定的性能
创建方式
在操作界面创建
架构图
实战经验总结
一、资源管理
1、交换机队列谁来创建？
消费者，遵循谁使用谁管理的原则
2、如何创建？
可以在界面创建。
代码中创建。
Spring中配置。
二、配置文件与命名规范
三、如何简化或灵活切换MQ
可以自己再封装一层
四、如何实现消息可追溯/重发
可以使用表将报文存起来，需要重发可以使用定时器去扫描失败的记录等
五、生成环境运维监控
引入第三方插件
六、如何减少连接数
可以将多条数据拼接成json数组的形式去推送
等等...
