1. QR コードをスキャンしてログインするにはどうすればよいですか?
1. Webページでログインページを開き、サーバーが生成する固有の番号を持つQRコードを表示します。その後、ブラウザはこの QR コードのステータスを定期的にポーリングします。
2. APP は QR コードをスキャンし、APP のトークン情報と QR コード ID をサーバーに送信し、 サーバーはリクエストを受信した後、 QR コードのスキャンステータスを変更し、一時的なトークンを生成します。
3. Web ページに表示される QR コードのステータスは、コードがスキャンされており、確認する必要があることを示します。APP が コードをスキャンした後、承認された操作を確認するプロンプトが表示されます。
4. ユーザーがログインを確認した後、一時トークンをサーバーに持ち込むと、サーバーはQR コードのステータスを変更し、Web ページの認証トークンを生成します。
5. Web ページはステータスの変更をポーリングし、トークンnを取得して QR コード認証を完了します。
2. 注文がタイムアウトした場合の自動キャンセル機能はどのように設計すればよいですか?
この問題は単純で、スケジュールされたタスクを作成してデータベースをポーリングし、順序時間に基づいて、それを キャンセルするだけです。
7年間活動していたファン も同様の対応をしたが、失敗した。
このアプローチにはいくつかの問題があります。
1. ポーリングに遅れが、時間通りに注文をキャンセルすることが不可能になります。
2.データベースのデータベースに大きな負荷をかけるため、注文テーブルのデータ量が比較的多い場合、 ポーリングの効率は比較的低くなります。
パフォーマンスとリアルタイム性を考慮する必要がある場合、より良い解決策はあるでしょうか?
もちろんそれもありますが、例えば
3. タイム ホイール アルゴリズム (写真). このアルゴリズムは循環配列 + リンク リストを使用して遅延 タスクを管理します。必要なのは、この注文のタイムアウトを計算し、タイム ホイールに追加することだけです。
タイムホイール アルゴリズムの唯一の欠点は、永続化できないため、サービスの再起動後にデータのウォームアップが必要なことです。
4.メインストリーム MQ の遅延メッセージ機能を使用すると 、メッセージはBrokerに送信されてから すぐに配信されるのではなく、メッセージに設定された遅延時間に従って配信されます。新しい注文を送信し、この注文の MQへのタイムアウトを計算するだけです。
MQ 実装方法は、パフォーマンス、スケーラビリティ、安定性の点で優れており、良い選択です。
3. インターフェイスの冪等性を理解する方法と、プロジェクトでインターフェイスの冪等性を確保する方法
簡単に言うと、同じパラメータを使用して繰り返し実行した場合に、データを 1 回インターフェイスです。
例えば、決済業務において、決済インターフェースの調整をN回繰り返しても、資金の引き落としは1回だけとなる、これが威力です。
待って。
好奇心旺盛な学生いるかもしれませんが、これは普通のことではないでしょうか? なぜそれを個別に話す必要があるのでしょうか？
理由は単純で 、｛図にあるように｝分散アーキテクチャでは、ネットワーク通信の導入により、 リクエスト成功・失敗以外にステータスも不明となるためです。
つまり、リモート インターフェイス呼び出しが失敗した場合、リクエストはサーバー側で正常に実行された可能性があります。
このリクエストが確実に正常に実行されるようにするために、クライアントは再試行操作を開始し、同じインターフェースが 複数回呼び出される場合があります。
サーバー インターフェイスの冪等性を確保するには、 データ変更が実行されないように、現在のリクエストをサーバー インターフェイス内の繰り返しリクエストとして識別する必要があります。
一般的な解決策がいくつかあります。
1. これを実現するには、データベース内の一意のインデックス。 メッセージコンテンツフィールドを持ち、一意のインデックスとして設定されるメッセージ テーブルを具体的に作成できます。各メッセージを受信した後、md5 値が生成され、 メッセージテーブルです。重複メッセージが発生すると例外がスローされます。この例外をキャッチして、 データへの繰り返しの変更を避けることができます。
2. Redis でsetNx コマンドを使用すると、現在のリクエスト内で一意に識別された情報をRedis に保存できます。setNx コマンドによって返された結果に基づいて、それが繰り返し実行されたかどうかを判断できます。繰り返し実行された場合、リクエストは次のようになります。捨てられた。
3.ステート マシン メソッドを使用して冪等性を実現します。多くのビジネス シナリオでは、ビジネス ステートのフローが存在し、 これらのステートフロー前進するだけです。したがって、データを変更するときは、次のデータを変更するだけで済みます。状態を 表面に示すことで、データが繰り返し変更されるという問題を回避できます。
もちろん、これらの方法に加えて、他の解決策もあるはずです。
どのソリューションを採用する場合でも、核心となるのは、現在のリクエストを繰り返しのリクエストとして識別することです。
4.メッセージプッシュにおける既読メッセージと未読メッセージの設計上の問題
「サイトメッセージ」には 2 つの基本的な機能があります。
1. ポイントツーポイントのメッセージ送信。ユーザーはユーザーにサイト メッセージを送信し、管理者はユーザーにサイト メッセージを送信します。
2. ポイントツーポイントメッセージング。管理者がユーザーにグループメッセージを送信（特定の条件を満たすユーザーグループを指定）
これら 2 つの関数も、{図に示すように} 実装するのが非常に簡単です。
メッセージ コンテンツ テーブルとユーザー通知テーブルを設計するだけで、システム通知が作成されると、データがメッセージ コンテンツ テーブルに挿入されます。メッセージの内容には送信チャネルが含まれており、その後のアクションは送信チャネルに基づいて決定されます。
サイト内チャネルの場合は、メッセージ コンテンツを挿入した後、レコードをユーザー通知テーブルに非同期的に挿入します。
この解決策は問題がないようですが、実際には、すべてのユーザー通知メッセージを テーブル入れている ため、ユーザーが 10W いる場合、同じメッセージを 10W ずつ保存する必要があります。
明らかに、次の 2 つの問題が発生します。
1.ユーザーの数が増えると、メッセージを送信するためにデータベースに挿入する必要があるデータの量がますます増大し、時間がかかるようになります。
2. ユーザー通知テーブルのデータ量が非常に多くなり、未読メッセージのクエリ効率が大幅に低下し
したがって、上記の解決策は明らかに機能しません。これら 2 つの問題を解決するために、参考となる解決策が 2 つあります。
最初の方法 (図に示すように) は、プラットフォーム メッセージの送信時に大量の重複 データが挿入される問題を回避するために、最初にユーザー通知テーブルをキャンセルすることです。
次に、 -site メッセージ進行状況テーブルに「message_offset 」を追加します。これにより、各ユーザーがメッセージ消費進行状況の オフセットを維持します。
各ユーザーが未読メッセージを取得するときは、現在維持されている msg_id_offset より大きいデータをクエリ する。
この設計方法では、10万人にメッセージを送信する場合でも、メッセージコンテンツテーブルに1 レコード。
パフォーマンスとデータ量が大幅に向上しました。
2 番目の方法は、最初の方法と同様に、Redis の Set コレクションを使用して、読み取られたメッセージ ID を保存します。 userid_read_message をキー として使用する と、読み取られたすべてのメッセージのID をユーザーごとに保存できます。
ユーザーが未読メッセージを読み取る このようにして、読まれたメッセージの数と特定のメッセージ ID がわかったら、そのメッセージ IDを直接使用して 、未消費データことができます。
ソリューション設計を少し最適化するだけで、パフォーマンスが大幅に向上する可能性があるため、多くの 企業は、より多くの資金を投じて、優れたスキルを持つ人材を採用したいと考えています。
5. ブルームフィルターとは何ですか? 何のために？
ブルームフィルターを説明する前に、まず質問させてください、ある要素が特定の セット場合はどうすればよいでしょうか?
一般的な解決策は、最初にすべての要素を保存し、次にループ比較によってそれらを決定することです。
しかし、(図に示すように) 数千万、さらには数億のデータがある場合、データ取得の時間の複雑さはさまざまなデータ構造によって最適化できますが、全体的な効率は依然として非常に遅く、多くの時間がかかります。メモリ空間、この問題を解決するにはどうすればよいですか?
このとき、ビットマップが便利です {写真}
BitMapの基本原理は、ビットを使用して現在のデータが存在するかどうかのステータス値を格納すること です。つまり、データハッシュ演算を通じてモジュロ化され、ビットの 配列 に分類され、その位置には 1 のマークが付けられます。この方法は大規模なデータに適していますが、データの状態はそれほど多くないため、通常は特定のデータが存在するかどうかを判断するために使用されます。
ブルーム フィルターは、ビットマップに基づいて最適化された設計です (図に示すように) 。
その原理は、要素がセットに追加されると、その要素が K 個のハッシュ関数を通じてビット配列内のK 点にマッピングされ 、1 に設定されるということです。
取得時も同様の方法でマッピングを行い、マッピングされた各位置の値が1になっているかどうかを見れば、その要素がコレクション内に存在するかどうかが大まかに分かります。
これらの点のいずれかが0の場合、チェック対象の要素は存在しないはずです。すべて 1 の場合、チェック対象の要素は 存在する可能性があります。