少なくとも 10,000 人が同時にログインすることを想定した Web アプリケーションを開発しています。現在、次の問題を解決しようとしています。
目的 - 同時ログインを禁止する (同じ資格情報でログインする)
アプローチされたソリューション - AJAX 呼び出しは JavaScript タイマーで実行され、DB 内のローカル セッション ID とセッション ID をチェックします。詳しい説明は同時ログイン回避を参照
問題 - 膨大な数の人々がオンラインで、10 秒ごとにタイマーを介してサーバーにアクセスすると、同時ログインがない場合でも、1 秒あたりの最大接続数と不要なクライアント サーバー トランザクションに関して、サーバーに多大な負荷がかかります。
解決策 - 現在のアプローチ以外に、同時ログインの問題を解決する方法はありますか?
あなたの輝きをありがとう!!!...
興味深い質問です。
純粋な RAM ベースのソリューションを使用するためにできることは、おそらくこの種の問題に最も適していると思います。Mysql には RAM ベースのストレージ エンジンがありますが、それはさておき、memcached と redis はどちらもデータの有効期限が自動化されており、おそらくパフォーマンスが優れているため、それらの方が適していると思います。Redis の有効期限とmemcached の有効期限を参照してください。
RAM だけにヒットさせることができれば、半分は勝ったと思います。
それに加えて、クライアントからの「ping」が本当に必要な頻度を慎重に評価してみてください。ユーザーがアイドル状態の場合、クライアントは 10 秒ごとに ping を送信する必要がありますか? セッションの有効期限が切れた後、ユーザー インタラクションを正常に処理できますか? (ユーザーがボタンをクリックすると、システムが「既にログインしています。他のウィンドウを閉じてください」という行に沿って何かを応答するなど。ユーザーがフォームへの書き込みに長い時間を費やしていない場合、これは機能する可能性があります。送信後にログアウトされたことを発見するだけです。)
最悪のシナリオとは？
このシナリオを試してください:
| time | Client 1 | Client 2 | Server |
| t0 | Log in | | |
| t1 | | | Authorize client 1 session |
| t2 | Send ping | | |
| t3 | | | Update client 1 session |
| t4 | | Log in | |
t3 と t4 の間の時間が 1 秒であるとします。その場合、次に起こることは次のとおりです。
| t5 | | | Server rejects client 2 |
また、t3 と t4 の間の時間が 20 秒で、ping 間隔が 10 秒の場合、クライアント 1 がなくなったと仮定します。
| t5 | | | Delete client 1 session |
| t6 | | | Authorize client 2 session |
ただし、ping 間隔がはるかに長いモデルを使用して、クライアントがログインする前に可能な遅延を導入することができます。ping 時間が 60 秒で、t3 と t4 の間の時間が 30 秒であるとします。
| t4+30| Send ping | | |
| t5 | | | Server rejects client 2 |
または - クライアント 1 がなくなった場合、
| t4+30| | | Delete client 1 session |
| t6 | | | Authorize client 2 session |
ただし、この遅延は、別のクライアントからの最近のログインがあった場合にのみ発生するため、典型的なユース ケースでユーザーごとにクライアントが 1 つしかない場合、深刻な問題は発生しません。