19
在大型站点上服务后台任务
我们正在处理StackOverflow上一个有趣的问题。 我们有一堆小的“需要尽快完成的任务”。一个示例是更新“相关问题”列表。过去我们所做的是将这些任务附加到某些用户的页面加载中。 这从来都不是理想的，但并不是很明显。现在，SO已经超过了1,000,000个问号，那些不幸的用户开始感觉到它。 自然的解决方案是将这些任务实际推入后台。我正在考虑有两种广泛的方法可以做到这一点。 1.在IIS中作为自定义线程池/工作队列 基本上，我们启动了几个（非ThreadPool，以便不干扰IIS）线程，并使它们服务于我们将Funcs推入的某些集合。 这里的最大优点是简单性。我们不必担心会封送任何东西，也不必确保某些外部服务正常运行并做出响应。 我们还可以访问所有通用代码。 缺点是，我们不应该使用后台线程。我知道的反对意见都集中在饥饿的IIS（如果使用ThreadPool）和线程随机死亡（由于AppPool回收）的问题上。 我们已经有了现有的基础架构来使随机线程死亡成为非问题（基本上可以放弃检测任务的可能性），并且限制线程数量（并使用非ThreadPool线程）也不难。 我是否在IIS进程线程池/工作队列中缺少其他任何反对意见？ 已移至StackOverflow，因为此处未真正解决。 2.作为服务 某些第三方解决方案或定制解决方案。 基本上，我们会将任务跨流程边界编组到某个服务，而不必理会它。大概我们是在某些代码中链接原始代码，或者将它们限制为原始SQL +连接字符串。 优点是这样做的“正确方法”。 缺点是我们要么只能做有限的工作，要么必须制定一些系统来使该服务与我们的代码库保持同步。我们还需要以某种方式挂钩所有监视和错误日志记录，这些都是通过“ In IIS”选项免费获得的。 服务方法还有其他好处或问题吗？ 简而言之，是否存在无法预见和无法克服的问题，从而使方法1变得不可行，如果是的话，我们是否应该寻求方法2的良好第三方服务？