消息中间件MQ
消息中间件：(kafka，rocketmq，activemq，rabbitmq)，与传统的传输方式有什么不一样的地方？
- 问题一：异步，无需等待的。是怎么实现的?存在队列里面的。
- 问题二：发送请求，调用别人接口的时候，返回的是同步的还是异步的？
- 答：有两个项目，A项目需要调用B项目的接口（API）。这时候又有一个问题(A调用B接口的时候，B接口有延迟，会产生什么的场景？会产生阻塞(为什么会产生阻塞?A会一直等待，等待B响应结果回来。))。请求与响应是一个同步请求的方式。
- 同步的请求的方式有什么缺点：
- 阻塞，超时。
- 网络延迟，可能产生重复提交(B接口还没有帮我们处理好，又有相同的请求过来，这时候就会出现重复提交。重复提交怎么解决呢？(采用token(令牌)+图像验证码，A拿着令牌调B接口，令牌只能在B接口操作一次))
- A调用B的时候，B可能挂了，A要重试，重试的时候，可能数据不一致。这时候又扯到了分布式事务的概念，在同步的情况下，怎么解决分布式事务(分场景，有些情况下，我们的同步接口采用的是Http协议的，怎么保证双方的数据的一致性？A调用B，如果B没有及时的响应，A默认有3次重试补偿的机制，将该信息存放在日志表(补偿表)，在使用定时job每天晚上健康检查数据，可以手动补偿提交，不是实时的。 )
- 总结：当我们使用同步接口的时候，请求与响应的过程必须要依赖响应回来的，我们才能往下进行处理，这是非常浪费时间的，当B宕机的时候，我们整个的请求都要做补偿的机制了。这时候消息中间件来了。
什么是消息中间件？什么是队列？
消息中间件：客户端与服务器端进行异步通讯。有两种通讯方式，点对点，发布订阅。
队列：队列就是一个存放消息地址的一个容器。
为什么使用消息中间件？高并发，有两种通讯方式 ，点对点，发布订阅，异步通讯(无需等待）
-
消息队列的作用：
- 生产者：主要向队列发送消息。
- 消费者：主要从队列获取消息。
-
生产者向队列发送消息，如果消费者不在，会进行缓存。队列可以做持久化的。
-
消费者从队列中获取到消息后，会消费，消费后消息直接清除。
-
为什么mq可以解决高并发的问题。
答：假设生产者向队列中产生高并发流量，消费者会不会挂？不会，mq会进行缓存，进行排队。先将一部分消费，另外的先缓存起来，慢慢消费。 -
消费消息的过程中，消费者抛异常了，消息还会在吗？
- 这时候，JMS保证消息的一致性可靠性，重试机制。
- Java的jms是什么？Java发送消息，客户端与服务端进行异步通讯的方式。
- jms可靠消息：如果是activemq，默认是自动签收。1. 消费者自动签收消息，这种情况不好，没有事务，没有补偿。2.消费者事务消息，消费者没有提交事务，默认表示没有进行消费，默认自动重试机制。3. 手动签收，没有手动签收，默认没有消费。
- 怎么保证消息中间件的幂等性问题，核心就是通过全局的ID去进行
-
消息模型：点对点，发布订阅
- 点对点的通讯方式(只允许一个消费者)：生产者----------》消息队列——-----》消费者
- 发布订阅(允许多个消费者)：生产者------------》主题----------》消费者
-
同步过程：注册服务要5秒，发送短信要耗时5秒，发送邮件要耗时5秒，微信推送要耗时5秒。总共耗时要20秒，可以用多线程解决，每个是一个线程。
-
异步过程：注册要5秒，短信队列5秒，邮件队列5秒，微信队列5秒。总耗时才10秒。
-
点对点通讯，提高程序的效率 。
使用MQ注意事项
- 消费者，获取到消息后，代码抛异常。怎么办？
- activemq会默认重试机制，重试机制也要分场景，抛出jdbc连接异常，要保持默认重试机制。抛出数据类型转换异常，重试也没用，数据有问题，解决没解决好，还是会直接重试的，浪费时间。
- 总结: