分布式消息队列-MQ

分布式消息队列

一, 消息队列能做什么

1, 应用解耦

模块之间仅依赖“通知”，而没有直接的接口调用，所以不存在依赖

2, 可扩展性

队列支持高可用部署，水平扩展容量和吞吐量
生产者和消费者都只关心“通知”，消息队列提供通知机制，业务众向扩展

3, 异步处理

生产者只管保证把“通知”发送出去，并不关心下游处理结果，允许多个消费者同时消费

4, 削峰填谷

消息队列“堆积”消息，只要不溢出就行

可以添加模块

二, 发布订阅模式

2, 发布订阅模式的两种模式（1）

MQ不断主动把消息推送给消费者，如果消费者处理能力不高，有可能造成消费者本地缓存溢出，但是消息能及时被消费；例如RabbitMQ就支持这种模式

2, 发布订阅模式的两种模式（2）

消费者主动到MQ拉取消息，所以会造成消息并没有即时消费，但是能控制消费的速度，例如kafka支持这种模式。

3, 发布订阅模式的两种模式（3）

1. rocketMQ既支持推模式也支持拉模式。
2. ActiveMQ解决push模式溢出的问题

利用prefetch limit解决push模式的问题，也就是当推送消息的数量到达了perfetch limit规定的数值时，消费者还没有向消息中间件返回ACK，消息中间件将不再继续向消费者推送消息。

三, 如何做到消息必达？

1, 可靠投递

2, 事物机制

比如RabbitMQ中与事务机制有关的方法有三个：txSelect(), txCommit()以及txRollback(), txSelect用于将当前channel设置成transaction模式，txCommit用于提交事务，txRollback用于回滚事务，在通过txSelect开启事务之后，我们便可以发布消息给broker代理服务器了，如果txCommit提交成功了，则消息一定到达了broker了，如果在txCommit执行之前broker异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过txRollback回滚事务了。
确认机制

1. 普通确认模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端回复ACK。实际上是一种串行确认了。
2. 批量确认模式：每发送一批消息后，调用waitForConfirms()方法，等待服务器端确认。
3. 异步确认模式：提供一个回调方法，服务端确认了一条或者多条消息后Client端会回调这个方法。异步确认的投递效率最高，但是编程也更复杂一些。

3, 可靠消费

最大努力投递机制：未收到ack的消息放到重发队列，然后每隔1s，5s，20s，40s….去投递

3, 持久化存储

添加一个 系统漏洞补充系统

四, 系统漏洞补充系统

1,验证是否发货, 没有发货发货

2, 邮件方式通知运维人员（补充货物失败情况）