什么是生产端的可靠性投递?

  1. 保障消息的成功发出。
  2. 保障MQ节点的成功接收。
  3. 发送端收到MQ节点(Broker)确认应答。
  4. 完善的消息进行补偿机制。

互联网大厂的解决方案:

  • 消息落库,对消息状态进行打标。
  • 消息的延迟投递,做二次确认,回调检查。

1.生产端-可靠性投递:消息落库,对消息进行打标

  • Step1:业务数据落库(BIZ DB)(如订单数据),消息落库(MSG DB)。
  • Step2:分布式定时任务查询待发送消息发送至MQ Broker。
  • Step3:MQ Broker confirm 机制回调Producer Listener。
  • Step4:更新消息发送状态。
  • Step5:分布式定时任务查询发送失败(未被confirm)的消息。
  • Step6:重新发送发送失败的消息。
  • Step7:重复发送次数达到指定次数,不进行再次投递,人工接入处理。

该场景在高并发场景下是否合适?

2.生产端-可靠性投递:消息的延迟投递,做二次确认,回调检查

  • Step1:业务上游业务数据落库成功后,发送一条消息M1。
  • Step2:一定时间延迟后(延迟时间根据业务需求而定)发送一条延迟消息M2用于追溯M1(可在M1发送得同时发送至延迟队列中)。
  • Step3:业务下游接收M1消息之后,完成下游业务逻辑。
  • Step4:发送消息M3至MQ Broker(新的得队列)。
  • Step5:CallBack端监听M3消息,落入消息库。
  • Step6:同时CallBack监听延时到达得M2消息,与MSG DB 中的M3比对。若对比结果M3不存在,则消息补偿(重新发送M1消息)。此时下游业务端可能会消费重复消息(M3消息发送失败),因此需要保证幂等性。

改方案对比上述方案上游业务端减少一次数据库持久化,并发压力提高,补偿消息机制略差。

3.消费端幂等性保障

简单来说就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的。
我们可以借鉴数据库的乐观锁机制来举个例子

  • 首先为表添加一个版本字段version
  • 在执行更新操作前呢,会先去数据库查询这个version
  • 然后执行更新语句,以version作为条件,例如:
  • UPDATE T_REPS SET COUNT = COUNT -1,VERSION = VERSION + 1 WHERE VERSION = 1
  • 如果执行更新时有其他人先更新了这张表的数据,那么这个条件就不生效了,也就不会执行操作了,通过这种乐观锁的机制来保障幂等性。

3.1消费端-幂等性保障

什么情况下会出现重复消费?
当消费者消费完消息时,在给生产端返回ack时由于网络中断,导致生产端未收到确认信息,该条消息会重新发送并被消费者消费,但实际上该消费者已成功消费了该条消息,这就是重复消费问题。

业界主流的幂等性操作:

  • 唯一ID + 指纹码机制,利用数据库主键去重
  • 利用Redis的原子性去实现

唯一ID+指纹码机制:
唯一ID + 指纹码机制,利用数据库主键去重
SELECT COUNT(1) FROM T_ORDER WHERE ID = 唯一ID +指纹码
好处:实现简单
坏处:高并发下有数据库写入的性能瓶颈
解决方案:跟进ID进行分库分表进行算法路由
整个思路就是首先我们需要根据消息生成一个全局唯一的ID,然后还需要加上一个指纹码。这个指纹码它并不一定是系统去生成的,而是一些外部的规则或者内部的业务规则去拼接,它的目的就是为了保障这次操作是绝对唯一的。

将ID + 指纹码拼接好的值作为数据库主键,就可以进行去重了。即在消费消息前呢,先去数据库查询这条消息的指纹码标识是否存在,没有就执行insert操作,如果有就代表已经被消费了,就不需要管了。

对于高并发下的数据库性能瓶颈,可以跟进ID进行分库分表策略,采用一些路由算法去进行分压分流。应该保证ID通过这种算法,消息即使投递多次都落到同一个数据库分片上,这样就由单台数据库幂等变成多库的幂等。

利用Redis的原子性去实现:
我们都知道redis是单线程的,并且性能也非常好,提供了很多原子性的命令。比如可以使用 setnx 命令。

在接收到消息后将消息ID作为key执行 setnx 命令,如果执行成功就表示没有处理过这条消息,可以进行消费了,执行失败表示消息已经被消费了。

使用 redis 的原子性去实现主要需要考虑两个点

第一:我们是否要进行数据落库,如果落库的话,关键解决的问题是数据库和缓存如何做到原子性?
第二:如果不进行落库,那么都存储到缓存中,如何设置定时同步的策略(同步到关系型数据库)?缓存又如何做到数据可靠性保障呢
关于不落库,定时同步的策略,目前主流方案有两种,第一种为双缓存模式,异步写入到缓存中,也可以异步写到数据库,但是最终会有一个回调函数检查,这样能保障最终一致性,不能保证100%的实时性。第二种是定时同步,比如databus同步
来源:若汐缘
链接:https://www.jianshu.com/p/d8042d7f62e1

posted on 2020-05-19 21:01  whn051799  阅读(820)  评论(0编辑  收藏  举报