Go微服务: 分布式之通过本地消息实现最终一致性和最大努力通知方案

Go微服务: 分布式之通过本地消息实现最终一致性和最大努力通知方案

引用

CSDN

1.

https://blog.csdn.net/Tyro_java/article/details/139538856

通过本地消息实现最终一致性

1. 概述

• 我们的业务场景是可以允许我们一段时间有不一致的消息的状态的，并没有说必须特别高的这个消息的一致性
• 比如说在TCC这个架构中，如果采用了消息的最终一致性，整体架构设计要轻松好多
• 即便我们库存服务挂了，或者我们积分服务挂了也没有关系，只要我们有中间的这个消息，那就是没有问题的
• 因为你在消息消费中，如果你你没有消费成功，那么消息就会一直存在在这个消息队列里

2. 场景
   

• 看看这个我们的这个具体的案例的场景是什么样的？还是以这个订单服务和库存服务，还有积分服务为例
• 比如说，现在要下个订单，直接就在订单服务里，把它搞定了，我们就正常下订单
• 建立我们的订单表和我们的订单产品表，然后，这时候发送一条消息到这个消息队列里
• 那么我们说这个如果我们发送失败了，我们本地这个订单服务也能感知到，它就进行回滚就可以了
• 但是我们说突然的这个停电，这个我们就没办法感知到了
• 另一种情况，说你发送这个成功了，比如说我们建这个订单单服务，然后订单生成了订单产品表，也生成了, 消息发送也成功了
• 但是消息队列给我回消息的时候，由于网络的拥塞或者是抖动，这都很正常
• 然后，我们这个订单服务，肯定是要有超时机制的，它就超时了，订单就要回滚
• 但是这个这个消息队列是消息，可是真的到消息队列里存在了
• 那我下游的就库存，还有积分服务就拿着这个消息去做自己的业务了，该扣减库存就扣减库存，该增加积分就增加积分
• 但是，这个时候订单已经回滚了，那老板或者业务就会问了，这订单都没有了，你这个库存的积分增加是个什么意思
• 那我们要怎么解决这个问题呢？
• 那我们就是在我们这个订单服务增加订单的时候，我们不先去给他发这个消息
• 我们是先在本地表里头建立一个消息发送这个各种情况的一张表
• 比如说, 我这个订单服务，我建立了一条消息，但是这个消息没有返回来
• 有没有返回来也没有关系，这个表里已经记录了，说可以定一种状态，说就是未发送成功
• 我们这里这个本地消息表，就以发送成功的这个状态为准
• 只要是你能记录到这个表里的，没有发送成功的，我们就把它这个状态记录上
• 我们下次启动的时候，在这个订单服务里增加一个循环的这种定时任务
• 我们一般是做成异步的，因为你要是同步的话，相当于本地的这个数据库也是也有造成一定的压力的
• 我们就扫描这个之前没有发送成功的这个消息，那就是说直到我们这个定时任务，一直发送这个消息队列发送成功为止
• 所以他一定是能达到最终一致性的，我们这个里面就有一个问题，说你没发送成功，我记录一条可以没问题
• 那我下次一发送这个消息队列就成功了, 我回写消息本地这个表就记录了这条消息成功
• 如果，遇到我们的这个库存服务了，或者积分服务挂了都没有问题
• 因为你不消费消息队列里的这个消息，你就不会确认，你不会确认的这个消息就永远在消息队列里，这个就没有问题
• 但是还有一种情况，比如我这个消息，可能发很多次都有问题，可能是消息队列问题或者网络等问题
• 这样，重复发送就带来一个风险，比如下游如果重复消费怎么办？这个就是我们下游服务要解决的问题
• 本地消息的最终一致性，比TCC要简单很多，但是在某些高并发的场景，它也是有自己的问题的
• 如果一切正常，就发送，让消息队列让消费者去消费就可以了
• 如果有问题，就建立一张本地的这个消息发送表，记录各种情况，它最后能保证我们消息的最终一致性，但是要解决重复消费消息的这种情况

最大努力通知方案

• 我们想投递一个消息的时候，一定要想方设法投递给对方，就是最大努力通知方案
• 在生活中，你买了这个货物，商家是一定要给你发货的，但是你今天不在家，明天也不在家
• 这个快递小哥是不是一直给你投递，直到你在家为止，收到快递或指定存放地点或触发退回机制
• 在计算机当中，就是说这个消息一定要投递给你
  
• 在商场购物的支付系统中，无论是，银联或微信，支付宝选一个
• 小明在点击付款之后，他就会跳转到这个相应的这个第三方支付的页面
• 支付成功之后，支付系统就要发送一个通知给我们的商户，比如小A
• 对于这个小商户来说，它的网络是否稳定？对于支付机构来说是不确定的
• 目前支付系统已经入账，但是小A仍未收到通知，支付系统就会一直通知你
• 直到你告诉我，你确认了这个消息收到了，但是频繁调用对支付系统是一种无用的负担
• 如果商户一直掉线，无疑会造成巨大的资源浪费，支付系统的策略可能是
• 第一次是1s间隔，第二次是五s间隔, 第三次是15s间隔, …
• 随着时间的拉长，通知的频率越来越低，这样缓解了支付系统的压力
• 商家是有多个的，如果一直这么调用也不是办法，我们可以设置一个上限比如，调50次
• 那么50次之后，还不通，那我就不调了，那商家的钱就放在了这个支付系统里
• 如果商家的系统修复了，但是支付系统已通知到了上限，即超额了50次，这种场景下
• 支付系统提供一个接口，让商家自己来查询，这就是最大努力通知方案
• 它应用在，需要反复和对方确认的系统上