WeChatでメッセージを送るときは、相手に早く見てもらって、早く返信してほしいと思うのですが、相手が読んだかどうかはまだ分かりません。すぐに返信できないWeChatメッセージを受け取ったときは、見て見ぬふりをして黙って返します。WeChat は個人のソーシャル ネットワーキング、製品デザイン、オンライン ステータスに使用され、必須の開封確認は個人のプライバシーを公開する可能性があるため、WeChat には関連する機能がありません。DingTalkはビジネスコミュニケーションに利用されており、その「開封確認強制」機能により、職場では「オンラインになっていないふりをする」「受信していないふりをする」ことができなくなります。さらに、DingTalkのグループには「開封確認必須」機能があり、グループ内でメッセージを送信すると、誰がメッセージを読んだのか、誰が読んでいないのかが分かります。
グループ メッセージのプロセスとは何か、受信者はグループ メッセージが受信されたことをどのように確認するか、送信者は開封確認をどのように受信するか、プルするかプッシュするかが今日議論される問題です。
1. グループメッセージの配信プロセスと到達性の保証
主な質問 1: グループ メッセージのコピーは 1 つだけですか? それともメンバーごとに1部ですか？
回答:コピーを保存し、メンバーごとにグループ メッセージ キューを設定すると、データの冗長性が多くなり、適切ではありません。
主な質問 2: グループ メッセージのコピーが 1 つしかない場合、各メンバーがどのメッセージを読んだかをどうやって知ることができますか?
回答: グループ メッセージの半順序関係を使用して、各メンバーのlast_ack_msgid (last_ack_time) を記録できます。このメッセージの前のメッセージは既読であり、このメッセージの後のメッセージは未読です。このソリューションは、グループ内の各ユーザーについて、値を 1 つだけ記録する必要があることを意味します。
上記の 2 つの主要な質問に答えれば、グループ メッセージの主要なデータ構造を簡単に取得できます。
グループメッセージテーブル：グループメッセージを記録します。
group_msgs(msgid, gid, sender_uid, time, content); 各フィールドの意味は、メッセージ ID、グループ ID、送信者 UID、送信時刻、送信コンテンツです。
グループ メンバー テーブル: グループ内のメンバーと、各メンバーが受信した最後のグループ メッセージを記録します。
group_users(gid, uid, last_ack_msgid); 各フィールドの意味は、グループ ID、グループ メンバー UID、およびグループ メンバーが受信した最後のグループ メッセージ ID です。
コアとなるデータ構造を設計したら、グループ メッセージを送信するプロセスを見てみましょう。
ビジネスシーン:
(1) グループには 4 つのメンバー A、uid1、uid2、uid3 があります。
(2) A、uid1、uid2 はオンラインであり、オンライン メッセージをリアルタイムで受信することを期待しています。
(3) uid3 はオフラインであり、将来オフライン メッセージをフェッチする予定です。
メッセージ送信プロセス 1 ～ 4 の全体を上の図に示します。
(1) A がグループ メッセージを送信します。
(2) サーバーがメッセージを受信した後、最初にグループ メッセージを地上に送信する必要があり、次に、プッシュを実装するためにグループにどのグループ メンバーが含まれているかを確認する必要があります。
(3) グループ メンバーの場合は、オンライン ステータスを問い合わせます。
(4) オンライングループメンバーに対しては、プッシュを実装します。
このプロセスでは、メッセージ ランディングの 2 番目のステップが完了している限り、グループ メッセージが失われないことが保証されます。
主な質問 3: 受信者がグループ メッセージを確実に受信できるようにするにはどうすればよいですか?
回答: メッセージを受信した後、各メンバーは各グループ メンバーの last_ack_msgid を変更して、このメッセージが受信されたことが確認されたことをシステムに伝える必要があります。
オンラインメッセージとオフラインメッセージでは、last_ack_msgidの変更が異なります。
オンライン グループの友人の場合、グループ メッセージを受信した後、すぐに確認応答し、last_ack_msgid を変更します。
オフライン グループの友達の場合、次回のログイン時にすべての未読グループ オフラインメッセージが取得され、last_ack_msgid が最新のメッセージに変更されます。
主な質問 4: ACK が失われた場合、グループ メンバーは重複したグループ メッセージをプルしますか?
回答: はい、重複排除は msgid に基づいてクライアント側でローカルに実行できます。システム レベルで重複メッセージが受信された場合でも、良好なユーザー エクスペリエンスを保証できます。
上記のプロセスでは、受信者がメッセージを受信することのみを保証できます。送信者には、誰がオンラインでメッセージを読んだのか、誰がオフラインでメッセージを読んでいないのかがまだわかりません。開封確認は実装されていません。どのような種類の開封確認が送信されますか?システム設計はどうですか?影響はどうですか?
2. 開封確認処理
送信者が送信したグループ メッセージについては、メッセージを読んだ人の数と読んでいない人の数を知る必要があり、この関係を記録するための基本的なテーブルが必要です。
メッセージ受信テーブル: メッセージの開封確認を記録するために使用されます。
msg_acks(sender_uid, msgid, recv_uid, gid, if_ack); 各フィールドの意味は、送信者 UID、メッセージ ID、返信受信者 UID、グループ ID、受信マークです。
開封確認ロジックを追加すると、グループ メッセージの流れが少し変わります。
ステップ 2、サーバーがメッセージを受信した後、さらに次のことが行われます。
グループメッセージを送信します。
プッシュを実装するためにグループにどのグループ メンバーがいるかをクエリします。
さらに、次のものが必要です。
-
各メッセージの初期受信ステータスを挿入します。
受信側が last_ack_msgid を変更する手順は次のようになります。
(1) ACK リクエストを送信します。
(2) last_ack_msgid を変更し、読み取り確認の if_ack ステータスを変更します。
(3) 送信者のオンライン状態を問い合わせます。
(4) 開封確認をリアルタイムで送信者にプッシュします (送信者がオンラインの場合)。
送信者がオフラインの場合、次回ログインします。
(5) 各メッセージの開封確認を関連付けテーブルから取得します。
ここでの暫定的な結論は次のとおりです。
送信者がオンラインの場合、開封確認はリアルタイムでプッシュされます。
送信者がオンラインでない場合、開封確認は次回オンラインになったときに取得されます。
3. プロセス最適化計画
再度詳細な分析を行うと、グループ メッセージ開封確認の「メッセージ ストーム拡散係数」は、各グループのユーザー数が 200 人で、ユーザーの 20%、つまり 40 人がオンラインであると仮定します。グループ ユーザーがグループ メッセージを送信するたびに、次のことが行われます。
グループの友達に通知するメッセージは 40 件。
40 ack は last_ack_msgid を変更し、サーバーに送信します。
40 件の開封確認。送信者に通知されます。
ニュースストームの拡散係数が非常に大きいことがわかります。
同時に、40 個の ack レコードを保存する必要があります。
グループ、グループ友達、グループメッセージの数が増えると、ストレージも問題になります。
最適化計画はありますか?
受信側でグループメッセージのプッシュをポーリングやプルに変更できますか?
回答: いいえ、メッセージ受信とリアルタイム パフォーマンスが中心的な指標です。
last_ack_msgid の変更について、各グループ メッセージに確認応答する必要は本当にありますか?
回答: 実際には、その必要はありません。バッチで確認し、合計 N 個のグループ メッセージ (たとえば、10) を受信し、last_ack_msgid 変更リクエストをサーバーに送信し、同時にメッセージの開封確認を変更できます。このリクエストの前にすべてのリクエストが削除されるため、サーバーに送信される ACK リクエストの量は元の 1/10 に減ります。
副作用は何ですか?
回答: last_ack_msgid の機能は、受信側が最近取得したグループ メッセージを記録することです。リアルタイムで更新されないと、異常終了が発生したときに一部のグループ メッセージが last_ack_msgid の更新に失敗する可能性があります。ログインすると、重複したメッセージが表示されます。グループ メッセージ。しかし、これは問題ではありません。クライアントは msgid に従って重複を排除でき、ユーザー エクスペリエンスには影響しません。
送信者がオンラインの場合、開封確認を送信するためにリアルタイムのプッシュが本当に必要ですか?
回答: 実際には、必要ありません。送信者は、送信されたメッセージごとに 40 件の開封確認を受け取ります。ポーリング(たとえば、1 分に 1 回、1 時間あたり 60 件のリクエスト) を使用すると、リクエストの量を大幅に減らすことができます。
副作用は何ですか?
回答: 開封確認はリアルタイムでは更新されませんが、最悪の場合でも 1 分以内に更新されます。もちろん、このポーリング時間は、パフォーマンスと製品エクスペリエンスに基づいて妥協点として設定できます。
データ量を減らすにはどうすればいいですか？
回答: 受信データはコア データではありません。
-
既読メッセージは、削除対象としてマークするのではなく、物理的に削除できます。
-
N を超えた領収書はアーカイブまたは削除します。
4. まとめ
グループメッセージの開封確認の場合、一般的には次のようになります。
送信者がオンラインの場合、開封確認はリアルタイムでプッシュされます。
送信者がオンラインでない場合、開封確認は次回オンラインになったときに取得されます。
向けに最適化する場合は、次のことができます。
受信者は合計 N 個のグループ メッセージを受信し、バッチ ACK を送信します。
送信者はポーリングして開封確認を取得します。
開封確認データを物理的に削除し、コア以外の履歴データを定期的に削除またはアーカイブします。
----------
転載元：WeChat公開アカウント「建築家への道」