这是交易。我们会采取完整的静态 html 路径来解决性能问题，但由于该站点将是部分动态的，这对我们来说是行不通的。 我们想到的是使用 memcache + eAccelerator 来加速 PHP 并负责缓存最常用的数据。
这是我们目前想到的两种方法：
在 >>all
将内存缓存用于最常检索的数据，并与标准硬盘存储的缓存结合以供进一步使用。
仅使用 memcache 的主要优势当然是性能，但随着用户的增加，内存使用量会变得很重。将两者结合起来听起来对我们来说是一种更自然的方法，尽管理论上会在性能上有所妥协。 Memcached 似乎也有一些可用的复制功能，当需要增加节点时可能会派上用场。
我们应该使用什么方法？ - 妥协和结合这两种方法是愚蠢的吗？我们是否应该专注于使用 memcache，而不是专注于随着负载随着用户数量的增加而升级内存？
非常感谢！
【问题讨论】：
标签： database caching scalability memcached
您可以将磁盘/内存缓存的组合委托给操作系统（如果您的操作系统足够智能）。 对于 Solaris，实际上你甚至可以在中间添加 SSD 层；这种技术称为 L2ARC。
我建议您先阅读以下内容：http://blogs.oracle.com/brendan/entry/test。
【讨论】：
Memcached 是一个可扩展的系统。例如，您可以复制缓存以减少某些密钥存储桶的访问时间，或实施 Ketama 算法，使您能够从池中添加/删除 Memcached 实例，而无需重新映射所有密钥。这样，当您碰巧有额外的内存时，您可以轻松地添加专用于 Memcached 的新机器。此外，由于它的实例可以以不同的大小运行，您可以通过向旧机器添加更多 RAM 来抛出一个实例。一般来说，这种方法更经济，并且在某种程度上并不逊于第一种，尤其是对于 multiget() 请求。关于性能随数据增长而下降的问题，Memcached 中使用的算法的运行时间不会随数据大小而变化，因此访问时间仅取决于同时请求的数量。最后，如果你想调整你的内存/性能优先级，你可以设置过期时间和可用内存配置值，这将严格 RAM 使用或增加缓存命中。
同时，当您使用硬盘时，文件系统可能会成为您应用程序的瓶颈。除了一般的 I/O 延迟之外，碎片和巨大的目录之类的事情也会显着影响您的整体请求速度。另外，请注意默认的 Linux 硬盘设置更多是为了兼容性而不是速度，因此建议在使用前正确配置它（例如，您可以尝试 hdparm 实用程序）。
因此，在再添加一个积分点之前，我认为您应该调整现有系统。通常，即使对于高负载的网站，正确设计的数据库、配置的 PHP、Memcached 和静态数据的处理也应该足够了。
【讨论】：
Memcached 是您确定需要时使用的东西。您不必担心它会占用大量内存，因为在评估它时，您会考虑将要部署它的专用盒子的成本。
在大多数情况下，将 memcached 放在共享机器上是浪费时间，因为它的内存最好用于缓存它所做的任何其他事情。
memcached 的好处是可以将它用作多台机器之间的共享缓存，从而提高命中率。此外，您可以拥有比单个盒子更高的缓存大小和性能，因为您可以（并且通常会）部署多个盒子（每个地理位置）。
此外，通常使用 memcached 的方式取决于来自应用服务器的低延迟链接；因此您通常不会在基础架构内的不同地理位置使用相同的 memcached 集群（每个 DC 都有自己的集群）
流程是：
你不应该
由于您的性能测试环境永远不会完美，您应该有足够的仪器/监控来衡量性能并在生产中分析您的应用程序。
这也意味着你缓存的每一件事都应该有一个缓存命中/未命中计数器。您可以使用它来确定缓存何时被浪费。如果缓存的命中率很低（例如，
在生产环境中让各个缓存可切换可能也是值得的。
记住：优化会引入功能性错误。尽可能少做优化，并确保它们是必要且有效的。
【讨论】：
我认为将这两种方法折中并结合是一种非常聪明的方法。
最明显的缓存管理规则是延迟与延迟。大小规则，也用于 CPU 缓存。在多级缓存中，每个下一级都应该有更大的大小来补偿更高的延迟。我们有更高的延迟但更高的缓存命中率。所以，我不建议你将基于磁盘的缓存放在 memcache 前面。相反，它应该放在内存缓存后面。唯一的例外是如果您缓存安装在内存中的目录 (tmpfs)。在这种情况下，基于文件的缓存可以补偿 memcache 上的高负载，并且还可以获得延迟收益（因为数据局部性）。
这两个存储（基于文件，memcache）不仅仅是方便缓存的存储。您还可以使用几乎任何 KV 数据库，因为它们非常擅长并发控制。
缓存失效是一个单独的问题，可以引起您的注意。您可以使用几种技巧来为缓存未命中提供更微妙的缓存更新。其中之一是狗桩效应预测。如果多个并发线程同时出现缓存未命中，则它们都将转到后端（数据库）。应用程序应该只允许其中一个继续，其余的应该等待缓存。其次是后台缓存更新。很高兴不在 Web 请求线程中而是在后台更新缓存。在后台，您可以更优雅地控制并发级别和更新超时。
实际上，有一种很酷的方法可以让您进行基于标签的缓存跟踪（例如memcached-tag）。引擎盖下非常简单。对于每个缓存条目，您可以保存它所属的标签版本向量（例如：{directory#5: 1, user#8: 2}）。当您读取缓存行时，您还会从 memcached 中读取所有实际的向量编号（这可以通过multiget 有效地执行）。如果至少一个实际标签版本大于保存在缓存行中的标签版本，则缓存无效。并且当您更改对象（例如目录）时，应增加适当的标签版本。这是一种非常简单而强大的方法，但也有其自身的缺点。在此方案中，您无法执行有效的缓存失效。 Memcached 可以轻松删除实时条目并保留旧条目。
当然，您应该记住：“计算机科学中只有两件困难的事情：缓存失效和命名事情”——Phil Karlton。
【讨论】：
我建议您首先将 memcache 用于所有主要查询。然后，进行测试以找到最少使用的查询或很少更改的数据，然后为此提供缓存。
如果您可以将常用数据与很少使用的数据隔离开来，那么您可以专注于提高更常用数据的性能。
【讨论】：