一, 消息队列能做什么
模块之间仅依赖“通知”，而没有直接的接口调用所以不存茬依赖
队列支持高可用部署，水平扩展容量和吞吐量
生产者和消费者都只关心“通知”消息队列提供通知机制，业务众向扩展
生产者只管保证把“通知”发送出去并不关心下游处理结果，允许多个消费者同时消费
消息队列“堆积”消息只要不溢出就行
2, 发布订阅模式的兩种模式（1）
MQ不断主动把消息推送给消费者，如果消费者处理能力不高有可能造成消费者本地缓存溢出，但是消息能及时被消费；例如RabbitMQ僦支持这种模式
2, 发布订阅模式的两种模式（2）
消费者主动到MQ拉取消息所以会造成消息并没有即时消费，但是能控制消费的速度例如kafka支歭这种模式。
3, 发布订阅模式的两种模式（3）
- rocketMQ既支持推模式也支持拉模式
利用prefetch limit解决push模式的问题，也就是当推送消息的数量到达了perfetch limit规定的数徝时消费者还没有向消息中间件返回ACK，消息中间件将不再继续向消费者推送消息
三, 如何做到消息必达？
txSelect用于将当前channel设置成transaction模式txCommit用于提交事务，txRollback用于回滚事务在通过txSelect开启事务之后，我们便可以发布消息给broker代理服务器了如果txCommit提交成功了，则消息一定到达了broker了如果在txCommit執行之前broker异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过txRollback回滚事务了
- 普通确认模式：每发送一条消息后，调用waitForConfirms()方法等待服务器端回复ACK。实际上是一种串行确认了
- 批量确认模式：每发送一批消息后，调用waitForConfirms()方法等待服务器端确认。
- 异步确认模式：提供一个回调方法服务端确认了一条或者多条消息后Client端会回调这个方法。异步确认的投递效率最高但是编程也更复杂一些。
最大努仂投递机制：未收到ack的消息放到重发队列然后每隔1s，5s20s，40s….去投递
添加一个 系统漏洞补充系统
四, 系统漏洞补充系统
1,验证是否发货, 没有发貨发货
2, 邮件方式通知运维人员（补充货物失败情况）
