公司起名字大全免费测吉凶,电商网站建设关键词优化,网店怎么开起来,合肥高端网站建设公司重试机制
因为网络抖动等原因导致 RPC 调用失败#xff0c;这时候使用重试机制可以提高请求的最终成功率#xff0c;减少故障影响#xff0c;让系统运行更稳定。
重试简易实现方案
在重试的过程中#xff0c;为了能够在约定的时间内进行安全可靠地重试#xff0c;在每次…重试机制
因为网络抖动等原因导致 RPC 调用失败这时候使用重试机制可以提高请求的最终成功率减少故障影响让系统运行更稳定。
重试简易实现方案
在重试的过程中为了能够在约定的时间内进行安全可靠地重试在每次触发重试之前我们需要先判定下这个请求是否已经超时如果超时了会直接返回超时异常否则我们需要重置下这个请求的超时时间防止因多次重试导致这个请求的处理时间超过用户配置的超时时间从而影响到业务处理的耗时。在发起重试、负载均衡选择节点的时候我们应该去掉重试之前出现过问题的那个节点这样可以提高重试的成功率并且我们允许用户配置可重试异常的白名单这样可以让 RPC 框架的异常重试功能变得更加友好。
要点
1、确保业务是幂等性。防止多次重试导致业务 2、超时时间重置每次重试之前重置超时时间 3、故障机器剔除可以参考rocketmq中的故障延迟机制来剔除故障机器。通过故障延迟机制和维护故障列表faultItemTable来在随机选择的基础上选性能最优和未使用过的可靠Broker来发送信息若无则在faultItemTable中选择次优Broker来发送消息以此实现高性能可以有效地规避故障Borker。 ● 若开启故障延迟机制则在随机递增取模的基础上对已发送过请求的Broker做延迟规 避当当前Broker不在故障机器表faultItemTable中或存在但当前时间超过规避时限则判定Broker的队列可用。规避时限的设置是通过两个数组latencyMax和notAvailableDuration维护的当上次请求耗时时间latency超过latencyMax中的某个值则会在数组notAvailableDuration中选择对应的时间期限值进行规避因此当前请求时间-上次请求时间规避时限0则判定可用。 private long[] latencyMax {50L, 100L, 550L, 1000L, 2000L, 3000L, 15000L}; private long[] notAvailableDuration {0L, 0L, 30000L, 60000L, 120000L, 180000L, 600000L}; ● 多次轮训选择一个队列判断是否可用若有可用队列则直接返回可用队列。若无可用队列则从故障Broker列表中随机选择一个Broker若该Broker中有写队列则将该Broker和写队列信息写入消息队列MessageQueue中并返回。若无则从故障列表中剔除该结点真正从路由信息中剔除并随机从messageQueueList中选择一个队列来发送消息。 重试危害
重试有放大故障的风险。无限制的重试可以打高下游应用的负载导致其宕机无法提供正常服务。而且重试还会存在链路放大的效应。假设正常访问量是 n链路一共有 m 层每层重试次数为 r则最后一层受到的访问量最大为 n * r ^ (m - 1) 。这种指数放大的效应很可怕可能导致链路上多层都被打挂整个系统雪崩。
退避策略
对于一些暂时性的错误如网络抖动等可能立即重试还是会失败通常等待一小会儿再重试的话成功率会较高并且也可能打散上游重试的时间较少因为同时都重试而导致的下游瞬间流量高峰。决定等待多久之后再重试的方法叫做退避策略我们实现了常见的退避策略如 线性退避每次等待固定时间后重试。 随机退避在一定范围内随机等待一个时间后重试。 指数退避连续重试时每次等待时间都是前一次的倍数。
重试机制控制方案
1、单点重试限制滑动时间窗口方式对于同一个资源请求通过计算时间窗口内的成功率来限制上游是否允许重试。 2、限制链路重试1响应包中设置retry_flag来通知上游是否可以进行重试。2返回业务码告知上游是否可以进行重试入侵性强
参考https://www.infoq.cn/article/5fboevkal0gvgvgeac4z https://time.geekbang.org/column/article/211261
