ToB企服应用市场:ToB评测及商务社交产业平台

标题: Go微服务: 分布式之通过本地消息实现最终划一性和最大努力关照方案 [打印本页]

作者: 王海鱼 时间: 2024-6-11 11:43
标题: Go微服务: 分布式之通过本地消息实现最终划一性和最大努力关照方案
通过本地消息实现最终划一性

1 ）概述

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

2 ）场景

看看这个我们的这个详细的案例的场景是什么样的？照旧以这个订单服务和库存服务，另有积分服务为例
好比说，现在要下个订单，直接就在订单服务里，把它搞定了，我们就正常下订单
建立我们的订单表和我们的订单产物表，然后，这时间发送一条消息到这个消息队列里
那么我们说这个假如我们发送失败了，我们本地这个订单服务也能感知到，它就进行回滚就可以了
但是我们说突然的这个停电，这个我们就没办法感知到了
另一种情况，说你发送这个乐成了，好比说我们建这个订单单服务，然后订单天生了订单产物表，也天生了, 消息发送也乐成了
但是消息队列给我回消息的时间，由于网络的拥塞或者是抖动，这都很正常
然后，我们这个订单服务，肯定是要有超时机制的，它就超时了，订单就要回滚
但是这个这个消息队列是消息，但是真的到消息队列里存在了
那我下游的就库存，另有积分服务就拿着这个消息去做自己的业务了，该扣减库存就扣减库存，该增长积分就增长积分
但是，这个时间订单已经回滚了，那老板或者业务就会问了，这订单都没有了，你这个库存的积分增长是个什么意思
那我们要怎么解决这个题目呢？

那我们就是在我们这个订单服务增长订单的时间，我们不先去给他发这个消息
我们是先在本地表里头建立一个消息发送这个各种情况的一张表
好比说, 我这个订单服务，我建立了一条消息，但是这个消息没有返返来
有没有返返来也没有关系，这个表里已经记录了，说可以定一种状态，说就是未发送乐成
我们这里这个本地消息表，就以发送乐成的这个状态为准
只要是你能记录到这个表里的，没有发送乐成的，我们就把它这个状态记录上
我们下次启动的时间，在这个订单服务里增长一个循环的这种定时任务
我们一般是做成异步的，因为你要是同步的话，相当于本地的这个数据库也是也有造成肯定的压力的
我们就扫描这个之前没有发送乐成的这个消息，那就是说直到我们这个定时任务，不停发送这个消息队列发送乐成为止
所以他肯定是能到达最终划一性的，我们这个里面就有一个题目，说你没发送乐成，我记录一条可以没题目
那我下次一发送这个消息队列就乐成了, 我回写消息本地这个表就记录了这条消息乐成
假如，遇到我们的这个库存服务了，或者积分服务挂了都没有题目
因为你不消耗消息队列里的这个消息，你就不会确认，你不会确认的这个消息就永远在消息队列里，这个就没有题目
但是另有一种情况，好比我这个消息，可能发很多次都有题目，可能是消息队列题目或者网络等题目
这样，重复发送就带来一个风险，好比下游假如重复消耗怎么办？这个就是我们下游服务要解决的题目
本地消息的最终划一性，比TCC要简朴很多，但是在某些高并发的场景，它也是有自己的题目的
假如一切正常，就发送，让消息队列让消耗者去消耗就可以了
假如有题目，就建立一张本地的这个消息发送表，记录各种情况，它最后能保证我们消息的最终划一性，但是要解决重复消耗消息的这种情况

最大努力关照方案

我们想投递一个消息的时间，肯定要费尽心机投递给对方，就是最大努力关照方案
在生存中，你买了这个货品，商家是肯定要给你发货的，但是你今天不在家，明天也不在家
这个快递小哥是不是不停给你投递，直到你在家为止，收到快递或指定存放地点或触发退回机制
在盘算机当中，就是说这个消息肯定要投递给你

在商场购物的付出系统中，无论是，银联或微信，付出宝选一个
小明在点击付款之后，他就会跳转到这个相应的这个第三方付出的页面
付出乐成之后，付出系统就要发送一个关照给我们的商户，好比小A
对于这个小商户来说，它的网络是否稳定？对于付出机构来说是不确定的
现在付出系统已经入账，但是小A仍未收到关照，付出系统就会不停关照你
直到你告诉我，你确认了这个消息收到了，但是频仍调用对付出系统是一种无用的负担
假如商户不停掉线，无疑会造成巨大的资源浪费，付出系统的计谋可能是
第一次是1s间隔，第二次是五s间隔, 第三次是15s间隔, …
随着时间的拉长，关照的频率越来越低，这样缓解了付出系统的压力
商家是有多个的，假如不停这么调用也不是办法，我们可以设置一个上限好比，调50次
那么50次之后，还不通，那我就不调了，那商家的钱就放在了这个付出系统里
假如商家的系统修复了，但是付出系统已关照到了上限，即超额了50次，这种场景下
付出系统提供一个接口，让商家自己来查询，这就是最大努力关照方案
它应用在，必要反复和对方确认的系统上

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)