問題內(nèi)容
上下文
我有很多帖子，每個帖子的贊成票和反對票計數(shù)都存儲在我的 Postgres 數(shù)據(jù)庫中。我正在運行 Gin Golang 服務(wù)器、Flutter 移動應(yīng)用，并使用 FCM（Firebase 云消息傳遞）向用戶發(fā)送通知。
架構(gòu)問題
首先，這個問題很容易解決。我只是不知道如何有效解決它。
我想大約每天向每個用戶發(fā)送一次得票最高的帖子。但是，我想根據(jù)用戶在應(yīng)用程序中最活躍的時間向他們發(fā)送通知（不是一次全部發(fā)送，即不僅僅是每天上午 12 點）。
所以，假設(shè)我在一個名為 active_times 的表中跟蹤每個用戶的一個條目，該條目有一個我根據(jù)他們與移動應(yīng)用程序（如 Postgres 中的 time ）交互時更新的字段。我根據(jù)用戶活動不斷更新。
我的直覺告訴我，我應(yīng)該每隔約 2 小時在我的服務(wù)器中運行一個 cron 作業(yè)，該作業(yè)會查詢在該約 2 小時窗口內(nèi)擁有 time 字段的所有用戶。然后，我將置頂帖子通知發(fā)送給這些用戶。然后，我在 Redis 緩存中保存一個映射 user_ids 到 time_notification_recieveds 的哈希集，并將自動過期設(shè)置為大約 12 小時。對于每個后續(xù)查詢，我首先檢查Redis中的if user_id，不要發(fā)送給該用戶，否則，發(fā)送并將id添加到Redis。
這將允許我有一個窗口，如果用戶在通知發(fā)送給他們后突然登錄或直接在應(yīng)用程序上進(jìn)行交互（將他們的活動轉(zhuǎn)移到 time），他們最多會在 12 小時內(nèi)收到通知稍后，但通常由于其活動窗口不會發(fā)生太大變化，因此大約每 24 小時（每天）發(fā)送一次。例如，這與他們的 time 窗口是下午 2 點相反，然后在我向他們發(fā)送通知后，它更新到下午 4 點，他們在 2 小時內(nèi)再次受到攻擊。
備注
這是一種有效的方法嗎？我最初考慮使用 Postgres 數(shù)據(jù)庫來存儲所有這些 ID，但我認(rèn)為這可能很快就會壓垮數(shù)據(jù)庫。
此外，Redis 就是用來做這種事情的嗎？我可以采取完全不同的方法來做到這一點嗎？
謝謝！
正確答案
在您擁有數(shù)百萬用戶之前，您每隔幾個小時執(zhí)行的任何操作都會非常高效。
我會在用戶表中有一個單獨的列（例如），其中包含“下一個通知時間”，用于安排通知。我想您不希望出現(xiàn)這樣的情況：用戶正在使用系統(tǒng)，然后立即收到通知，對嗎？
為了確定何時發(fā)送通知，您可以使用一個帶有迷你活動直方圖的表格；類似的東西
用戶 ID
一天中的某個時間
柜臺
然后每當(dāng)用戶進(jìn)行“活動”時就會增加計數(shù)器。然后，在計算“下次發(fā)送通知的時間”時，您可以查看此表以找到該特定用戶的最佳時間。隨著時間的推移，您可以改進(jìn)算法，使其變得更加復(fù)雜，而不僅僅是活動計數(shù)。 （也許您希望在用戶通常活躍之前一小時收到通知？或者可能是他們有時使用該應(yīng)用程序但不習(xí)慣使用的時間，等等）。
