在fastcgi应用程序中缓存的最有效方法 [英] Most efficient way to cache in a fastcgi app

问题描述

为了娱乐，我正在编写一个fastcgi应用程序.现在，我要做的就是生成一个GUID并将其显示在页面顶部，然后根据url进行数据库查询，该url从我现有站点之一中提取数据.

For fun i am writing a fastcgi app. Right now all i do is generate a GUID and display it at the top of the page then make a db query based on the url which pulls data from one of my existing sites.

除了GUID，我想尝试缓存页面上的所有内容.有什么好的方法呢?我听说过但从未使用过redis.但它似乎是一台服务器，这意味着它处于单独的过程中.也许在过程中的解决方案会更快?(除非不是?)

I would like to attempt to cache everything on the page except for the GUID. What is a good way of doing that? I heard of but never used redis. But it appears its a server which means its in a seperate process. Perhaps an in process solution would be faster? (unless its not?)

什么是页面缓存的好解决方案?(我正在使用C ++)

What is a good solution for page caching? (i'm using C++)

推荐答案

您的实现听起来像您需要一个简单的键值缓存机制，并且可以使用类似 boost :: unordered_map . unordered_map 提供了哈希表实现.如果您有时需要更高的性能，还可以查看 Boost.Intrusive 可提供高性能，标准库兼容的容器.

Your implementation sounds like you need a simple key-value caching mechanism, and you could possibly use a container like std::unordered_map from C++11, or its boost cousin, boost::unordered_map. unordered_map provides a hash table implementation. If you needed even higher performance at some point, you could also look at Boost.Intrusive which provides high performance, standard library-compatible containers.

如果您使用提到的建议来滚动缓存，则第二个问题将是缓存条目到期，因为缓存的数据可能会过时.我不知道您的数据是什么样的，但是您可以选择实施以下任何一种缓存策略:

If you roll your cache with the suggestions mentioned, a second concern will be expiring cache entries, because of the possibility your cached data will grow stale. I don't know what your data is like, but you can choose to implement a caching strategy like any of these:

• 一定时间/使用次数后，使缓存的条目失效
• 在一定时间/使用次数后，使整个缓存过期(极端)
• 最近最少使用的-有关此问题的堆栈溢出问题: LRU缓存设计

多线程/并发访问也可能是一个问题，尽管如上面链接中所建议的那样，可能是在访问时锁定缓存，而不用担心粒度锁定.

Multithreaded/concurrent access may also be a concern, though as suggested in the link above, a possibility would be to lock the cache on access rather than worry about granular locking.

现在，如果您正在谈论扩展，上移到多个进程以及在多个物理机之间分配服务器进程，那么简单的进程内缓存可能就不再可行了(每个人可能拥有不同的数据副本)在任何给定时间，如果某些服务器缓存了数据而其他服务器没有缓存，则性能会不一致.

Now if you're talking about scaling, and moving up to multiple processes, and distributing server processes across multiple physical machines, the simple in-process caching might not be the way to go anymore (everyone could have different copies of data at any given time, inconsistency of performance if some server has cached data but others don't).

这是Redis/Memcached/Membase/etc的位置.闪耀-它们是为扩展和从数据库分担工作而构建的.它们的性能可能会被数据库和内存中的缓存所击败(毕竟存在延迟，还有许多其他因素)，但是在扩展方面，它们非常有用，可以节省数据库的负载，并且可以快速处理请求.它们还带有功能缓存过期(它们之间的实现有所不同).

That's where Redis/Memcached/Membase/etc. shine - they are built for scaling and for offloading work from a database. They could be beaten out by a database and in-memory cache in performance (there is latency, after all, and a host of other factors), but when it comes to scaling, they are very useful and save load from a database, and can quickly serve requests. They also come with features cache expiration (implementations differ between them).

最好?它们易于使用和插入.您无需从一开始就选择redis/memcache，因为缓存本身只是一种优化，您可以使用例如内存缓存来快速替换缓存代码.您自己可以使用Redis或其他方式.

Best of all? They're easy to use and drop in. You don't have to choose redis/memcache from the outset, as caching itself is just an optimization and you can quickly replace the caching code with using, say, an in-memory cache of your own to using redis or something else.

尽管如此，缓存服务器之间仍然存在一些差异-membase和memcache分发它们的数据，而redis具有主从复制.

There are still some differences between the caching servers though - membase and memcache distribute their data, while redis has master-slave replication.

记录:我在一家使用内存缓存服务器的公司工作-我们在数据中心中有几台服务器，其余的服务器每台都完全分配了大约16 GB的RAM来缓存.

For the record: I work in a company where we use memcached servers - we have several of them in the data center with the rest of our servers each having something like 16 GB of RAM allocated completely to cache.

为了进行速度比较，我将改编我很久以前看过的Herb Sutter演示中的内容:

And for speed comparisons, I'll adapt something from a Herb Sutter presentation I watched long ago:

• 在内存中处理->非常快
• 从本地进程的内存数据中获取数据->仍然非常快
• 来自本地磁盘的数据->取决于您的I/O设备，SSD可以快速运行，但是机械驱动器很方便
• 从远程进程获取数据(内存中的数据)->快速执行，最好关闭缓存服务器
• 从远程进程(磁盘)中获取数据->冰山

这篇关于在fastcgi应用程序中缓存的最有效方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！