任务调度架构问题 - C＃.net。
我需要从数据库中提取数据并通过XML发送结果。该过程还需要导入传入文件和生成相应的确认文件。该过程的高杠杆轮廓遵循以下步骤：
在传输文件X 5小时后，对 X 的确认文件进行投票。
如果在5小时内收到文件，则处理它。
如果在文件X 发送后60分钟内未收到确认X （X处理需要不同的时间才能运行），请发送电子邮件说'没收到文件'。
如果在文件X 发送后4个半小时内未收到确认X ，请发送一封电子邮件，说明“未收到文件”。
如果在发送 X 5小时后未收到确认X ，则拒绝确认。
对确认X 4小时后收到的文件Y 进行投票。
如果在4小时内收到文件Y ，则处理它（可以接收多个文件Y的修订副本进行处理）。同时为SFTP转移产生确认Y 文件。
如果在收到确认X 文件4小时后收到文件Y ，则发送确认Y 后回复说文件Y'太早'。同时为SFTP转移产品“太早确认Y 文件。
如果在收到确认X 文件4小时后收到文件Y ，则发送确认Y 后回复说文件Y'太晚了'。同时为SFTP转移产生'太晚'确认Y 文件。
如果收到确认X 后3个半小时未收到文件Y ，请发送一封电子邮件，说明“没有收到文件Y”。< / p>
对确认X 4小时后收到的文件Z 进行投票。
如果在4小时内收到文件Z 处理（可以接收文件Z的多个修订副本进行处理）。同时为SFTP转移产生确认Z 文件。
如果在收到确认Z 文件4小时后收到文件Z ，则发送确认Z 后回复说文件Z'太早了'。同时为SFTP转移产品“太早确认Z 文件。
如果在收到确认X 文件4小时后收到文件Z ，则发送确认Z 后回复说文件Z'太晚了'。同时为SFTP转移产品“太晚”确认Z 文件。
如果收到确认X 后3个半小时未收到文件Z ，请发送一封电子邮件，说明“没有收到Z档”。< / p>
主要问题：
由于处理不是静态时间，并且所有文件每天24小时都需要轮询，这对于架构来说是最好的方法。 Windows服务似乎是一个合理的解决方案，但还有更好的方法吗？通过Autosys编写脚本并调用可执行文件是否更好？
看看这种方法，[http://www.codeproject.com/Articles/832979/Windows-Services-in-Csharp-with-Timers-Jump-start][1]，从“背景”部分可以看出，Windows服务中的计时器并未受到欢迎？ （[http://weblogs.asp.net/jongalloway//428303][1]）
非常感谢。
答案 0 :(得分：0)
在Windows服务中使用Timer时，背景部分的那篇文章对我来说有点奇怪：
运行计时器的Windows服务需要自动运行，这意味着它将在您登录计算机之前启动并在计算机关闭之前一直运行。如果它们挂起或内存泄漏缓慢，它们将继续拖累系统，直到服务重新启动（或者它们使机器崩溃）。
好吧，如果有内存泄漏或者您的逻辑只是在特定时间点挂起，那么它与定时器或Windows服务无关，而是关于制作必须修复的错误的开发人员。所以我不能同意作者的计时器，但我同意有时最好使用任务计划程序来运行一个工作。任务计划程序已经有很多不错的功能，您可以轻松地为您的工作设置高级计算机，而您可能需要使用Windows服务重新编写自行车。
我无法确定您的情况最好是什么，因为我不知道解决方案的所有细节，但我认为可以同时使用任务计划程序和Windows服务。
任务计划程序：
1.创建控制台命令以创建文件X 并将其安排为每天22:00运行。例如，您应该将文件创建日期时间保存到数据库
2.再创建一个工作，每20秒运行一次，或者你的民意调查时间应该是多少。然后只需从数据库中读取 X文件创建日期时间并执行上面的检查。例如：检查 X 的确认文件是否存在，然后在创建X文件后经过不到5个小时处理它。如果该文件尚不存在，请检查是否已经过了60分钟并发送通知，依此类推。一项工作就足以放置您为所有文件描述的所有轮询逻辑。
Windows服务：
1.您可以添加计时器来创建文件X，但您必须自己实施计划，这就是为什么在这种情况下最好使用任务计划程序。
但是，使用Windows服务，您可以侦听文件系统事件而不是轮询。看看FileSystemWatcher课程。这可能非常简单，特别是如果文件名没有严格定义。在这种情况下，您只需订阅一个事件并仅处理新文件。如果您只是使用任务计划程序轮询，则必须保留文件系统文件夹状态以检查哪个文件是新文件。
因此，从我的问题中我知道，我只需要创建两个作业并使用任务计划程序将其缩小，但您的解决方案可能更复杂，任务计划程序可能无法满足您的所有要求，但我希望我能为您提供足够的信息以便您可以做出正确的选择。
希望它有所帮助！