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