每天执行一次用户操作：24小时重置与午夜重置[关闭]

当用户每天只能执行一次动作（例如，获得比赛的免费门票）时，我会遇到两种可能性。

1）24小时重置

如果他在第1天的晚上11:45执行动作，则只能在第2天的11:45或之后再次执行动作。他将无法在第二天的11:44做到这一点。

2）午夜重置（或任何固定时间）

无论用户在第1天什么时候执行该操作，只要它变成午夜且第2天开始，他都将能够再次执行该操作。

两者都限制了用户每天仅执行一项操作，但是我经常遇到方法1，我认为这样做很不方便，原因有两个：

• 首先，我必须等待时间
• 在很长一段时间内，我执行动作的时间戳会变得越来越迟，因为我将无法在每天的那个时间戳上准确地执行动作，而只能在几秒钟或几分钟后执行。

有什么技术上的原因，尽管我认为对于事先说明的用户来说，重要的缺点是它会首选方法1？

编辑，以指定：我特别是在谈论一个示例，其中显然不需要24小时的实际时间间隔，例如在当前的Theory11自由旋转事件中，您每24小时可获得1次自由旋转以获得机会在获奖中。

我很惊讶，因为我通常会期望午夜重新设置。

但是，它的确有一个主要缺点，即每24小时有一个以上的午夜。您需要选择时区。

也许这就是为什么选择每24小时通用一次的原因，您可以想象该公司可能不希望接受不同国家/地区的一半用户的本地时间不是午夜，或者他们可能认为“每天”暗示午夜因此，他们将市场营销更改为“每24小时”，并将软件规格更改为匹配

尽管我认为这几天看到“格林尼治标准时间下午2点结束”或类似情况很普遍。

我本来以为为每个用户存储上一个操作日期的挑战比为用户或操作类型分配时区的挑战要困难得多。

编辑我认为值得注意两种方法之间的差异

24小时规则

• 我将获得恒定的事件流，速率限制为每24小时小于1。
• 当我结束事情时，一些用户将获得较少的事件。
• 我需要存储每个用户的最后一个事件
• 当夏令时导致一天的忙碌或短暂时，我每天不会有1个事件
• 人类将无法精确地命中24小时，因此我平均每天自然会少于1小时

每个日历天规则1个

• 我在分配给一个日历日的50小时（？UTC + 14到-12？）期间收到大量事件
• 实际上，我仍然必须将每个用户的最后一个事件存储为“天”
• 我确实有一天的结束，我可以说现在以后的所有事件都不在当天。
• 我需要知道用户的位置，才能知道他们的活动适用于哪一天
• 有些人在“一天”中醒得比其他人早得多

UTC规则中每个日历日1个

• 我每天24小时都穿着漂亮的制服
• 我可以整理活动
• 我知道一天的开始和结束时间
• 夏令时会让人们感到困惑。
• 人类每天可以进行1次活动
• 不住在格林威治附近的人类将有有趣的开始和结束时间
• 也许我可以做一个聪明的优化，只存储已输入用户的列表？（可能最终我将存储每个用户的事件和时间）

*对事件进行批处理将对各种报告用途超级有用。例如。说我每24小时要赢得10个奖项，而且它们随时间而变化。第10天有多少学生报名？等等

从我的头顶上：

• 实施“自上次行动以来的24小时”版本可能会更容易
• 如果用户没有在上一次之后的24小时内准确执行操作，那么最终他们可能会错过整个24小时的时间，因为必须在他们入睡或工作时进行重置。也许他们是在早上7点才去上班，然后在晚上8点才去上班。第二天，他们在7:15，然后7:30，然后7:45进行操作，并在最后一天停留到8:00，然后在离开前执行操作。第二天他们不愿意一直待到8:15，所以只想念那天早上，在下午6点下班回到家后（间隔34小时）去做。如果行动的结果对公司来说是昂贵的，那么节省可能比不便更为重要。

正如其他答案所提到的那样，24小时方法对多个时区更友好，并且就像为每个用户存储最后一个成功的时间戳一样，其编码也很容易。

它还具有实际要求用户每天与应用进行交互以获取所有日常操作的“好处”。如果说要进行午夜重置，则用户可以在11:59 PM，然后在12:00 AM再次执行操作。他们可以隔天这样做，但仍然可以执行所有操作。对于某些应用程序，日常操作的目的是使用户每天与应用程序进行交互，因此不太理想。

还有第三种选择可以避免两者的UI陷阱，但是很难编码。

3）在（n-0.75）* 24小时内没有超过n个动作的条纹

