好的做外贸的网站,襟鼎高级服装定制,企业163邮箱登录入口,网站建设整个流程接口重试策略如何设计#xff1f;
常见的重试策略有两种#xff1a;
固定间隔时间重试#xff1a;实现简单、但是可能导致重试过于频繁或稀疏#xff0c;从而影响系统性能。如果重试间隔太短#xff0c;可能导致雪崩效应#xff1b;如果太长#xff0c;可能影响用户体…接口重试策略如何设计
常见的重试策略有两种
固定间隔时间重试实现简单、但是可能导致重试过于频繁或稀疏从而影响系统性能。如果重试间隔太短可能导致雪崩效应如果太长可能影响用户体验梯度间隔重试根据重试次数去延长重试间隔时间。例如第一次重试间隔1s第二次2s第三次4s。能有效提高重试的几率也能通过梯度增加间隔时间来避免对下游系统造成更大压力。此种策略需要设置合理的上下限值否则可能导致延长时间过长。
重试策略对分布式系统来说是自私的客户端认为他的消息很重要并要求服务端花费更多资源来处理盲目的重试设计不可取。
重试策略最佳实践
合理设置消费的最大超时时间和次数尽快向客户端返回成功或失败不要以超时或者异常抛出来代替消费失败重试会导致相同的消息进行重复消费消费方应该有一个良好的幂等设计
支付系统中补单操作如何完成https://mp.weixin.qq.com/s/9Z-N3cfWu7oMVJsTDkbb-Q
简单来讲补单利用 RocketMQ 对操作失败进行补偿操作但不能一直进行补偿操作需要设置一个最大重试次数在多次补偿失败之后需要延缓补偿频率这些都通过 RocketMQ 进行实现这里还存在几个问题
如果异常消息发送失败上游没有重试机制这笔订单就会卡住因为系统并不知道需要去补偿在补偿消息时失败如果重试达到最大次数仍然没有成功该如何处理
针对问题1可以将异常消息落库存在异常消息表中记录订单号、当前重试次数、一场分类、记录状态、消息体等字段设置定时任务去扫描该表进行处理。对当前 MQ 的可用性异常数据很少出现。
针对问题2如果补偿失败会向上抛出 error利用 RocketMQ 的梯度重试机制当消费次数上限后会进入死信队列。这种情况一般是网络出现问题恢复之后可以从死信队列拉取这些消息再统一处理。如果 MQ 和 DB 都失败了为极端情况人工介入即可。
针对问题3如果达到最大次数仍然没有成功将他放入异常表。
还可以有一些在业务低峰期的兜底任务扫描业务表对未完成的订单进行补偿。兜底任务可能造成信息的短暂堆积影响线上补偿流程推进可以使用独立的队列隔离开。
