- mq常见的用途有哪些
1.异步:将非必要的业务逻辑写入消息队列，以异步的方式运行，加快响应速度。如果有一个注册功能，将用户信息写入数据库后，发送邮件给用户邮箱。发送邮件时间比较长，不用异步的情况下用户需要等好长时间才能得到注册成功结果，体验很差。用了异步之后，信息落库之后将发送邮件的请求放入mq，然后直接返回注册成功，响应速度快体验好。
2.解耦:一般用于和第三方对接接口。将消息写入消息队列，需要消息的时候第三方系统从消息队列中订阅，如果需要增加或减少第三方系统，只需要自行订阅或者取消订阅即可，不需要改动代码。
3.削峰:当有特殊活动使得某一时刻请求量激增时，将请求放入mq，系统慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。
4.延时队列:有的需求需要延迟执行某个功能，比如下订单后如果用户未付款需要延迟对订单进行取消，这时候可以下订单后将订单信息放入延迟队列中，延迟队列的消息过期后加入取消队列(死信队列)，消费取消队列中的消息并判断订单是否已付款，如果未付款的话进行取消订单。
常见的mq有哪些？如何根据业务选择相应的mq
1.ActiveMQ:吞吐量万级，延迟在ms级别，可用性高，有较低概率丢失数据，且社区活跃度不高。
2.RabbitMQ:吞吐量万级，结合erlang语言本身的并发优势，时效性微秒级延迟是最低的，社区活跃度也比较高，管理界面用起来十分方便，如果你的数据量没有那么大，中小型公司优先选择功能比较完备的RabbitMQ。
3.Kafka:吞吐量十万级，Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
4.RocketMQ:吞吐量十万级，天生为金融互联网领域而生，可用性极高，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰，在大量交易涌入时，后端可能无法及时处理的情况。RoketMQ在稳定性上可能更值得信赖，这些业务场景在阿里双11已经经历了多次考验，如果你的业务有上述并发场景，建议可以选择RocketMQ。
总结:
般业务系统需要引入MQ，最早使用的是ActiveMQ，但现在用的不多了，没有经过大规模吞吐场景的验证，
社区也不活跃，不建议使用。
如果业务需要大数据的实时计算、日志采集等需求，推荐使用Kafka。
对于小公司吞吐量需求不是那么高的，用rabbitMQ即可。对于互联网公司高吞吐量分布式项目推荐使用RocketMQ。rabbitmq核心概念有哪些
1.Server:又称Broker，简单来说就是消息队列服务器实体。
2.Exchange:消息交换机，它指定消息按什么规则，路由到哪个队列。
3.Queue:消息队列载体，每个消息都会被投入到一个或多个队列。
4.Binding:绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
5.RoutingKey:路由关键字，exchange根据这个关键字进行消息投递。
6.Producer:消息生产者，就是投递消息的程序。
7.Consumer:消息消费者，就是接受消息的程序。
8.Channel:消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。
由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。四种交换机是什么
生产者将消息发送给交换机，交换机将消息发送到队列，消费者从队列中获取消息。不同类型交换机发送消息到队列的策略不同。
1.direct exchange:此类型的交换机通过路由键绑定各种队列，生产者发送消息和路由键，将消息转发到该路由键绑定的队列里。
2.fanout exchange:此类型的交换机不处理路由键，直接将消息转发到所有绑定的队列上。
3.topic exchange:此类型的交换机与direct类似，都需要绑定路由键，只不过topic是模式匹配。类似模糊查询。例如:绑定abc.#则路由键为abc.1213.aa这类可以匹配上的消息都可以投递。
4.headers exchange:不处理路由键，而是根据消息中的headers属性进行匹配。(基本不用)如何保证投递消息的可靠性
1.发送方确认模式:将信道设置成confirm模式(发送方确认模式)，则所有在信道上发布的消息都会被指派一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后(可持久化的消息)，信道会发送一个确认给生产者(包含消息唯一ID)。如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack(notacknowledged，未确认)消息。发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
2.接收方确认机制:消费者接收每一条消息后都必须进行确认(消息接收和消息确认是两个不同操作)。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。这里并没有用到超时机制，RabbitMQ仅通，过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性。