它确实需要存储两个变量，但是它允许不试图滥用系统的人在一天中的任何时间都可以使用其一项操作，而不必担心时区和重置。

它还可以防止任何人使用多个“额外”操作。

因此，实际实施算法需要存储连胜的开始时间，最后一次播放时间以及连胜中的动作数。

跟踪上一个动作时间可以使您拒绝两个过于靠近的动作。您可以将限制设置为少于24小时，因为条纹可以防止在一天中的早些时候爬行。

只要您每天采取行动，条纹就会持续不断。如果采取某项措施意味着您在连胜中要采取的行动多于几天，那么它将被拒绝。这样可以防止缓慢向前爬行，并打包“额外”动作，因为条纹的开始时间不会改变。

一些伪代码来实现检查和跟踪时间：

//precondition: streakStart and  lastAction are initialized as in the far past
//              streakCount is initialized as 0
graceHours=18;
checkAllowed(currentTime,&streakStart,&streakCount, &lastAction){
    diffhours=hoursDifferent(lastAction,currentTime);
    if(diffhours< 24 - graceHours){
        return false;
    }
    diffhours=hoursDifferent(streakStart,currentTime);
    if(diffhours <= 24*streakCount - graceHours){
        return false;
    }
    if(diffhours > 24*(streakCount+2)-graceHours){
        streakStart=currentTime;
        streakCount=0;
    }
    streakCount++;
    lastActionTime=currentTime;
    return true;
}

作为额外的奖励，如果您需要的话，您还会获得连胜柜台。

关于您的操作间隔24小时的问题，有些公司改用22小时间隔，这样用户在需要执行操作的当天的确切时刻会有一些回旋余地，并且仍然可以鼓励用户实际执行操作每天一次-没有23:59-00:00漏洞。

没有答案，但是我没有足够的意见要发表。

tl/dr: 24 hour resets are the lazy man's way of minimizing load spikes

除了上述答案外，午夜重置还鼓励交通流量激增。如果在特定时间所有参与者都可以使用该操作，那么将有许多人同时尝试该操作的动机。这就是为什么大多数州的驾照在您的生日而不是固定的日期（美国）到期的原因：如果每个人的驾照在1月1日到期，DMV将无法跟上。

不用多说：如果计算机系统每天需要对大量用户采取措施，那么您可以提出相同的问题，我通常将其设计为两者的结合。您可以想象两个cron任务：

1. 在午夜运行，查找所有记录，采取措施
2. 每分钟运行一次（或按固定频率运行），查找自昨天00:00以来未采取任何行动的所有记录，采取行动，记录已采取行动

实际上，我发现前者很脆弱。如果cron任务在运行时中断，则可能未应用某些操作，因此系统可能需要执行其他工作才能记住它在哪里，并在中断的地方继续工作。如果您获得了足够的记录，而您的cron任务无法在合理的时间内处理所有记录，那么它也会引起问题，并且在完成之前将其关闭。

后者解决了这两个问题。这样做的目的并不是要使所有任务都准确地分开处理24小时，但是只要您的cron任务可以轻松地每天执行所有操作，它们就会非常接近，并且您可以保证每个人都可以在每天的实际情况下运行（即您不会在超过24小时的时间内慢慢消失）。但是最重​​要的是，如果由于某种原因发生故障，它很容易从中断处恢复。

https://www.youtube.com/watch?v=hoMO1yYC7pQ

TfL（伦敦交通）的每日巴士/火车票的有效时间为4:30 am至4:30 am。人们入睡时进行切换。很多人都想在午夜8:30至一个小时之前使用服务说

午夜重置有一个特定的条件，该条件可能是理想的，也可能是有害的，具体取决于您要解决的问题，即：我可以在一天的11:59:58处执行操作，然后在00:00:01处执行。如果问题空间是任何竞争，这都可能给选择在午夜之前执行其操作的人们带来不公平的优势。24小时重置规则是确保公平分配可用操作的唯一方法，而不管某人一天中的什么时间可用。

可以通过提供公差来缓解24小时重置的后果，例如，只要没有实际记录（或不采取行动），就可以在重置发生后的15分钟内接受动作请求效果），直到发生重置为止。这给解决方案带来了更多的复杂性，但是我想不出任何缓解策略，像午夜重置一样，能够间隔两秒执行两次日常操作。

我从未见过有人提到24小时制鼓励定期例行造访。许多游戏都有每天一次的登录/胜利奖励，该奖励会在24小时后重置，因为它们希望您每24小时检查一次，而不是每48小时检查一次。我想这对于托管机票赠品的网站来说是相似的。