消息中间件——MQ简介

一、 同步存在的问题

1、产生问题

• 异步请求，无需等待
• 解决同步请求阻塞、超时问题
• 数据不一致性，重试失败记录到日志表

2、解决方法

• 同步可能网络延时，造成重复提交（token+redis可以解决）、
• 数据不一致问题，采用日志表存储+定时job对数据进行健康检查，不能实时更新。
• 图像验证（解决机器暴力扫描）

二、消息中间件解决问题

• 为啥使用
• 解决高并发，异步流量削峰
• 两种通信方式：点对点、发布订阅
• 异步通信，系统解耦

1、点对点通信

消息队列、生产者、消费者

2、缺点

• 可用性降低：在加入MQ之前，你不用考虑MQ服务器挂掉的情况，引入MQ之后你就需要去考虑了，可用性降低。

• 复杂性提高：加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等问题。因此需要考虑的东西更多，系统复杂性增大。

• 数据一致性：消息队列带来的异步确实可以提高系统响应速度，但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了。

2.1 可用性

引入消息队列后，系统的可用性下降。实际项目中发送MQ消息，如果不做集群，其中mq机器出了故障宕机了，那么mq消息就不能发送了，系统就崩溃了，所以我们需要集群MQ，当其中一台MQ出了故障，其余的MQ机器可以接着继续运转

2.2 复杂性

1.如何保证消息不被重复消费呢？

• 如果消息是做数据库的插入操作，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
• 如果你拿到这个消息做redis的set的操作，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
• 如果上面两种情况还不行，准备一个第三服务方来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。

2.如何保证消息的可靠性传输呢？

其实这个问题是第一个问题的扩展，换而言之，我们要保证可靠性传输，其实就是保证防止生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据而已
其实这些问题早在中间件开发者已经考虑到了，也提供了一些可配置的文件给我们自行设定相关参数，消息队列一般都会持久化到磁盘这个不用担心，然后生产者数据丢失的话MQ的事务会回滚，可以尝试重新发送，消费者丢的的话一般都是采用了自动确认消息模式导致消费信息被删，只要修改为手动确认就行了，也就是说消费者消费完之后，调用一个MQ的确认方法就行了

3.如何保证从消息队列里拿到的数据按顺序执行？

通过算法，将需要保持先后顺序的消息放到同一个消息队列中，
然后只用一个消费者去消费该队列。

4.如何解决消息队列的延时以及过期失效问题？有几百万消息持续积压几小时，怎么解决？

这个问题是生产环境出现事故后的，考察你如何快速的解决问题，，消息队列的延迟和过期失效是消息队列的自我保护机制，目的是为了防止本身被挤爆，当然是可以关闭保护，比如当某个消息消费失败5次后，就把这个消息丢弃等，尽量不要关掉保护机制，那么问题来了，那些被丢弃的消息难道就不要了吗？其实并不是，我们可以针对该业务，查询出来将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把丢的数据给他补回来。

事前：考虑各种异常可能，对上下游系统做到不信任性，做好异常处理策略
事中：线上排查，故障处理，数据恢复
事后：针对故障点系统优化

三、JMS通信模型

异步客户端与服务端通讯

• 点对点通信

生产者、消费者、消息队列
只有单个消费者、即一对一

• 发布订阅

生产者-主题-消费者
多个消费者、一对多关系

四、mq使用场景

• 点对点提高效率
• 数据一致性
• 订单-库存系统