我有 5 台专用服务器，每台都运行相同版本的应用程序。我希望大幅加强我们的缓存策略，以减轻 MySQL 的负载，因为这是我们的主要瓶颈。所有站点都是 LAMP，每台服务器大约有 20 个托管站点。我计划使用 Zend_Cache 来运行缓存，它有许多我可以使用的适配器 - 主要的是 Memcached / APC / File 和 SQLlite。我希望缓存很多东西，但它们大多属于大型 DB 结果集或 HTML 片段的区域。对于 HTML 片段，基于文件的解决方案似乎是理想的，但许多人提到这可能会带来相当大的 IO 开销 - 特别是如果它在大量站点上完成，就像这样。我也很喜欢 Memcached，因为它的速度很快——我曾有一个模糊的想法，尝试设置一个专用的 Memcached 服务器，纯粹用于处理缓存，并让我所有的其他服务器使用它，尽管我不确定这是一个多么好的主意，也不确定由于 RAM 实际上不在发出请求的机器的本地，会损失多少速度。
最终，最好能得到一些关于不同适配器的性能（最佳性能）、它们最适合什么以及我们的最佳选择是什么的可靠建议。
谢谢。
答案1
听起来你已经选择了一个解决方案，现在只是试图理清细节。
我有 5 台专用服务器...LAMP
那么，您已经在所有 5 台主机上运行了循环主-主 mysql 复制，并且通过共享集群中的反向代理使用适当的缓存指令提供了 HTTP 内容？
大型数据库结果集或 HTML 片段
您已经针对大型结果集优化了模式，并且对 HTTP 片段使用了类似 ESI 缓存的功能。
我有一个模糊的想法，尝试设置一个专用的 Memcached 服务器，纯粹用于处理缓存
撇开这会引入单点故障的事实不谈，这比具有大量结果集缓存的单个 DBMS 服务器更有效率吗？
由于 RAM 不是直接本地的，其速度会损失多少
你为什么不测量一下并找出答案呢？
与 mysql 结果缓存相比，任何基于内存的缓存解决方案都不会产生太多（任何？）好处 - 如果您尝试缓存大型数据集，那么您很快就会刷新小型内存缓存。
坐下来，拿着电子表格开始做一些建模，以估计可缓存实体的数量和大小，以及在无限大的缓存条件下它们可能被重用的频率。