この記事では、成長期間中にアクセスするWebサイトで発生する可能性のある認証の問題について説明します。
ユーザー認証データベースを保存する場所は？
ユーザーを文字列ログインですばやく認証するにはどうすればよいですか？
複数のシャードテーブルと複数のデータベースに分散されたユーザーデータを収集する方法
それをすべて機能させる方法と、MemcacheDBはこれをどのように支援できますか？
数か月前、私たちのプロジェクトで、最初に作成されたデータベースアーキテクチャが現在の負荷に適していないという事実に出会いました。 まず第一に、これはユーザーベースに関するものでした。
問題
はい、memcachedを使用してリクエストをキャッシュし、セッションに大量に保存し、多くのテーブルとデータベースでシャーディングすることでユーザーデータを共有しましたが、サイトでのユーザー認証などの基本的なことは、途方もなく長い時間がかかり始めました。
さらに、ユーザーの作業中に識別子のみを使用して友人に関するデータを収集するために、アプリケーションは既に150万を蓄積していたユーザーテーブルにアクセスする必要がありました。
サンプルの負荷が高いため、ユーザーログインテキストインデックスに非常に長い時間がかかり始めました。 リソースにアクセスするユーザーのほとんどは新規ユーザーであったため、登録数は1日に数万になりました。
ソリューションを検索する
いくつかの解決策がありました。
一方では、user1、user2、...、userNのようなMySQLの多くの認証テーブルにユーザーを分割する可能性を考慮しました。Nはユーザーのログインから何らかの方法で計算されました。 しかし、1つのデータベース内のテーブルの数がリレーショナルデータベースの通常のパフォーマンスに対して大きくなりすぎた場合はどうすればよいでしょうか？
スケーリングの柔軟性をどのように実現しますか？ 大規模なポータルは独自の認証システムを作成しますが、私たちのチームは主に限られたリソースの結果に取り組んでおり、そのような作業には時間がかかりすぎるため、既存のソリューションを探し始めました。
次に、 ここで読むことができるKey-Valueデータベースに注目しました （ http://habrahabr.ru/blogs/hi/55077/ ）
いくつかの事情により、まず第一に相対的な名声があったため、MemcacheDBに決めました。
建築
だから、今、アーキテクチャについて。
実験として、基本的な認証データだけでなく、迅速に取得できるようにユーザーデータの場所に関する情報もMemcacheDBに保存することにしました。
MemcacheDBの主な書き込み操作は、MySQLデータベースに複製することが決定されました。これは、MemcacheDBの整合性の維持における安定性が不明であり、まだ不明であるためです。 MemcacheDBの作成者はSteve Chuであり、私たちの手紙に応えて、これについては後で説明しますが、同じソリューションを推奨しました。
読み取り操作はMemcacheDBからのみ実行され、クローネでは1日に1回MySQLデータベースとMemcacheDBのIDチェックが設定されました。
プロジェクトはPHP5で実行され、最初はMCDBのクライアントとしてpecl-memcacheモジュールを使用しましたが、大量のデータの負荷テスト中に、モジュールが（memcacheの）読み取り遅延が大きい接続を切断する傾向があることが判明しました。 一連の苦悩と倒錯の後、著者スティーブ・チューに手紙を書きました。スティーブ・チューは、この種の問題を知っていて、最近公開されたpecl-memcachedモジュールをクライアントとして使用することを推奨したと述べました（追加されたdに注意）。 これで問題が解決しました。さらに、著者の迅速な対応により、最終的に選択の正しさを確信しました。
別のサーバーでデータベースが失われた場合の迅速な回復のために、メインデータがレプリケートされるMemcacheDBの別のインスタンスが作成されました。 データ障害が発生した場合、バックアップサーバーへの迅速な切り替えを手配します。
したがって、各ユーザーはキー=>値に従って2回保存されます。
ユーザーデータは常にデータに保存され、キーは次のとおりです。
- ユーザーログイン
- ユーザーID
したがって、登録プロセスは次のように表示されます。
- ユーザーデータはデータベースに保存されます。
- ユーザーデータは、user_ loginキーでMemcacheDBに保存されます 。loginはユーザーログインです
- ユーザーデータは、user_ idキーでMemcacheDBに格納されます。idはユーザー識別子です。
承認プロセス：
- ユーザーは、認証データ（ログインとパスワード）を入力します。
- システムは、user_ ログインキーを使用してMemcacheDBからユーザーデータを受信し、認証します。
ユーザーの友達に関する情報を取得するプロセス：
- ユーザーが友達リストをアップロードします。
- （おそらく同じMemcacheDBから）ユーザーフレンド識別子のリストを受信したシステムは、user_ idによって各フレンドに関する情報を受信し、この情報に基づいて、データベースに配信されている他のユーザーデータを収集します。
メリット
このアプローチの主な利点：
1.少量のデータと大量のデータの両方でMemcacheDBが同じタスクでMySQLのパフォーマンスを超えるパフォーマンスを示すことがあります。
2. MemcacheDBは、データベース内の多数のキーと値のペアを簡単に参照します。現在、データベースには約400万のキーと値のペアがあります。
3.エンティティによるデータのシャーディングと分離もMemcacheDBで可能です。異なるデータベースでMemcacheDBの複数のインスタンスを実行することで想像できます。
これらの変更は本番環境で2か月間機能しており、これまでのところ問題はありません。
この記事が、教育目的および蓄積された問題を解決するために役立つことを本当に願っています。
ご清聴ありがとうございました！