上下文
我有很多帖子，每个帖子的赞成票和反对票计数都存储在我的 Postgres 数据库中。我正在运行 Gin Golang 服务器、Flutter 移动应用，并使用 FCM（Firebase 云消息传递）向用户发送通知。
架构问题
首先，这个问题很容易解决。我只是不知道如何有效解决它。
我想大约每天向每个用户发送一次得票最高的帖子。但是，我想根据用户在应用程序中最活跃的时间向他们发送通知（不是一次全部发送，即不仅仅是每天上午 12 点）。
所以，假设我在一个名为 active_times 的表中跟踪每个用户的一个条目，该条目有一个我根据他们与移动应用程序（如 Postgres 中的 time ）交互时更新的字段。我根据用户活动不断更新。
我的直觉告诉我，我应该每隔约 2 小时在我的服务器中运行一个 cron 作业，该作业会查询在该约 2 小时窗口内拥有 time 字段的所有用户。然后，我将置顶帖子通知发送给这些用户。然后，我在 Redis 缓存中保存一个映射 user_ids 到 time_notification_recieveds 的哈希集，并将自动过期设置为大约 12 小时。对于每个后续查询，我首先检查Redis中的if user_id，不要发送给该用户，否则，发送并将id添加到Redis。
这将允许我有一个窗口，如果用户在通知发送给他们后突然登录或直接在应用程序上进行交互（将他们的活动转移到 time），他们最多会在 12 小时内收到通知稍后，但通常由于其活动窗口不会发生太大变化，因此大约每 24 小时（每天）发送一次。例如，这与他们的 time 窗口是下午 2 点相反，然后在我向他们发送通知后，它更新到下午 4 点，他们在 2 小时内再次受到攻击。
备注
这是一种有效的方法吗？我最初考虑使用 Postgres 数据库来存储所有这些 ID，但我认为这可能很快就会压垮数据库。
此外，Redis 就是用来做这种事情的吗？我可以采取完全不同的方法来做到这一点吗？
谢谢！
正确答案
在您拥有数百万用户之前，您每隔几个小时执行的任何操作都会非常高效。
我会在用户表中有一个单独的列（例如），其中包含“下一个通知时间”，用于安排通知。我想您不希望出现这样的情况：用户正在使用系统，然后立即收到通知，对吗？
为了确定何时发送通知，您可以使用一个带有迷你活动直方图的表格；类似的东西
- 用户 ID
- 一天中的某个时间
- 柜台
然后每当用户进行“活动”时就会增加计数器。然后，在计算“下次发送通知的时间”时，您可以查看此表以找到该特定用户的最佳时间。随着时间的推移，您可以改进算法，使其变得更加复杂，而不仅仅是活动计数。 （也许您希望在用户通常活跃之前一小时收到通知？或者可能是他们有时使用该应用程序但不习惯使用的时间，等等）。
