小規模から大規模への MySQL アーキテクチャの進化の詳細

Web サイト (discuz) の訪問数が最初から数千万件に達すると仮定して、その mysql サーバー アーキテクチャの進化を推測してみましょう。

第一段階
ウェブサイトのアクセス数の毎日の pv レベルが 10,000 未満です。 単一のマシンで web と db を実行します。アーキテクチャー層のチューニングを行う必要はありません (たとえば、memcached キャッシュを増やす必要はありません)。このとき、データは毎日コールド バックアップされることが多いですが、データのセキュリティを考慮する場合は、mysql のマスター/スレーブが設定される場合もあります。

第二段階
ウェブサイトの一日のアクセス数は数万に達しました。この時点で、単一のマシンにはすでにある程度の負荷がかかっています。Web と DB を分離し、キャッシュとして memcached サービスを構築する必要があります。言い換えれば、この段階では、単一のマシンを使用して mysql を実行し、Web サイト全体のデータ ストレージとクエリを実行することもできます。 MySQL マスター/スレーブを行う場合は、データのセキュリティも目的となります。

第3フェーズウェブサイトのアクセス数は毎日数十万PVに達しました。 1 台のマシンでサポートできますが、必要なマシン構成は以前のマシンよりもはるかに優れています。資金が許せば、MySQL サービスを実行するために高構成のマシンを購入できますが、これは、構成を 2 倍にしてもパフォーマンスが 2 倍になるという意味ではありません。 。したがって、この段階では、mysql サービスをクラスタ化することを考えます。これは、複数のマシンを使用して MySQL を実行できることを意味します。ただし、MySQL クラスターは Web クラスターとは異なり、データの整合性を考慮する必要があるため、Web クラスター化の手法 (lvs、nginx プロキシ) を単純に適用することはできません。可能なアーキテクチャは、
mysql マスター/スレーブ、1 つのマスターと複数のスレーブ です。アーキテクチャの堅牢性とデータの整合性を確保するために、マスターと複数のスレーブは 1 つだけ存在できます。
考慮する必要があるもう 1 つの質問があります。つまり、フロントエンド Web 層で、プログラムは MySQL マシンの IP を指定します。そのため、複数の mysql マシンがある場合、それをどのように構成するかです。プログラム？ discuz には、実際には MySQL の読み取りと書き込みの分離をサポートする機能があります。つまり、複数のマシンを使用して MySQL を実行できます。そのうちの 1 つは書き込み用で、もう 1 つは読み取り用です。プログラムに読み取り IP と書き込み IP を設定するだけで、プログラムが自動的にマシンを区別します。もちろん、discuz に付属の設定を使用しない場合は、
mysql-proxy というソフトウェアを使用して読み取りと書き込みの分離を実現することもできます。 1 つのマスター モードと複数のスレーブ モードをサポートします。

第4フェーズ 1日あたりのウェブサイトのアクセス数は数百万に達しました。以前の 1 マスター、複数のスレーブ モデルでは、Web サイトのアクセス数が増加すると、データベースの読み取り量も増加するため、スレーブを追加する必要がありますが、スレーブの数が数十に増加すると、ボトルネックが発生します。すべてのbin-logをすべてのスレーブに配布する必要があるため、この処理自体が非常に面倒であり、頻繁な読み取りと相まって、スレーブからの同期データに大きな遅延が発生することは避けられません。したがって、最適化を行うことができます。
元の MySQL の 1 つのマスターと複数のスレーブを 1 つのマスターと 1 つのスレーブに変更すると、そのスレーブは他のスレーブのマスターとして機能し、元のマスターは Web サイトのビジネスの作成のみを担当します。後者は決して責任を負いません。Web サイト上の企業は、ビンログを他のスレーブと同期することのみを担当します。 このようにして、さらにいくつかのスレーブ ライブラリをスタックし続けることができます。

第 5 フェーズ Web サイトのアクセス数が 1 日あたり 1,000 万に達したとき、Web サイトの書き込み量が非常に大きいことがわかりました。以前のアーキテクチャではマスターが 1 つしかありませんでした。がボトルネックになっています。したがって、さらなる調整が必要です。たとえば、ビジネスをモジュールに分割し、ユーザー関連のものを分離することもできます。また、権限やポイントなどを分離して別のライブラリを実行し、マスターとスレーブ、いわゆるサブライブラリとして機能することもできます。 。もちろん、緯度を変更したり、アクセスや書き込み量が多いテーブルを分けてサーバー上で実行したり、テーブルを複数の小さなテーブルに分割したりすることもできます。この操作ではプログラムの変更が必要となるため、事前に開発仲間とコミュニケーションをとり、設計を行う必要があります。つまり、このステップで行う必要があるのは、
サブデータベースとサブテーブルです。

裏面に書いてくださいさらに開発するには、大きなテーブルを小さなテーブルに分割し続けます。 国内の Alibaba Taobao ウェブサイトはすべて MySQL を使用しており、その分割ルールには地域ごとの分割などの幅があります。売り手と買い手で分けることもできますし、時期などで分けることもできます。

上記は、小規模から大規模への MySQL アーキテクチャの進化プロセスの詳細です。さらに関連するコンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。