api - 我应该为外部服务设置哪个超时？

Question

此服务是一个远程 session 池。我需要请求一个 session 才能与其他服务一起工作。在大多数情况下，此池将有可用的 session ，因此在 15 毫秒内我将收到响应。但有时，它需要按需创建 session ，最多需要 800 毫秒才能创建它。

我有两种选择来处理这种情况:

1. 设置 15 毫秒的超时，并实现重试策略，直到 800 毫秒为止呈指数回退。无论我是否连接到该服务，它都会创建所需的 session 。

2. 设置 800 毫秒的超时，并保持与服务的连接，直到我有可用的 session 。

在这两种情况下，都不能保证我会在 800 毫秒后进行 session 。

所以问题是:每个选项的优缺点是什么？

Answer 1

1 . To set a 15ms timeout, and to implement a retry policy up with an exponential back off until 800ms. This service will create the required session no matter whether I am connected to it.

专业版

1. 检测到 session 无法立即使用，几乎不需要为此等待一秒钟。
2. 由客户再次请求 session 或通过其他方式进行，您可以更灵活地处理不同的用例。
3. 您可以区分每次回退策略继续时等待 session 超过 15 毫秒报告的不良事件，这对于异常 session 池行为检测很有用。

缺点

1. 由于回退行为，代码更加复杂。
2. 由于不同的超时而使用多个参数。

2 . To set a 800ms timeout, and to keep connected to the service until a session is available for me.

专业版

1. 实现简单直接
2. 简单的参数化

缺点

1. 您无法从 session 池中注意到 session 创建事件的延迟。这对于跟踪和诊断很重要，这种简单的方法可以隐藏 session 池问题。
2. 不能针对不同的客户用例灵活实现。

-

我认为决策驱动因素是您是否需要恰好适用于此用例的解决方案，或者此方法是否将用于不同的客户和用例。

---

PS:如果你需要为不同的客户创建一个解决方案，那么创建一个更复杂的协议(protocol)可能是值得的，比如:

// just takes a session if available, no more than 15msec delay expected
get_session(...)  : session 

// if not available, creates one
get_session_or_create(...) : session 

available_sessions(...) : int

//  between 0 and 1, the proportion of available sessions
availability(...) : double  

...

如何使用由客户决定。

根据 session 创建延迟差异，将超时参数的尺寸增加一些安全百分比。