【问题标题】:GAE/P: Implementing Exponential backoff for RPC callsGAE/P:为 RPC 调用实现指数退避
【发布时间】:2016-08-23 11:57:56
【问题描述】:

我知道当 RPC 调用失败时,指数退避是一件好事。到目前为止,在我的 GAE/P 应用程序中,我已经使用任务队列实现了指数退避:

deferred.defer(function_that_makes_RPC_call)

如果执行 RPC 调用的函数引发异常,那么任务队列的指数退避会处理它,我不必担心。

然而,一个问题是 deferred.defer 本身就是一个可能失败的 RPC 调用!我有时会收到此错误:

DeadlineExceededError:API 调用 taskqueue.BulkAdd() 耗时过长 响应并被取消。

所以看来我不能再偷懒了,必须实现自己的指数退避。 :(

我正在考虑在 deferred.defer 周围放置一个包装器,以使用 backoff 实现指数退避,如下所示:

@backoff.on_exception(backoff.expo,
                      (exception1, exception2, ...),
                      max_tries=8)
def defer_wrapper(function_that_makes_RPC_call):
    deferred.defer(function_that_makes_RPC_call)

这里,装饰器实现了在引发枚举异常(例如,异常 1、异常 2、...)之一时发生重试的回退。

关于这个的几个问题:

  1. 这是实现指数退避的好解决方案吗?
  2. 我需要列出哪些例外情况?除了 DeadlineExceededError 之外还有什么?

我知道有自己的指数退避然后提交到任务队列有点多余,但我认为deferred.defer 应该比其他 RPC 调用更容易失败,我想响应请求尽快。

【问题讨论】:

    标签: python google-app-engine rpc


    【解决方案1】:

    特别是对于 DeadlineExceededError 在尝试将延迟任务排入队列时,我只需要进行 back2back 重试,而不是使用指数退避 - 由于截止日期间隔到期本身,尝试将间隔 5 秒,这给出了在请求本身到达截止日期之前最多重试 12 次。

    不过,对于其他类型的故障来说,这可能是个好主意。

    【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-12-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多