八、代码实现-自动/手动应答 _队列

这里写自定义目录标题
一、的概念
是一个消息中间件，他接收并且供第三方使用。就像快递一样，商家为生产者，快递站为MQ ，而用户为消费者。
二、为什么使用解耦
比如公司的系统A ，需要将数据推送到其他不同的系统中去。这样子系统间的耦合度变高，系统A需要考虑一些列乱七八糟的因素，如其他系统挂了，需不需要重新推送、、等待问题。这时候如果使用，则系统A只需要考虑将数据推送到，其他系统需要消费的，自己去系统A获取即可，可以有效的做到系统A与其他系统的解耦。削峰
比如公司的业务存在高峰期，如上午数据写入存在w/s的数据量，而数据库的承受量加入只有k/s ，系统就有可能导致崩溃卡死。但是如果将消息写入，由控制消息读取速度小于系统承受量，这样即使在高峰时期也不会挂掉。异步
比如系统A存在需求，如果接受某一份数据，则需要写入A系统和其他系统，时间是累加的。但是如果将数据发送到其他，由各个系统自己实现写入，则写入的时间将会大幅度缩减。三、使用的缺点系统可用性
由于加入了，导致系统的组件增加，部署与运维难度增加。而且如果挂掉，也会影响系统的使用。
2.数据一致性
因为加入了，需要考虑的因为也会随之增加。比如消息丢失、消息重复消费、消息发送成功却是否被消费者成功消费等等、、、四、MQ的选择名称优点缺点适用场景
单机吞吐量万级，时效性ms级，可用性高，较低概率出现丢失数据。
官方社区现在对于5.x的版本维护越来越少，高吞吐量场景较少使用。
早期使用的，随着其他MQ的出现使用量渐渐减少，而且没经过大规模吞吐量场景的验证，社区也不是很活跃，所以不推荐。
Kafka
单机吞吐量百万级，时效性 ms级，可用性非常高，消息可靠性可配置 0 丢失。而且是分布式的，一个数据有多个副本，少数机器宕机也不会丢失数据。
单机超过64个队列/分区， CPU会明显变高，队列越多越高，发送消息响应时间变长。消费失败不支持重试。
主要用于日志的采集与传输，一般大公司使用
单机吞吐量十万级，可用性高，支持分布式，消息可靠性可以做到0丢失，扩展性好，支持十亿级别消息堆积。
支持的客户端不多，目前只支持java和c++ 。
主要用于金融领域，被阿里广泛的用于订单、交易、重置、消息推送等场景。
用语言编写，性能较好，单机吞吐量万级，时效性μs级，可用性高，消息可靠性基本不丢失，而且支持大量的其他语言，社区活跃度高，更新频率高。
商业版需要收费，学习成本较高。
界面管理方便，功能完备。如果数据量较小可以推荐使用，适用于中小型公司。
五、安装
ps：由于需要的包下载较慢，可以直接从这里下载（网络较好的可以忽略）：
由于需要的支持，所以下载包之前需要确定和的对应关系：安装