流水模式算法问题

[数据的流]

使用的EF框架，现在有一表订单表，需要对没有核对的订单进行核对，核对字段check_status（0未核对，1核对成功，2核对失败），因为系统是正在使用中的，未核对的订单数量是在不停增加的，核对以后check_status更新为1或2，现在需要做一个定时的核对订单的算法，比如每隔半小时核对一次，求教思路

[数据的流]

引用 7 楼 xuzuning 的回复:

奇怪的需求！ 如果核对是机器完成的，那么在入库时就应完成。无需积累到一定数量再批量完成 如果核对是人工完成的，那么就不可能是定时任务

需求并不奇怪，订单数据提交时候是提交到2个地方的，本地数据库提交、远程接口提交。这个就有核对的需要了

[数据的流]

引用 5 楼 wuyajungogo 的回复:

[quote=引用 3 楼 xiaoguidangjiajia 的回复:] windows servers

我之前也有定时处理任务的项目，也是用得Windows Service。主要是省心，机子启动随着启动，不怕宕机或者异常导致定时任务失败[/quote] winservices确实比较好用，考虑的就是这个，因为是需要定时跑的。不过我现在的问题是怎么去写这个定时的算法，订单库，入口是未核对的订单不停在生成，出口是将核对过的订单状态修改为“已核对”，订单库中找不到需要核对的订单时本次核对结束，等待下一次定时器触发

[数据的流]

引用 6 楼 sp1234 的回复:

如果你要做的仅是一个定时启动的小程序，每一次启动进程时都初始化最干净的启动环境（而不是那种运行很长时间，可能造成内存泄漏甚至逻辑崩溃的程序），那么就应该依据 windows 计划任务的方式来执行。 这是 windows 计划任务跟windows service 的区别。 比如说 windows 的自动更新程序，当判断需要下载和更新新的组件时，它就会自动地每隔1分钟就启动一次，直到所有的更新任务都完成。这样当更新中任何意外的失败、崩溃，在下一分钟还是会重新启动更新进程。这就是它正确地选择了“计划任务”程序模式，而不是windows service方式。

没有这么复杂的，就是一个每天都需要跑的，间隔半个小时的程序。用for蒙逼了思路有点乱，在考虑用递归解决

[娃都会打酱油了]

sql作业，或者quartz.net作业式框架

[数据的流]

引用 1 楼 starfd 的回复:

sql作业，或者quartz.net作业式框架

sql作业单独是搞不定的，订单中的状态，需要和web服务接口请求的返回值进行对比

[小鬼当家家]

windows servers

[以专业开发人员为伍]

如果是一个独立的计划任务小程序，那么应该编写为console程序。

[一枚大帅哥]

引用 3 楼 xiaoguidangjiajia 的回复:

windows servers

我之前也有定时处理任务的项目，也是用得Windows Service。主要是省心，机子启动随着启动，不怕宕机或者异常导致定时任务失败

[xuzuning]

奇怪的需求！ 如果核对是机器完成的，那么在入库时就应完成。无需积累到一定数量再批量完成 如果核对是人工完成的，那么就不可能是定时任务

[以专业开发人员为伍]

如果你要做的仅是一个定时启动的小程序，每一次启动进程时都初始化最干净的启动环境（而不是那种运行很长时间，可能造成内存泄漏甚至逻辑崩溃的程序），那么就应该依据 windows 计划任务的方式来执行。 这是 windows 计划任务跟windows service 的区别。 比如说 windows 的自动更新程序，当判断需要下载和更新新的组件时，它就会自动地每隔1分钟就启动一次，直到所有的更新任务都完成。这样当更新中任何意外的失败、崩溃，在下一分钟还是会重新启动更新进程。这就是它正确地选择了“计划任务”程序模式，而不是windows service方式。