0

一个有趣的难题。这是我想要做的：

我有一个在 Heroku 上运行的 Pyramid (python 2.7.2) 网站，它将通知推送给我的 iPhone 应用程序用户。每天，每个用户都需要在上午 10:00 到晚上 10:00 之间随机生成的时间向他们发送推送通知（显然还需要知道用户的时区）。

我目前的计划如下：使用持久的工作进程每 1 分钟触发一次函数。每分钟，它将调用一个函数（在不同的线程上以免中断计时器），该函数将做两件事：

  1. 检查每个时区是否是晚上 11:00（每天发生 24 次，每个时区一次）。如果为真，它将调用一个函数，该函数遍历相应时区中的每个用户并生成他们第二天的随机时间，然后将其存储在 Mongo 数据库中。

  2. 在每一分钟，工作人员还将循环访问用户并检查他们是否在那时收到通知。如果到期，则发送通知。

我的问题是：有没有更好的方法不需要每天预先生成大量随机日期时间列表？

4

2 回答 2

0

这是一些伪代码：

Once per PERIOD (e.g. 1 minute) in the RANGE:
    Let NOTECOUNT be the number of users needing notification
    Let FRACTION be the length of the RANGE divided by the PERIOD
    Notify FRACTION of users (either first N or randomly chosen)
    Update notified user records with the notification time

At the end of each RANGE:
    Notify all users whose last notification time is at least 24 hours ago

没有明确说明如何处理多个时区。您可以简单地考虑每个支持的时区都需要上述过程的一个“实例”，并且每个时区中的用户列表将是每个实例中的候选列表。两个潜在的问题是用户可能会更改时区，而时区很糟糕，因此有时可能会发生两次（例如，当 DST 更改时），因此您应该考虑这一点。

于 2012-04-30T11:34:00.283 回答
0

当然还有其他方法。他们是否更好是另一回事。例如：假设在给定用户一天结束前还有n分钟，他们还没有收到通知。然后现在以概率 1/ n向他们发送通知。这样，您不需要大量的随机日期时间列表，但您仍需要每分钟遍历所有用户，查看他们是否已收到通知，并为他们计算随机数。总体而言，计算量要多一些（尽管我怀疑差异是否很大），这意味着您所有的数据库更新都很小。

或者：每次通知用户时，都会生成他们的下一次更新时间。这样，下一次更新时间会以增量方式计算，但仍是提前知道的。

（如果您的用户数量相对较少，因此在大多数分钟没有通知，您可以使调度更智能 - 但我不会多说，因为如果您的用户那么少，那么数量无论如何，您的软件需要做的工作将可以忽略不计，并且针对这种情况进行优化是没有意义的。）

于 2012-04-30T11:36:15.183 回答