避免轮询活动任务时发生延迟
GetActivityTask API 设计为仅提供一次 taskToken。如果在通过活动工作线程通信时 taskToken 被丢弃，大量 GetActivityTask 请求可能会被阻止 60 秒以等待响应，直至 GetActivityTask 超时。如果只有少量轮询等待响应，则可能所有请求都会排在被阻止的请求之后，无法处理。但是，如果每个活动 ARN 都有大量未完成轮询，某个百分比的请求需要等待，不过更多的请求仍然可以获取
taskToken 并开始处理工作。
对于生产系统，建议每个活动 ARN 在每个时间点至少有 100 个轮询。如果一个轮询被阻止，其后有一部分轮询排队，在 GetActivityTask 请求被阻止时，仍然有更多请求将获得 taskToken 可以处理工作。
避免在轮询任务时出现这类延迟问题：
-
在活动工作线程实现的工作之外通过单独的线程实现轮询器。
-
每个活动 ARN 在每个时间点至少有 100 个轮询。
注意
每个 ARN 都扩展到 100 个轮询会比较昂贵。例如，每个 ARN 100 个 Lambda 函数轮询比具有 100 个轮询线程的单个 Lambda 函数贵 100 倍。要降低延迟并 最大限度减少成本，请使用具有异步 I/O 的语言，并且每个工作线程实施多个轮询线程。有关轮询器线程独立于工作线程的示例活动工作线程，请参阅使用 Ruby 编写的示例活动工作线程。
有关活动和活动工作线程的更多信息，请参阅活动。