Redis を使用して、重複を避けるために変更される時間設定に基づいて FCM 経由でユーザーに 1 日に 1 回メッセージを送信します。

コンテキスト

私には多くの投稿があり、各投稿の賛成票と反対票の数が Postgres データベースに保存されています。私は、Gin Golang サーバー、Flutter モバイル アプリを実行し、FCM (Firebase Cloud Messaging) を使用してユーザーに通知を送信しています。

アーキテクチャの問題

まず、この問題は簡単に解決できます。 効果的に解決する方法がわかりません。

投票数の多い投稿を各ユーザーにほぼ 1 日 1 回送信したいと考えています。ただし、ユーザーがアプリで最もアクティブな時間に基づいてユーザーに通知を送信したいと考えています (一度にすべてではなく、つまり毎日午前 12 時だけではありません)。

それでは、active_times というテーブル内の各ユーザーのエントリを追跡しているとします。このエントリには、time# のようなモバイル アプリとの関係に基づく時間値が含まれています。 Postgres では ##) インタラクション中にフィールドが更新されました。ユーザーの活動に基づいて常に更新しています。

私の直感では、約 2 時間以内に

time フィールドを持つすべてのユーザーをクエリする cron ジョブを約 2 時間ごとにサーバーで実行する必要があると考えています。次に、これらのユーザーに固定投稿通知を送信します。次に、user_ids を time_notification_recieveds にマッピングする一連のハッシュを Redis キャッシュに保存し、自動有効期限を約 12 時間に設定します。後続の各クエリでは、まず Redis の if user_id を確認し、そのユーザーに送信しません。それ以外の場合は、ID を送信して Redis に追加します。

これにより、通知が送信された後にユーザーが突然ログインしたり、アプリ上で直接操作したりした場合 (アクティビティを

time に移動した場合) にログインするウィンドウを作成できるようになります。最大 12 件の通知は、その後の時間に受信されますが、アクティビティ ウィンドウはあまり変わらないため、通常は約 24 時間ごと (毎日) に送信されます。たとえば、これは、彼らの time ウィンドウが午後 2 時であるのに、私が通知を送信した後、午後 4 時に更新され、2 時間以内に再びヒットするのとは対照的です。 ＃＃＃述べる＃＃＃

これは効率的なアプローチですか?最初は、Postgres データベースを使用してこれらすべての ID を保存することを検討しましたが、これではデータベースがすぐに過負荷になってしまう可能性があると考えました。

また、Redis はこのようなことを行うのに使用されていますか?これを行うために実行できるまったく異なるアプローチはありますか?

＃＃＃ありがとう！

正解

ユーザー数が数百万人になるまでは、数時間おきに行うあらゆる作業が非常に効率的になります。

通知をスケジュールするための「次回通知時間」を含む別の列をユーザー テーブルに (たとえば) 作成します。ユーザーがシステムを使用しているとすぐに通知が届くという状況は望ましくないと思いますよね。

いつ通知が送信されるかを判断するには、ミニ アクティビティ ヒストグラムのようなテーブルを使用できます。

＃＃＃ユーザーID＃＃＃ ＃＃＃時刻＃＃＃ ＃＃＃カウンター＃＃＃

その後、ユーザーが「アクティビティ」を実行するたびにカウンターがインクリメントされます。次に、「次回通知を送信する時間」を計算するときに、このテーブルを参照して、その特定のユーザーにとって最適な時間を見つけることができます。時間の経過とともに、アルゴリズムを改善して、単なるアクティビティのカウントよりも複雑にすることができます。 (ユーザーが通常アクティブになる 1 時間前に通知を受け取りたい場合もありますか? または、ユーザーが時々アプリを使用するものの、それに慣れていない時間なども考えられます)。

以上がRedis を使用して、重複を避けるために変更される時間設定に基づいて FCM 経由でユーザーに 1 日に 1 回メッセージを送信します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。