我需要连续运行一些任务。这些任务主要包括从DB中检索特定的记录，分析并保存它们。这是一个重要的分析，可能需要几秒钟(可能超过一分钟)。我不知道新记录在DB中保存等待分析的频率(有另一个cronjob)。
我应该一个接一个地检索记录，在它完成后(递归地)再次调用相同的分析函数，并尝试保持cronjob运行，直到没有更多未分析的记录?还是应该在每次cronjob运行时检索固定数量的新记录，并每隔一定的时间调用cronjob ?
作业队列服务器可能适合此场景(例如，参见ActiveMQ或MemcacheQ)。与其将未分析的记录直接添加到数据库中，不如将它们发送到队列中进行处理。然后，您的cron作业可以从队列中检索一些项目进行处理，如果一个作业需要很长时间才能运行，则会再次触发cron作业，下一个作业将运行并获取队列中的下一个项目。
就我个人而言，我会让cron作业检索固定数量的记录进行处理，只是为了确保在新记录不断添加并且处理器无法跟上的情况下，您不会让脚本长时间卡住处理。最终它可能会完成所有事情，但你可能会陷入一种持续很长时间的情况。
您也可以考虑创建一个锁文件，以便作业可以查找任务处理器是否已经运行。例如，当cron作业启动时，检查文件是否存在(例如processor.lock)，如果存在，则退出，如果不存在，则创建该文件，处理一些记录，然后删除该文件。
希望对你有帮助。
或者我应该在每次cronjob运行时检索固定数量的新记录，并每隔一定的时间调用cronjob ?
。你必须先做一些试错度量来决定最优的fixed amount。
当然，这很大程度上取决于你实际在做什么，你同时运行多少数据库密集型的cron作业，以及你有什么样的设置。我最近花了一天时间在一个非常密集的脚本中寻找Heisenbug，该脚本将映像从db迁移到s3(并且在迁移时创建了几个拇指)。问题是，由于我们的ORM中没有记录的行为，到数据库的连接在某些时候会丢失，因为将某些图像发布到s3 +大拇指生成所花费的时间比连接时间限制要多一点。这是一种糟糕的情况，在递归的"包办一切"方案中，可能需要花费超过一天的时间来识别。
您最好使用安全的方法，即使这意味着在执行cron之间会损失一些时间。
我将使用The Fat Controller来运行和重复任务，而不是使用cron作业。它基本上是一个守护进程，可以运行任何脚本或应用程序，并在完成后重新启动它，可以选择在运行之间延迟。
您还可以指定超时，以便停止长时间运行的脚本。这样你就不需要关心锁、长时间运行的进程、错误处理等等。这将有助于保持您的业务逻辑整洁。
网站上有更多的例子和用例:
http://fat-controller.sourceforge.net/