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