Memcacheでデータをキャッシュするために使用できるデータベースとN台のサーバーを持つサーバーが1台あるとします。データベース内のすべてのレコードは、キャッシュ内に複数の（ただし実質的にN未満）表現を持つことができます。たとえば、id 108のエンティティは、entity_108_1、entity_108_2、...、entity_108_10というキーでキャッシュできます。データベース内の一部のレコードが変更されると、キャッシュ内のそれぞれのレコードが新しいデータに置き換えられます。Master + SlaveデータベースアーキテクチャとMaster + Memcache
なぜこのアーキテクチャはマスター/スレーブデータベースの設定より優れていないのですか？レプリケーションの遅れにさらされていないのと同じ利点があるようです。
memcacheと一緒に行く方が良いと思います。レプリケーション中に遅延が発生するだけでなく、問題が発生しますが、N台のサーバーには膨大なHDDスペース（大規模なデータベースがあると仮定した場合）は必要ありません。一方、冗長性は実現しません。あなたのマスターデータベースサーバが消滅した場合は、誰もそのデータベースサーバを使用することはできません。だから、スレーブサーバはこれらの目的には必要ですが、N個は必要ないでしょうし、memcacheを使ってスケーラビリティを達成できるのであれば、それをしない理由はありません（つまり、それを使用する方法を知っている）。私の経験から、memcachedインスタンスをスレーブのMySQLサーバよりも保守するほうがずっと簡単です（おそらく他のデータベースエンジンと同じです）。
もちろん、memcacheの使い方を知っているアプリケーションを開発した場合、これはすべて意味があります。もう1つの接続文字列を設定に追加し、マスターと同じ方法でデータベースサーバから読み取り専用の目的で使用する方が簡単です。他のデータソース（memcacheなど）のデータを使用すると、アプリケーションをそのようにbuldしたとみなされます。あなたはmemcacheの
解決のためのN個のノードを持っている場合でも、あなたはまだDBのマスター/スレーブ設定を持つことになりますと仮定し
が、これは我々が話をしている場合は、マスタ/スレーブよりも良くない短所と長所
が付属しています書き込みの重いシナリオでは
書き込みプロセスは、すべてのキャッシュされたオブジェクトをすべてのmemcacheノードで期限切れにする必要があり、古いデータのコピーへのアクセスを避けたいので、「成功」の応答を待たなければなりません。この場合、キャッシュされたオブジェクトのコピー数とネットワーク速度によっては、パフォーマンスが低下する可能性があります。どのノードにコピーがあるのかわからないので、すべてのノードに期限切れ要求を送信する必要があります......（