消息队列笔记

1 消息队列的使用场景

参考文章：《消息队列的使用场景是怎样的？》

当业务体量很小，很多时候单机服务器都能全部搞定了，但是随着后面业务体量不断扩大，就会采用 微服务的设计思想，分布式的部署方式。
而此时拆分了很多的服务，随着体量的增加以及业务场景越来越复杂了，而 消息队列中间件 就能降低这些复杂度。
谈到消息队列，就需要想到以下几个概念：

• 异步
• 削峰
• 解耦
• 条件反射

1.1 异步

在简单的业务场景下，多个逻辑步骤都在一个流程中做完。
比如下单系统，简单的场景下，用户下单，然后付钱，流程就走完。
但后来需要添加一个优惠券系统，流程走完这个优惠券逻辑，可能需要耗时100毫秒，再后来需要加入一个积分系统，此时可能有需要额外耗时100毫秒，再后来。。。

而随着下单流程节点的逐渐增多，用户一个下单可能要耗费数十秒时间，此时就需要对系统进行优化，而异步策略就是一个很好的方法。
而使用线程可以实现到异步效果，但使用线程的弊端就是每当需要添加一个流程节点，就需要在源代码的基础上添加新的接口，然后重新发布系统；而且太过于耦合，流程里面随便一个地方出问题搞不好会影响到其他的点。
而此时使用消息队列，一切问题就迎刃而解了。使用了消息队列后的逻辑流程就是：
如下图，下单了，主下单系统发送下单消息给其它系统，而且接受到消息的系统执行自己对应的逻辑，一旦那后面还需要接入其它系统，只需订阅主下单系统发送的下单消息即可。

1.2 削峰

在应对超负荷的流量涌入的时候，比如说秒杀活动，使用消息队列能够达到流量削峰的效果，把用户的请求放到队列里面，然后每秒消费多少请求，就看自己的服务器处理能力，这样可能会比正常的慢一点，但是不至于导致服务器宕机，等流量高峰下去了，你的服务也就没压力了。

2 消息队列的问题

数据的一致性 是 分布式服务 本身就需要注意的一个问题，但是使用了消息队列这个问题会暴露得比较严重一点。使用消息队列需要注意一下几个问题：

• 消息重复消费
• 消息丢失
• 消息的顺序消费

2.1 消息重复消费

消息队列中都是有 重试机制，意思就是下游的业务发生异常了，下游会抛出异常并且要求主系统重新发一次消息。问题就在于此时，监听这条消息不仅仅只有发生了异常的下游业务系统，还有正常运行的下游业务系统，它们在第一次消息发送的时候就已经成功地执行了一次逻辑，此时监听到第二次消息后，会不会对对应的数据造成重复的读写操作，此时该接口是一个 幂等接口。

幂等 idempotent 是一个数学与计算机学概念，常见于抽象代数中。
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
例如，setTrue() 函数就是一个幂等函数，无论多次执行，其结果都是一样的。更复杂的操作幂等保证是利用唯一交易号(流水号)实现。

而如何保证实现幂等接口呢？这里又要引入两个概念 强校验 和 弱校验。

• 强校验：

比如你监听到用户支付成功的消息，你监听到了去加优惠券，那加优惠券接口下面再调用一个加流水（如：将 订单号+业务场景 这样的唯一标识信息添加到 流水表 中）的接口，两个放在 同一个事务，成功一起成功失败一起失败。
此后，每次消息过来都要拿着这样的唯一标识去流水表查，看看有没有这条流水，有就直接 return 不要走下面的流程了，没有就执行后面的逻辑。

• 弱校验：

与强校验的区别就在于流水号信息无需添加到实体表中，可能添加到 Redis 中，丢失了丢失了，真的需要重新执行逻辑也无关要紧。

重要的场景一定要强校验，真正查问题的时候没有在磁盘持久化的数据，心里还是空空的，就像你和女朋友分开的时候的心里状态一样