分布式消息队列
一, 消息队列能做什么
1, 应用解耦
模块之间仅依赖“通知”，而没有直接的接口调用，所以不存在依赖
2, 可扩展性
队列支持高可用部署，水平扩展容量和吞吐量
生产者和消费者都只关心“通知”，消息队列提供通知机制，业务众向扩展
3, 异步处理
生产者只管保证把“通知”发送出去，并不关心下游处理结果，允许多个消费者同时消费
4, 削峰填谷
消息队列“堆积”消息，只要不溢出就行
可以添加模块
二, 发布订阅模式
2, 发布订阅模式的两种模式（1）
MQ不断主动把消息推送给消费者，如果消费者处理能力不高，有可能造成消费者本地缓存溢出，但是消息能及时被消费；例如RabbitMQ就支持这种模式
2, 发布订阅模式的两种模式（2）
消费者主动到MQ拉取消息，所以会造成消息并没有即时消费，但是能控制消费的速度，例如kafka支持这种模式。
3, 发布订阅模式的两种模式（3）
- rocketMQ既支持推模式也支持拉模式。
- 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回滚事务了。
确认机制
- 普通确认模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端回复ACK。实际上是一种串行确认了。
- 批量确认模式：每发送一批消息后，调用waitForConfirms()方法，等待服务器端确认。
- 异步确认模式：提供一个回调方法，服务端确认了一条或者多条消息后Client端会回调这个方法。异步确认的投递效率最高，但是编程也更复杂一些。
3, 可靠消费
最大努力投递机制：未收到ack的消息放到重发队列，然后每隔1s，5s，20s，40s….去投递
3, 持久化存储
添加一个 系统漏洞补充系统
四, 系统漏洞补充系统
1,验证是否发货, 没有发货发货
2, 邮件方式通知运维人员（补充货物失败情况）
