3

该服务是一个remote session pool. 我需要请求一个会话以使用其他服务。在大多数情况下，这个池会有一个可用的会话，所以在 15 毫秒内我会有一个响应。但有时，它需要按需创建会话，最多需要 800 毫秒来创建它。

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

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

  2. 设置 800 毫秒超时，并保持连接到服务，直到我可以使用会话。

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

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

4

1 回答 1

1

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

临

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

缺点

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

2. 设置 800 毫秒超时，并保持连接到服务，直到我可以使用会话。

临

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

缺点

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

-

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

PS：如果您需要为不同的客户创建解决方案，也许值得创建一个更复杂的协议，例如：

// 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  

...

如何使用它取决于客户。

并且根据会话创建延迟差异，将超时参数过大一些安全的百​​分比。

于 2013-10-16T00:08:01.537 回答