【MQ我可以讲一个小时】

应用场景，消息可靠投递，消息丢失，消息重复消费，消息的幂等性，消息的顺序性，消息队列积压，延迟队列，消息过期失效，消息队列的高可用

使用消息队列有解耦，扩展性，削峰，异步等功能，市面上主流的几款mq，rabbitmq，rocketmq，kafka有各自的应用场景。kafka，有出色的吞吐量，比较强悍的性能，而且集群可以实现高可用，就是会丢数据，所以一般被用于日志分析和大数据采集。rabbitmq，消息可靠性比较高，支持六种工作模式，功能比较全面，但是由于吞吐量比较低，消息累积还会影响性能，加上erlang语言不好定制，所以一般使用于小规模的场景，大多数是中小企业用的比较多。rocketmq，高可用，高性能，高吞吐量，支持多种消息类型，比如同步，异步，顺序，广播，延迟，批量，过滤，事务等等消息，功能比较全面，只不过开源版本比不上商业版本的，加上开发这个中间件的大佬写的文档不多，文档不太全，这也是它的一个缺点，不过这个中间件可以作用于几乎全场景。
引入消息中间件也会带来很多问题，先说说消息丢失，生产者往消息队列发送消息，消息队列往消费者发送消息，会有丢消息的可能，消息队列也有可能丢消息，通常MQ存盘时都会先写入操作系统的缓存页中，然后再由操作系统异步的将消息写入硬盘，这个中间有个时间差，就可能会造成消息丢失，如果服务挂了，缓存中还没有来得及写入硬盘的消息就会发生消息丢失。不同的消息中间件对于消息丢失也有不同的解决方案，先说说最容易丢失消息的kafka吧。生产者发消息给Kafka Broker：消息写入Leader后，Follower是主动与Leader进行同步，然后发ack告诉生产者收到消息了，这个过程kafka提供了一个参数，request.required.acks属性来确认消息的生产，0表示不进行消息接收是否成功的确认，发生网络抖动消息丢了，生产者不校验ACK自然就不知道丢了。1表示当Leader接收成功时确认，只要Leader存活就可以保证不丢失，保证了吞吐量，但是如果leader挂了，恰好选了一个没有ACK的follower，那也丢了。-1或者all表示Leader和Follower都接收成功时确认，可以最大限度保证消息不丢失，但是吞吐量低，降低了kafka的性能。一般在不涉及金额的情况下，均衡考虑可以使用1，保证消息的发送和性能的一个平衡。Kafka Broker 消息同步和持久化：Kafka通过多分区多副本机制，可以最大限度保证数据不会丢失，如果数据已经写入系统缓存中，但是还没来得及刷入磁盘，这个时候机器宕机，或者没电了，那就丢消息了，当然这种情况很极端。Kafka Broker 将消息传递给消费者：如果消费这边配置的是自动提交，万一消费到数据还没处理完，就自动提交offset了，但是此时消费者直接宕机了，未处理完的数据丢失了，下次也消费不到了。所以为了避免这种情况，需要将配置改为，先消费处理数据，然后手动提交，这样消息处理失败，也不会提交成功，没有丢消息。
rabbitmq整个消息投递的路径是producer—>rabbitmq broker—>exchange—>queue—>consumer。<