本文主要是介绍Go微服务: 分布式之通过本地消息实现最终一致性和最大努力通知方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
通过本地消息实现最终一致性
1 ）概述
- 我们的业务场景是可以允许我们一段时间有不一致的消息的状态的，并没有说必须特别高的这个消息的一致性
- 比如说在TCC这个架构中，如果采用了消息的最终一致性，整体架构设计要轻松好多
- 即便我们库存服务挂了，或者我们积分服务挂了也没有关系，只要我们有中间的这个消息，那就是没有问题的
- 因为你在消息消费中，如果你你没有消费成功，那么消息就会一直存在在这个消息队列里
2 ）场景
- 看看这个我们的这个具体的案例的场景是什么样的？还是以这个订单服务和库存服务，还有积分服务为例
- 比如说，现在要下个订单，直接就在订单服务里，把它搞定了，我们就正常下订单
- 建立我们的订单表和我们的订单产品表，然后，这时候发送一条消息到这个消息队列里
- 那么我们说这个如果我们发送失败了，我们本地这个订单服务也能感知到，它就进行回滚就可以了
- 但是我们说突然的这个停电，这个我们就没办法感知到了
- 另一种情况，说你发送这个成功了，比如说我们建这个订单单服务，然后订单生成了订单产品表，也生成了, 消息发送也成功了
- 但是消息队列给我回消息的时候，由于网络的拥塞或者是抖动，这都很正常
- 然后，我们这个订单服务，肯定是要有超时机制的，它就超时了，订单就要回滚
- 但是这个这个消息队列是消息，可是真的到消息队列里存在了
- 那我下游的就库存，还有积分服务就拿着这个消息去做自己的业务了，该扣减库存就扣减库存，该增加积分就增加积分
- 但是，这个时候订单已经回滚了，那老板或者业务就会问了，这订单都没有了，你这个库存的积分增加是个什么意思
- 那我们要怎么解决这个问题呢？
- 那我们就是在我们这个订单服务增加订单的时候，我们不先去给他发这个消息
- 我们是先在本地表里头建立一个消息发送这个各种情况的一张表
- 比如说, 我这个订单服务，我建立了一条消息，但是这个消息没有返回来
- 有没有返回来也没有关系，这个表里已经记录了，说可以定一种状态，说就是未发送成功
- 我们这里这个本地消息表，就以发送成功的这个状态为准
- 只要是你能记录到这个表里的，没有发送成功的，我们就把它这个状态记录上
- 我们下次启动的时候，在这个订单服务里增加一个循环的这种定时任务
- 我们一般是做成异步的，因为你要是同步的话，相当于本地的这个数据库也是也有造成一定的压力的
- 我们就扫描这个之前没有发送成功的这个消息，那就是说直到我们这个定时任务，一直发送这个消息队列发送成功为止
- 所以他一定是能达到最终一致性的，我们这个里面就有一个问题，说你没发送成功，我记录一条可以没问题
- 那我下次一发送这个消息队列就成功了, 我回写消息本地这个表就记录了这条消息成功
- 如果，遇到我们的这个库存服务了，或者积分服务挂了都没有问题
- 因为你不消费消息队列里的这个消息，你就不会确认，你不会确认的这个消息就永远在消息队列里，这个就没有问题
- 但是还有一种情况，比如我这个消息，可能发很多次都有问题，可能是消息队列问题或者网络等问题
- 这样，重复发送就带来一个风险，比如下游如果重复消费怎么办？这个就是我们下游服务要解决的问题
- 本地消息的最终一致性，比TCC要简单很多，但是在某些高并发的场景，它也是有自己的问题的
- 如果一切正常，就发送，让消息队列让消费者去消费就可以了
- 如果有问题，就建立一张本地的这个消息发送表，记录各种情况，它最后能保证我们消息的最终一致性，但是要解决重复消费消息的这种情况
最大努力通知方案
- 我们想投递一个消息的时候，一定要想方设法投递给对方，就是最大努力通知方案
- 在生活中，你买了这个货物，商家是一定要给你发货的，但是你今天不在家，明天也不在家
- 这个快递小哥是不是一直给你投递，直到你在家为止，收到快递或指定存放地点或触发退回机制
- 在计算机当中，就是说这个消息一定要投递给你
- 在商场购物的支付系统中，无论是，银联或微信，支付宝选一个
- 小明在点击付款之后，他就会跳转到这个相应的这个第三方支付的页面
- 支付成功之后，支付系统就要发送一个通知给我们的商户，比如小A
- 对于这个小商户来说，它的网络是否稳定？对于支付机构来说是不确定的
- 目前支付系统已经入账，但是小A仍未收到通知，支付系统就会一直通知你
- 直到你告诉我，你确认了这个消息收到了，但是频繁调用对支付系统是一种无用的负担
- 如果商户一直掉线，无疑会造成巨大的资源浪费，支付系统的策略可能是
- 第一次是1s间隔，第二次是五s间隔, 第三次是15s间隔, …
- 随着时间的拉长，通知的频率越来越低，这样缓解了支付系统的压力
- 商家是有多个的，如果一直这么调用也不是办法，我们可以设置一个上限比如，调50次
- 那么50次之后，还不通，那我就不调了，那商家的钱就放在了这个支付系统里
- 如果商家的系统修复了，但是支付系统已通知到了上限，即超额了50次，这种场景下
- 支付系统提供一个接口，让商家自己来查询，这就是最大努力通知方案
- 它应用在，需要反复和对方确认的系统上
这篇关于Go微服务: 分布式之通过本地消息实现最终一致性和最大努力通知方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
