课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
补偿机制是程序员在学习分布式开发的时候需要重点掌握的一个编程开发方法,而今天我们就一起来了解一下,补偿机制的应用表现都有哪些实现方法。
「回滚」
我们将回滚分为2种模式,一种叫「显式回滚」(调用逆向接口),一种叫「隐式回滚」(无需调用逆向接口)。
常见的就是「显式回滚」。这个方案无非就是做2个事情:
先要确定失败的步骤和状态,从而确定需要回滚的范围。一个业务的流程,往往在设计之初就制定好了,所以确定回滚的范围比较容易。但这里需要注意的一点就是:如果在一个业务处理中涉及到的服务并不是都提供了「回滚接口」,那么在编排服务时应该把提供「回滚接口」的服务放在前面,这样当后面的工作服务错误时还有机会「回滚」。
其次要能提供「回滚」操作使用到的业务数据。「回滚」时提供的数据越多,越有益于程序的健壮性。因为程序可以在收到「回滚」操作的时候可以做业务的检查,比如检查账户是否相等,金额是否一致等等。
由于这个中间状态的数据结构和数据大小并不固定,所以我们建议你在实现这点的时候可以将相关的数据序列化成一个json,然后存放到一个nosql类型的存储中。
「隐式回滚」相对来说运用场景比较少。它意味着这个回滚动作你不需要进行额外处理,下游服务内部有类似“预占”并且“超时失效”的机制的。例如:
电商场景中,会将订单中的商品先预占库存,等待用户在15分钟内支付。如果没有收到用户的支付,则释放库存。
下面聊聊可以有很多玩法,也更容易陷入坑里的「重试」。
「重试」
「重试」大的好处在于,业务系统可以不需要提供「逆向接口」,这是一个对长期开发成本特别大的利好,毕竟业务是天天在变的。所以,在可能的情况下,应该优先考虑使用「重试」。
不过,相比「回滚」来说「重试」的适用场景更少一些,所以我们一步先要判断,当前场景是否适合「重试」。比如:
下游系统返回「请求超时」、「被限流中」等临时状态的时候,我们可以考虑重试
而如果是返回“余额不足”、“无权限”等明确无法继续的业务性错误的时候就不需要重试了
一些中间件或者rpc框架中返回Http503、404等没有何时恢复的预期的时候,也不需要重试
如果确定要进行「重试」,我们还需要选定一个合适的「重试策略」。主流的「重试策略」主要是以下几种。
策略1.立即重试。有时故障是候暂时性,可能是因网络数据包冲突或硬件组件流量高峰等事件造成的。在此情况下,适合立即重试操作。不过,立即重试次数不应超过一次,如果立即重试失败,应改用其它的策略。
策略2.固定间隔。应用程序每次尝试的间隔时间相同。这个好理解,例如,固定每3秒重试操作。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。