消息中间件MQ

消息中间件：(kafka，rocketmq，activemq，rabbitmq)，与传统的传输方式有什么不一样的地方？

1. 问题一：异步，无需等待的。是怎么实现的?存在队列里面的。
2. 问题二：发送请求，调用别人接口的时候，返回的是同步的还是异步的？

• 答：有两个项目，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宕机的时候，我们整个的请求都要做补偿的机制了。这时候消息中间件来了。

什么是消息中间件？什么是队列？

消息中间件：客户端与服务器端进行异步通讯。有两种通讯方式，点对点，发布订阅。

队列：队列就是一个存放消息地址的一个容器。

为什么使用消息中间件？高并发，有两种通讯方式 ，点对点，发布订阅，异步通讯(无需等待）

1. 消息队列的作用：

   • 生产者：主要向队列发送消息。
   • 消费者：主要从队列获取消息。

2. 生产者向队列发送消息，如果消费者不在，会进行缓存。队列可以做持久化的。

3. 消费者从队列中获取到消息后，会消费，消费后消息直接清除。

4. 为什么mq可以解决高并发的问题。
   答：假设生产者向队列中产生高并发流量，消费者会不会挂？不会，mq会进行缓存，进行排队。先将一部分消费，另外的先缓存起来，慢慢消费。

5. 消费消息的过程中，消费者抛异常了，消息还会在吗？

   • 这时候，JMS保证消息的一致性可靠性，重试机制。
   • Java的jms是什么？Java发送消息，客户端与服务端进行异步通讯的方式。
   • jms可靠消息：如果是activemq，默认是自动签收。1. 消费者自动签收消息，这种情况不好，没有事务，没有补偿。2.消费者事务消息，消费者没有提交事务，默认表示没有进行消费，默认自动重试机制。3. 手动签收，没有手动签收，默认没有消费。
   • 怎么保证消息中间件的幂等性问题，核心就是通过全局的ID去进行

6. 消息模型：点对点，发布订阅

   1. 点对点的通讯方式(只允许一个消费者)：生产者----------》消息队列——-----》消费者
   2. 发布订阅(允许多个消费者)：生产者------------》主题----------》消费者

7. 同步过程：注册服务要5秒，发送短信要耗时5秒，发送邮件要耗时5秒，微信推送要耗时5秒。总共耗时要20秒，可以用多线程解决，每个是一个线程。

8. 异步过程：注册要5秒，短信队列5秒，邮件队列5秒，微信队列5秒。总耗时才10秒。

9. 点对点通讯，提高程序的效率 。

使用MQ注意事项

• 消费者，获取到消息后，代码抛异常。怎么办？
  • activemq会默认重试机制，重试机制也要分场景，抛出jdbc连接异常，要保持默认重试机制。抛出数据类型转换异常，重试也没用，数据有问题，解决没解决好，还是会直接重试的，浪费时间。
• 总结:

1. 如果消费者抛出异常，默认自动重试，如果消费者代码需要发布版本进行解决问题，不要重试，我们可以采用日志记录+定时job健康检查+人工补偿。
2. 消息中间件保证幂等性问题，网络延迟，消费者没有及时签收的情况，mq会自动重试机制，造成重复消费。解决幂等性的问题。
   • 可以采用全局id进行区分消息。只要每个消息没有被消费，每个消息都有唯一id的，第二次消费，我们可以判断消息id是否存在，如果这个消息已经消费过了，我们立马给它手动签收，避免第三次重试。
   • 使用JMS可靠消息机制。

   项目实际的用处