为用户安排通知提醒

Question

我试图设计一种最好的方式，向用户发送他们注册的事件的提醒：

• 应在活动开始前72、48和24小时发出催复通知。
• 提醒不能发送两次(因此，注册到事件B的用户A最多应收到3份通知)
• 如果用户按照这三个间隔中的一个进行注册，他们显然不会收到前面的内容。
• 事件时间不能在第一次注册后更改。

这是一个带有Sidekiq和Redis的Rails应用程序(现在我们只是在注册时发送一个通知，这是没有计划的)。

我认为至少有两种方法可以解决这个问题：

A.在注册时安排作业

• 如果注册时间早于事件72小时，则安排通知(事件日期- 72小时)并排队。
• 如果注册时间早于事件的48小时，则安排通知(事件日期- 48小时)并排队。
• 如果注册时间早于事件的24小时，则安排通知(事件日期- 24小时)并排队。

这应涵盖以下情况：

• 如果用户在任何一段时间内删除他的约会，他们将不会接收其他通知(排队的作业将简单地失败)
• 用户无法收到相同通知的两倍，因为最多有3个作业已排定。
• 如果事件被从DB中完全删除，并且它的注册也被删除，那么排队的通知就会失败。

缺点：

• 如果许多用户取消注册，队列中可能会有许多死作业。
• 用户可能会收到两次通知(如果他们注册，然后取消注册，然后再次注册)，但这可以通过使用https://github.com/mhenrixon/sidekiq-unique-jobs这样的方法解决，它允许队列中基于参数匹配的一种类型的作业。

B.带有任务

的轮询

基本上每隔X分钟就有一个后台任务(可以用Unix或sidekiq的cron扩展来完成)检查"events“表，检查离事件是否有72小时、48小时或24小时的时间，并在每个注册时排队一个即时作业。

这有几个缺点：

• 如果时间检查算法不够精确，用户可能会错过通知(如果他们在轮询窗口内注册，可能会被跳过)
• 需要一种机制来标记已发送特定用户的通知。还可以通过依赖于禁止队列中具有相同参数的作业的库来解决这一问题。

结论

我倾向于“提前安排”的做法。没有外部cron配置，我不需要每隔X分钟强调DB，如果有数百个用户注册了数百个事件，查询可能会变得很重，而且我可以监视Sidekiq web仪表板上发生的事情。

轮询似乎是最容易的，因为火和忘记自然，但它不可能是棘手的优化路线。轮询的一个巨大优点是它不需要配置有持久性的Redis。如果机器(或Redis)被重新启动，下一个cron迭代将主要是拾取它停止的地方。

调度解决方案需要配置具有持久性的Redis，因为如果机器重新启动，它将失去所有计划的作业，但这可能是一个一般的问题，所以这只是一个一般的需求。

有什么想法吗？我是不是遗漏了什么？

Answer 1

理想的设计可能是A，简单的修改就是在用户注销时删除队列中的任何相关通知。这一修改将解决所列的两个缺点。

然而，这两种设计都是可以接受的。如果实际考虑使这更容易实现，则可以使用B。