这是交易。我们本可以采用完全静态 html 的方式来解决性能问题，但由于该站点将是部分动态的，因此这对我们来说行不通。 我们想到的是使用 memcache + eAccelerator 来加速 PHP 并负责缓存最常用的数据。
这是我们目前想到的两种方法:
在 >>所有<< 主要查询上使用 memcache 并让其独立执行其最擅长的工作。
将内存缓存用于最常检索的数据，并结合标准硬盘存储的缓存以供进一步使用。
只使用memcache最大的优势当然是性能，但是随着用户的增加，内存的使用量会越来越大。将这两种方法结合起来对我们来说是一种更自然的方法，尽管理论上会在性能上有所妥协。 Memcached 似乎也有一些可用的复制功能，这在需要增加节点时可能会派上用场。
我们应该使用什么方法？ - 妥协和结合两种方法是否愚蠢？我们是否应该将重点放在使用内存缓存上，而不是随着负载随着用户数量的增加而专注于升级内存？
非常感谢!
最佳答案
我认为将这两种方法折衷结合是一种非常聪明的方法。
最明显的缓存管理规则是延迟与时间。大小规则，也用于 CPU 缓存。在多级缓存中，每个下一级都应该有更大的大小来补偿更高的延迟。我们有更高的延迟但更高的缓存命中率。因此，我不建议您将基于磁盘的缓存放在 memcache 之前。相反，它应该放在 memcache 后面。唯一的异常(exception)是如果您将缓存目录安装在内存中 (tmpfs)。在这种情况下，基于文件的缓存可以补偿 Memcache 上的高负载，并且还可以获得延迟 yield (因为数据局部性)。
这两种存储(file based，memcache)不仅仅是方便缓存的存储。您还可以使用几乎任何 KV 数据库，因为它们非常擅长并发控制。
缓存失效是一个单独的问题，可以引起您的注意。您可以使用多种技巧在缓存未命中时提供更微妙的缓存更新。其中之一是狗堆效应预测。如果多个并发线程同时发生缓存未命中，则所有线程都将转到后端(数据库)。应用程序应该只允许其中一个继续进行，其余的应该等待缓存。其次是后台缓存更新。最好不要在 Web 请求线程中而是在后台更新缓存。在后台，您可以更优雅地控制并发级别和更新超时。
实际上有一种很酷的方法可以让您进行基于标签的缓存跟踪(例如 memcached-tag)。它在引擎盖下非常简单。对于每个缓存条目，您都会保存它所属的标签版本向量(例如:{directory#5: 1, user#8: 2})。当您读取缓存行时，您还从 memcached 中读取了所有实际向量编号(这可以通过 multiget 有效地执行)。如果至少一个实际标签版本大于缓存行中保存的标签版本，则缓存无效。当您更改对象(例如目录)时，应增加适当的标记版本。这是一种非常简单而强大的方法，但也有其自身的缺点。在此方案中，您无法执行有效的缓存失效。 Memcached 可以轻松删除事件条目并保留旧条目。
当然，您应该记住:“计算机科学中只有两件难事:缓存失效和命名事物”- Phil Karlton。
关于database - 组合缓存方法 - 基于内存缓存/磁盘，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2510409/