私はMySQLをスケーリングするためのソリューションを検討してきました。Memcachedレイヤーの追加以外によく発生するのは、読み取り/書き込み分割です。すべての書き込みはマスターに送信され、すべての読み取りは負荷分散されたスレーブのセットに送信されます。
このアプローチで明らかに発生する問題の1つは、「結果整合性」です。マスターで書き込みを実行すると、読み取りスレーブへのレプリケーションに一定の時間がかかります。したがって、新しく作成された行を要求すると、そこにない可能性があります。
この問題を処理するための具体的な戦略を知っている人はいますか？「何を書くかを読む」機能の概念的な部分的な解決策について読みました。しかし、概念的に、または具体的にはSpring / Hibernateスタックにあるかどうかにかかわらず、そのようなソリューションを実装する方法を誰かが知っている人はいますか？
私はこれを行っていませんが、ここにアイデアがあります。各読み取りクエリの前に接続する書き込みデータベースに memcache サーバーを配置できます。書き込みを行うときは、なんらかのキーを memcache に追加し、1をレプリケートするときはキーを削除します。
memcache 読み取りを実行し、単一のレコードを読み取る場合、レコードのキーが見つかった場合は、マスターからのみ読み取る必要があります。複数のレコードを選択している場合は、スレーブからそれらを読み取り、見つかった各 ID を memcache キーに対してクエリします。memcache で見つかった場合は、マスター データベースからそれらのレコードのみを再読み取りします。
この戦略が読み取り/書き込み分割の利点を無効にする (書き込みが多い) ユースケースがいくつかあることに気付くかもしれません。しかし、ほとんどの場合、memcache の余分なチェックと時折のマスターの再読み取りは、まだ価値があると私は賭けます.
1標準の複製を使用していて、特定のレコードが完全に複製されたかどうかを追跡できない場合は、すべてのキーにタイムスタンプを付けて、最悪のシナリオの遅延後にそれらを削除/期限切れにします。たとえば、スレーブがマスターより 2 分遅れている場合、確実に複製されるため、2 分より古いキーは無視 (および削除) します。
つまり、遅延が許容されるケースがたくさんあることを忘れないでください。たとえば、ユーザーがプロファイルを更新する Web サイトがある場合、変更が 5 分間完全に反映されなければ、ほとんどの場合問題ありません。肝心なのは、不要な場合にすぐに伝播できるように何かを過度に設計しないことです。