八 消息队列及Rabbitmq

消息队列基础

消息队列应用场景：解耦（耦合性高容错性低）、异步、削峰（秒杀项目将请求缓存起来）

消息队列选型：

消息队列缺点系统可用性降低（一旦MQ宕机）；系统复杂性高（如下所示）；一致性问题

如何保证高可用？（以Rabbitmq为例）
普通集群：
1.在多台机器上分别启动RabbitMQ实例。
2.多个实例之间可以相互通信。
3.创建的Queue只会放在一个RabbitMQ上，其他实例都同步元数据。
4.消费的时候，如果连接的没有Queue,那么当前实例会从queue所在实例拉取数据。
特点
1.没有真正做到高可用
2.有数据拉取的开销和单实例的瓶颈问题

镜像集群
RabbitMQ：使用镜像集群每一个节点都保留完整的数据既有实例数据还有元数据
1.在多台机器.上分别启动RabbitMQ实例。
2.多个实例之间可以相互通信。
3.每次生产者写消息到queue的时候，都会自动把消息同步到多个实例的queuue. 上。每个
RabbitMQ节点上都有Queue的消息数据和元数据。
4.某一个节点宕机，其他节点依然保存完整数据, .不影响客户端消费。

如何保证消息不丢失？

丢失原因发送至MQ过程中丢失；Mq接受到消息还没来得及持久化宕机；消费者获得消息还没处理宕机了

措施针对一MQ接收到后confirm确认，没收到重发。针对二MQ收到消息立即持久化再发确认。针对三：消费方消费完毕进行ACK确认后，mq再删除

如何保证消息不被重复消息？

重复消息是不可能避免的，产生原因网络不可达。

解决办法：
1.消息发送者发送消息时携带一个全局唯一的消息id
2.消费者获取消费后先根据id在redis/db中查询是否存在消费记录
3.如果没有消费过就正常消费，消费完毕后写入redis/db
4.如果消息消费过就直接舍弃

如何保证消费的顺序性?

网络原因导致顺序性
解决方法：生产者、MQ、消费者1比1比1，但有缺陷
缺点：效率低
最好解决办法：使用MQ集群

八 Rabbitmq实现

背景：在freemarker中，接口调用其实是同步的，耦合度也很大，如果前端有很多地方进行部署的话，那么后端需要修改代码。

工厂就是后端，他会生成html,虽然发送通知到mq，这就相当于发了一个消息到消息队列货。消费者也就是前端节点的应用监听到以后，是下载html到给子的服务节点中去了。

Rabbitmq:

●RabbitMQ: 消息队列服务中间件
●生产者produce: 创建消息，发送到mq
●消费者Consumer: 监听消息，处理业务通知
●Exchange: MQ的交换机，他会按照一定的规则来转发到某个队列，类似controller路由机制。比如/article/read
●Queue:队列,存储消息。相当于controller。 被消费者监听，一旦有消息，会被消费者接收到。
●Channel: 生产者和消费者与MQ建立的通道，相当于httpSession会话， 建立请求就会有channel。可
以理解为一个桥梁作用，消息经过桥梁到达mq的queue。