如果redis已经是堆栈的一部分，为什么Memcached仍与Redis一起使用? [英] If redis is already a part of the stack, why is Memcached still used alongside Redis?
问题描述
Redis可以执行Memcached提供的所有操作(LRU高速缓存，项目到期，现在在3.x +版本中，目前处于beta版中)或通过twemproxy等工具.性能也差不多.此外，Redis添加了持久性，因此在服务器重新启动时无需进行缓存预热.
参考一些比较Redis和Memcache的旧答案，其中一些偏爱Redis替代Memcache(如果已存在于堆栈中):
尽管如此，在研究大型网络公司(如Instagram，Pinterest，Twitter等)的堆栈时，我发现它们同时将Memcached和Redis用于不同的目的，而不是将Redis用于主缓存.主缓存仍是Memcached，Redis用于基于逻辑缓存的数据结构.
从2014年开始，当您已经拥有可以执行memcached可以做的所有事情的Redis组件时，为什么仍然值得把memcached作为额外的组件添加到堆栈中呢?有什么优势使建筑师/工程师除了已经存在的Redis之外仍包括内存缓存?
更新:
对于我们的平台，我们已经完全丢弃了Memcached，并使用redis满足了普通缓存和逻辑缓存的要求.高度 高效，灵活和可靠.
一些示例方案:
- 按特定模式列出所有缓存的键，并读取或删除它们的值.在redis中非常容易，而在memcached中则不容易.
- 要存储超过1mb的有效负载(在redis中很容易做到)，需要在memcached中调整平板大小，这本身就具有性能方面的副作用.
- 当前缓存内容的轻松快照
- Redis群集以及语言驱动程序也已经可以投入生产，因此群集部署也很容易.
我今天将其视为Redis上的Memcached的用例的主要原因是，您可以通过 plain获得的卓越内存效率 HTML片段缓存(或类似的应用程序).如果您需要将对象的不同字段存储在不同的Memcached键中，那么Redis哈希将提高内存效率，但是当您有大量键-> simple_string对时，memcached应该能够为您提供更多的项兆字节.
其他有关memcached的优点:
- 这是一段非常简单的代码，因此，如果您只需要它提供的功能，我想这是一个合理的选择，但是我从未在生产中使用过它.
- 它是多线程的，因此，如果您需要在单框设置中进行扩展，那是一件好事，您只需要与一个实例通信即可.
我相信，随着人们转向智能缓存或尝试通过Redis数据结构保留缓存数据的结构，将Redis作为缓存变得越来越有意义.
Redis LRU与内存缓存LRU之间的比较.
memcached和Redis都不执行真正的LRU驱逐，而只是近似执行.
Memcache逐出是按大小分类的，并且取决于其slab分配器的实现细节.例如，如果要添加适合给定大小类的项目，则memcached将尝试删除该类中已过期/未使用过的项目，而不是尝试全局尝试以了解对象是什么，而不管其对象是什么.大小，这是最佳选择.
相反， Redis会尝试在达到maxmemory限制时选择一个好的对象作为驱逐对象，查看所有对象，无论大小级别如何，但只能提供近似的好对象，而不能提供空闲时间更长的最佳对象.
Redis这样做的方法是对几个对象进行采样，然后选择一个空闲(未访问)时间最长的对象.由于Redis 3.0(当前处于beta版)，该算法得到了改进，并且在逐出过程中也采用了良好的候选库，因此对近似值进行了改进.在 Redis文档中，您可以找到说明和图表以及有关其工作原理的详细信息.
对于简单字符串->字符串映射，为什么memcached的内存占用量比Redis好.
Redis是一款更复杂的软件，因此Redis中的值以与高级编程语言中的对象更相似的方式进行存储:它们具有关联的类型，编码，用于内存管理的引用计数.这使Redis的内部结构良好且易于管理，但是与仅处理字符串的memcached相比，其开销很大.
当Redis开始提高存储效率时
Redis能够以特殊的内存节省方式存储小型聚合数据类型.例如，一个小的Redis Hash(代表一个对象)在内部没有存储在哈希表中，而是存储为二进制唯一的Blob.因此，将每个对象的多个字段设置为散列比将N个单独的键存储到memcached中更为有效.
实际上，您可以将对象作为单个JSON(或二进制编码)blob存储到memcached中，但是与Redis相反，这不允许您获取或更新独立字段.
Redis在智能缓存中的优势.
由于Redis数据结构，当缓存无效时用于销毁对象的memcached的常用模式是一种使用Redis的原始方式.
例如，假设您需要缓存发布到Hacker News的最新N条新闻，以便填充网站的最新"部分.使用Redis要做的是获取一个列表(最多包含M个项目)，并插入最新的新闻.如果您使用其他存储来存储数据，而Redis用作缓存，那么您要做的就是在发布新项目时填充视图(Redis和DB)两者.没有缓存失效.
但是，应用程序始终具有逻辑，因此，如果发现Redis列表为空(例如在启动后)，则可以从数据库重新创建初始视图.
通过使用智能缓存，与memcached相比，可以使用Redis以更有效的方式执行缓存，但是并非所有问题都适用于此模式.例如，HTML片段缓存可能无法从该技术中受益.
Redis can do everything that Memcached provides (LRU cache, item expiry, and now clustering in version 3.x+, currently in beta) or by tools like twemproxy. The performance is similar too. Morever, Redis adds persistence due to which you need not do cache warming in case of a server restart.
Reference to some old answers which compare Redis and Memcache, some of which favor Redis as replacement of Memcache (if already present in the stack):
In spite of this, on studying stacks of large web scale companies like Instagram, Pinterest, Twitter etc, I found that they use both Memcached and Redis for different purposes, not using Redis for primary caching. The primary cache is still Memcached, and Redis is used for its data structures based logical caching.
As of 2014, why is memcached still worth the pain to be added as additional component into your stack, when you already have a Redis component which can do everything that memcached can? What are the favorable points that incline the architects/engineers to still include memcached apart from already existing Redis?
Update :
For our platforms, we have completely discarded Memcached, and use redis for plain as well as logical caching requirements. Highly performant, flexible and reliable.
Some example scenarios:
- Listing all cached keys by a specific pattern, and read or delete their values. Very easy in redis, not doable ( easily ) in memcached.
- Storing a payload more than 1mb, easy to do in redis, requires slab size tweaks in memcached, which has performance side effects of its own.
- Easy snapshots of current cache content
- Redis cluster is production ready as well along with language drivers,hence clustered deployment is easy too.
The main reason I see today as an use-case for memcached over Redis is the superior memory efficiency you should be able to get with plain HTML fragments caching (or similar applications). If you need to store different fields of your objects in different memcached keys, then Redis hashes are going to be more memory efficient, but when you have a large number of key -> simple_string pairs, memcached should be able to give you more items per megabyte.
Other things which are good points about memcached:
- It is a very simple piece of code, so if you just need the functionality it provides, it is a reasonable alternative I guess, but I never used it in production.
- It is multi-threaded, so if you need to scale in a single-box setup, it is a good thing and you need to talk with just one instance.
I believe that Redis as a cache makes more and more sense as people move towards intelligent caching or when they try to preserve structure of the cached data via Redis data structures.
Comparison between Redis LRU and memcached LRU.
Both memcached and Redis don't perform real LRU evictions, but only an approximation of that.
Memcache eviction is per-size class and depends on the implementation details of its slab allocator. For example if you want to add an item which fits in a given size class, memcached will try to remove expired / not-recently-used items in that class, instead to try a global attempt to understand what is the object, regardless of its size, which is the best candidate.
Redis instead tries to pick a good object as a candidate for eviction when the maxmemory limit is reached, looking at all the objects, regardless of the size class, but is only able to provide an approximately good object, not the best object with the greater idle time.
The way Redis does this is by sampling a few objects, picking the one which was idle (not accessed) for the longest time. Since Redis 3.0 (currently in beta) the algorithm was improved and also takes a good candidates pools across evictions, so the approximation was improved. In the Redis documentation you can find a description and graphs with details about how it works.
Why memcached has a better memory footprint than Redis for simple string -> string maps.
Redis is a more complex piece of software, so values in Redis are stored in a way more similar to objects in a high level programming language: they have associated type, encoding, reference counting for memory management. This makes Redis internal structure good and manageable, but has an overhead compared to memcached which only deals with strings.
When Redis starts to be more memory efficient
Redis is able to store small aggregate data types in a special memory saving way. For example a small Redis Hash representing an object, is stored internally not with an hash table, but as a binary unique blob. So setting multiple fields per object into an hash is more efficient than storing N separated keys into memcached.
You can, actually, store an object into memcached as a single JSON (or binary-encoded) blob, but contrary to Redis, this will not allow you to fetch or update independent fields.
The advantage of Redis in the context of intelligent caching.
Because of Redis data structures, the usual pattern used with memcached of destroying objects when the cache is invalidated, to recreate it from the DB later, is a primitive way of using Redis.
For example, imagine you need to cache the latest N news posted into Hacker News in order to populate the "Newest" section of the site. What you do with Redis is to take a list (capped to M items) with the newest news inserted. If you use another store for your data, and Redis as a cache, what you do is to populate both the views (Redis and the DB) when a new item is posted. There is no cache invalidation.
However the application can always have logic so that if the Redis list is found to be empty, for example after a startup, the initial view can be re-created from the DB.
By using intelligent caching it is possible to perform caching with Redis in a more efficient way compared to memcached, but not all the problems are suitable for this pattern. For example HTML fragments caching may not benefit from this technique.
这篇关于如果redis已经是堆栈的一部分，为什么Memcached仍与Redis一起使用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
