如果您的任务是构建支持重复活动的事件调度系统，您将如何做？如何删除定期活动时的处理方式？你怎么能看到未来事件何时发生？
即。创建活动时，您可以选择“每日重复”（或每周，每年等）。
请回复一个设计。我已经习惯了Ruby / Rails，但是使用你想要表达设计的任何东西。
我在接受采访时被问到这个问题，并且无法得到我喜欢的非常好的回应。
注意：already asked/answered here.但是我希望得到一些更实用的细节，详情如下：
答案 0 :(得分：10)
我首先将一些时态表达式实现为outlined by Martin Fowler。这样可以确定计划项目何时应该实际发生。这是一种非常优雅的方式。我最终得到的只是文章中的内容。
下一个问题是弄清楚世界上如何存储表达式。另一个问题是当你读出表达式时，那些如何适应不那么动态的用户界面？有人说只是将表达式序列化为BLOB，但是表达树很难知道它是什么意思。
解决方案（在我的情况下）是存储适合用户界面将支持的有限数量的情况的参数，并从那里使用该信息动态生成临时表达式（可以在创建时进行序列化以进行优化） 。因此，Schedule类最终会有几个参数，如偏移量，开始日期，结束日期，星期几等等......从中可以生成临时表达式以进行艰苦的工作。
至于具有任务的实例，有一个'服务'可以生成N天的任务。由于这是与现有系统的集成，并且需要所有实例，因此这是有道理的。但是，像这样的API可以很容易地用于投影重复，而不存储所有实例。
答案 1 :(得分：2)
在我管理项目的数据库结束之前，我必须这样做。我要求将每个事件存储为单独的事件。这允许您只删除一个事件，或者您可以移动范围。删除倍数比尝试修改单个事件并将其变为两个要容易得多。然后我们能够创建另一个表，其中只有一个包含重复信息的recurrenceID。
答案 2 :(得分：2)
@Joe Van Dyk问道：“你能看到未来，看看即将举行的活动何时举行？”
如果您想查看/显示事件的下一个 n ，则必须提前计算 a）存储在某处或 b）即时计算并显示。任何晚上的框架都是一样的。
a）的缺点是你必须在某处限制它，之后你必须使用b）。更容易使用b）开始使用。
调度系统不需要这些信息，只需知道下一个事件的时间。
答案 3 :(得分：0)
保存活动时，我会将时间表保存到商店（让我们称之为“时间表”，然后我会计算下次活动的时间并保存，以便“事件”中的实例。然后我会查看“事件”并找出下一个事件何时发生并在此之前一直睡觉。
当应用“醒来”时，它会计算事件何时再次发生，再次将其存储在“事件”中，然后执行该事件。
重复。
如果在睡眠时创建了一个事件，则会中断并重新计算睡眠。
如果应用程序正在启动或从睡眠事件或类似事件中恢复，请检查“事件”是否已通过事件并采取相应措施（取决于您对错过事件的处理方式）。
这样的东西会很灵活，不会占用不必要的CPU周期。
答案 4 :(得分：0)
脱离我的头脑（在打字/思考时修改了几件事）：
确定所需的最低重复分辨率;这就是应用运行的频率。也许是每天，也许是每五分钟一次。
对于每个定期事件，如果需要，请存储最近的运行时间，运行间隔和其他好处，如到期时间。
每次应用程序运行时，它会检查所有事件，比较（今天/现在+ recurrenceResolution）和（recentRunTime + runInterval），如果它们重合，则触发事件。
答案 5 :(得分：0)
几年前，当我为自己 mumble 编写日历应用程序时，我基本上只是从cron中窃取了调度机制，并将其用于重复发生的事件。例如，除了1月份之外的每个月的第二个星期六发生的事情将包括指令“repeat = * 2-12 8-14 6”（每年，2-12个月，第2个星期从8日到14日，因为我在一周中使用了基于0的编号，所以星期六有6个星期六。
虽然这使得确定事件是否在任何给定日期发生变得非常容易，但是它不能处理“每N天”重复发生，并且对于不是unix-savvy的用户来说也不太直观。 / p>
为了处理单个事件实例和删除/重新安排的唯一数据，我只是跟踪计算了多远的事件并将结果事件存储在数据库中，然后可以在其中修改，移动或删除它们而不影响原始的重复事件信息。添加新的周期性事件时，会立即计算所有实例，直到现有的“最后计算”日期为止。
我没有声称这是最好的方法，但它是一种方式，并且在我之前提到的限制范围内运行良好。
答案 6 :(得分：0)
如果你有一个简单的reoccuring事件，比如每天，每周或每周几天，那么在scheduler / cron / at functionallity中使用buildt有什么问题？创建可执行/控制台应用程序并设置何时运行它？没有复杂的日历，事件或时间管理。
：）
// w ^