假設我們有一臺帶有數據庫和N臺服務器的服務器，可用於使用Memcache緩存數據。數據庫中的每個記錄都可以在緩存中有幾個（但實質上少於N個）表示。例如，具有id 108的實體可以通過密鑰entity_108_1，entity_108_2，...，entity_108_10進行緩存。當數據庫中的某條記錄發生更改時，緩存中的相應記錄將被替換爲新數據。Master + Slave數據庫體系結構與Master + Memcache
爲什麼此架構不比主/從數據庫設置更好？看起來它具有相同的優勢，同時不會受到複製滯後的影響。
我認爲最好使用memcache。複製過程中的延遲不僅會造成問題，而且您的N臺服務器不需要很大的硬盤空間（如果我們假設您擁有龐大的數據庫）。另一方面，你不會達到冗餘。如果您的主數據庫服務器死亡，您將不會有任何人佔用它的位置。所以，從屬服務器對於這些目的是必要的，但很可能你不需要其中的N個，如果你可以通過使用memcache實現可擴展性，沒有理由不這樣做（我的意思是，如果你開發了應用程序知道如何使用它）。根據我的經驗，維護memcached實例比從屬MySQL服務器更容易（並且可能與其他數據庫引擎相同）。
當然，如果您開發了知道如何使用memcache的應用程序，所有這些都是有意義的。只需在你的配置文件中添加一個連接字符串並將它用於某些數據庫服務器的只讀目的，就像使用master一樣。使用來自其他數據源的數據（如memcache）假定您以這種方式構建應用程序。
假設你仍然有一個主/從設置分貝，即使你有內存緩存
解決N個節點配有缺點和優點
是，如果我們討論的不超過主/從更好在寫作沉重的情況下。
寫入過程需要跨所有緩存節點終止所有緩存對象，並且必須等待「成功」響應，因爲您希望避免訪問任何舊數據副本。在這種情況下，根據緩存對象副本的數量和網絡速度，您可能會遭受糟糕的性能。說，既然你不知道哪個節點有副本，你將不得不發送到期的請求到所有節點...... :(