Memcached与Redis？
本文翻译自：Memcached vs. Redis?
We're using a Ruby web-app with Redis server for caching. 我们正在将带Redis服务器的Ruby Web应用程序用于缓存。 Is there a point to test Memcached instead? 有没有要测试Memcached的地方呢？
What will give us better performance? 什么会给我们带来更好的性能？ Any pros or cons between Redis and Memcached? Redis和Memcached之间有什么优缺点？
Points to consider: 要考虑的要点：
- Read/write speed. 读/写速度。
- Memory usage. 内存使用情况。
- Disk I/O dumping. 磁盘I / O转储。
- Scaling. 缩放比例。
#1楼
参考：https://stackoom.com/question/iIjp/Memcached与Redis
#2楼
Memcached is good at being a simple key/value store and is good at doing key => STRING. Memcached擅长于简单的键/值存储，擅长做键=> STRING。 This makes it really good for session storage. 这使得它非常适合会话存储。
Redis is good at doing key => SOME_OBJECT. Redis擅长执行key => SOME_OBJECT。
It really depends on what you are going to be putting in there. 这实际上取决于您要放入的内容。 My understanding is that in terms of performance they are pretty even. 我的理解是，就性能而言，它们是相当均匀的。
Also good luck finding any objective benchmarks, if you do find some kindly send them my way. 如果您发现一些客观基准，也很幸运，如果您确实找到一些基准，请按我的方式发送。
#3楼
If you don't mind a crass writing style, Redis vs Memcached on the Systoilet blog is worth a read from a usability standpoint, but be sure to read the back & forth in the comments before drawing any conclusions on performance; 如果您不介意粗俗的写作风格，那么从可用性的角度来看，Systoilet博客上的Redis vs Memcached值得一读，但是在得出任何性能方面的结论之前，请务必先阅读注释中的来回内容。 there are some methodological problems (single-threaded busy-loop tests), and Redis has made some improvements since the article was written as well. 存在一些方法上的问题（单线程繁忙循环测试），自从撰写本文以来，Redis也进行了一些改进。
And no benchmark link is complete without confusing things a bit, so also check out some conflicting benchmarks at Dormondo's LiveJournal and the Antirez Weblog . 毫无疑问，没有任何基准测试链接是完整的，因此也请在Dormondo的LiveJournal和Antirez Weblog上查看一些相互矛盾的基准测试。
Edit -- as Antirez points out, the Systoilet analysis is rather ill-conceived. 编辑 -正如Antirez所指出的那样，Systoilet分析相当不完善。 Even beyond the single-threading shortfall, much of the performance disparity in those benchmarks can be attributed to the client libraries rather than server throughput. 即使超出单线程不足，那些基准测试中的许多性能差异也可以归因于客户端库而不是服务器吞吐量。 The benchmarks at the Antirez Weblog do indeed present a much more apples-to-apples (with the same mouth) comparison. 实际上，Antirez Weblog上的基准确实提供了更多的苹果对苹果（具有相同口）的比较。
#4楼
Summary (TL;DR) 摘要（TL; DR）
Updated June 3rd, 2017 2017年6月3日更新
Redis is more powerful, more popular, and better supported than memcached. 与memcached相比，Redis功能更强大，更受欢迎并且得到更好的支持。 Memcached can only do a small fraction of the things Redis can do. Memcached只能做Redis可以做的一小部分。 Redis is better even where their features overlap. 即使Redis的功能重叠，Redis也更好。
For anything new, use Redis. 对于任何新内容，请使用Redis。
Memcached vs Redis: Direct Comparison Memcached与Redis：直接比较
Both tools are powerful, fast, in-memory data stores that are useful as a cache. 两种工具都是功能强大，快速的内存中数据存储，可用作缓存。 Both can help speed up your application by caching database results, HTML fragments, or anything else that might be expensive to generate. 两者都可以通过缓存数据库结果，HTML片段或其他可能产生成本很高的内容来帮助加快应用程序的速度。
Points to Consider 要考虑的要点
When used for the same thing, here is how they compare using the original question's "Points to Consider": 当用于同一事物时，以下是它们如何使用原始问题的“要考虑的要点”进行比较：
- Read/write speed : Both are extremely fast. 读/写速度 ：两者都非常快。 Benchmarks vary by workload, versions, and many other factors but generally show redis to be as fast or almost as fast as memcached. 基准测试因工作负载，版本和许多其他因素而异，但通常显示redis与memcached一样快或几乎一样快。 I recommend redis, but not because memcached is slow. 我建议使用redis，但不是因为memcached速度慢。 It's not. 不是。
- Memory usage : Redis is better. 内存使用 ：Redis更好。
- memcached: You specify the cache size and as you insert items the daemon quickly grows to a little more than this size. memcached：您指定高速缓存大小，并且在插入项目时，守护程序会迅速增长到略大于该大小。 There is never really a way to reclaim any of that space, short of restarting memcached. 除了重新启动memcached之外，从来没有真正的方法可以回收任何空间。 All your keys could be expired, you could flush the database, and it would still use the full chunk of RAM you configured it with. 您所有的密钥都可能过期，您可以刷新数据库，并且该数据库仍将使用您为其配置的全部RAM。
- redis: Setting a max size is up to you. redis：设置最大大小由您决定。 Redis will never use more than it has to and will give you back memory it is no longer using. Redis将永远不会使用过多的内存，并将为您提供不再使用的内存。
- I stored 100,000 ~2KB strings (~200MB) of random sentences into both. 我将100,000个〜2KB字符串（〜200MB）的随机句子存储到了两者中。 Memcached RAM usage grew to ~225MB. Memcached RAM使用量增加到约225MB。 Redis RAM usage grew to ~228MB. Redis RAM使用量增加到〜228MB。 After flushing both, redis dropped to ~29MB and memcached stayed at ~225MB. 刷新两次后，redis降至〜29MB，memcached保持在〜225MB。 They are similarly efficient in how they store data, but only one is capable of reclaiming it. 它们在存储数据方面同样有效，但是只有一个能够回收数据。
- Disk I/O dumping : A clear win for redis since it does this by default and has very configurable persistence. 磁盘I / O转储 ：Redis显然是赢家，因为它默认情况下会这样做，并且具有非常可配置的持久性。 Memcached has no mechanisms for dumping to disk without 3rd party tools. 没有第3方工具，Memcached没有任何机制可以转储到磁盘。
- Scaling : Both give you tons of headroom before you need more than a single instance as a cache. 可扩展性 ：在需要多个实例作为缓存之前，两者都为您提供了大量的净空。 Redis includes tools to help you go beyond that while memcached does not. Redis包含的工具可帮助您超越此范围，而memcached则不会。
memcached 记忆快取
Memcached is a simple volatile cache server. Memcached是一个简单的易失性缓存服务器。 It allows you to store key/value pairs where the value is limited to being a string up to 1MB. 它允许您存储键/值对，其中值限制为最大1MB的字符串。
It's good at this, but that's all it does. 擅长此事，但仅此而已。 You can access those values by their key at extremely high speed, often saturating available network or even memory bandwidth. 您可以通过它们的键以极高的速度访问这些值，这通常会使可用的网络或什至是内存带宽饱和。
When you restart memcached your data is gone. 重新启动内存缓存后，您的数据不见了。 This is fine for a cache. 这对于缓存很好。 You shouldn't store anything important there. 您不应该在其中存储任何重要内容。
If you need high performance or high availability there are 3rd party tools, products, and services available. 如果您需要高性能或高可用性，则可以使用第三方工具，产品和服务。
redis Redis
Redis can do the same jobs as memcached can, and can do them better. Redis可以完成与memcached相同的工作，并且可以做得更好。
Redis can act as a cache as well. Redis也可以充当缓存 。 It can store key/value pairs too. 它也可以存储键/值对。 In redis they can even be up to 512MB. 在redis中，它们甚至可以达到512MB。
You can turn off persistence and it will happily lose your data on restart too. 您可以关闭持久性，并且在重新启动时也很可能会丢失数据。 If you want your cache to survive restarts it lets you do that as well. 如果您希望缓存能够继续运行，那么重新启动也可以。 In fact, that's the default. 实际上，这是默认设置。
It's super fast too, often limited by network or memory bandwidth. 它也非常快，通常受网络或内存带宽的限制。
If one instance of redis/memcached isn't enough performance for your workload, redis is the clear choice. 如果一个redis / memcached实例的性能不足以处理您的工作负载，那么redis是不二之选。 Redis includes cluster support and comes with high availability tools ( redis-sentinel ) right "in the box". Redis包括集群支持，并附带了“在盒子里”的高可用性工具（ redis-sentinel ）。 Over the past few years redis has also emerged as the clear leader in 3rd party tooling. 在过去的几年中，redis也已成为第三方工具的明确领导者。 Companies like Redis Labs, Amazon, and others offer many useful redis tools and services. Redis Labs，Amazon等公司提供许多有用的Redis工具和服务。 The ecosystem around redis is much larger. Redis周围的生态系统更大。 The number of large scale deployments is now likely greater than for memcached. 现在，大规模部署的数量可能会大于内存缓存的数量。
The Redis Superset Redis超集
Redis is more than a cache. Redis不仅仅是一个缓存。 It is an in-memory data structure server. 它是一个内存中的数据结构服务器。 Below you will find a quick overview of things Redis can do beyond being a simple key/value cache like memcached. 在下面，您将快速概览Redis可以做的事情，而不仅仅是像memcached这样的简单键/值缓存。 Most of redis' features are things memcached cannot do. Redis的大多数功能都是memcached无法做到的。
Documentation 文献资料
Redis is better documented than memcached. Redis的文档比memcached的文档更好。 While this can be subjective, it seems to be more and more true all the time. 尽管这可能是主观的，但它似乎一直在越来越真实。
redis.io is a fantastic easily navigated resource. redis.io是一个很棒的易于导航的资源。 It lets you try redis in the browser and even gives you live interactive examples with each command in the docs. 它使您可以在浏览器中尝试redis，甚至还可以通过文档中的每个命令为您提供实时的交互式示例。
There are now 2x as many stackoverflow results for redis as memcached. 现在，redis的堆栈溢出结果是内存缓存的2倍。 2x as many Google results. 是Google结果的2倍。 More readily accessible examples in more languages. 提供更多语言的更易于访问的示例。 More active development. 更积极的发展。 More active client development. 更积极的客户开发。 These measurements might not mean much individually, but in combination they paint a clear picture that support and documentation for redis is greater and much more up-to-date. 这些度量可能并没有太大的意义，但结合起来可以清楚地看到，有关Redis的支持和文档越来越多，而且是最新的。
Persistence 坚持不懈
By default redis persists your data to disk using a mechanism called snapshotting. 默认情况下，redis使用称为快照的机制将数据持久保存到磁盘。 If you have enough RAM available it's able to write all of your data to disk with almost no performance degradation. 如果您有足够的可用RAM，则可以将所有数据写入磁盘，而性能几乎不会降低。 It's almost free! 它几乎是免费的！
In snapshot mode there is a chance that a sudden crash could result in a small amount of lost data. 在快照模式下，突然崩溃可能会导致少量数据丢失。 If you absolutely need to make sure no data is ever lost, don't worry, redis has your back there too with AOF (Append Only File) mode. 如果您绝对需要确保没有任何数据丢失，请放心，redis也使用AOF（仅附加文件）模式支持您。 In this persistence mode data can be synced to disk as it is written. 在这种持久模式下，数据可以在写入时同步到磁盘。 This can reduce maximum write throughput to however fast your disk can write, but should still be quite fast. 这样可以将最大写入吞吐量降低到磁盘可以写入的速度，但是仍然应该非常快。
There are many configuration options to fine tune persistence if you need, but the defaults are very sensible. 如果需要，有许多配置选项可以微调持久性，但是默认设置非常明智。 These options make it easy to setup redis as a safe, redundant place to store data. 这些选项使将Redis设置为安全，冗余的数据存储位置变得容易。 It is a real database. 这是一个真实的数据库。
Many Data Types 许多数据类型
Memcached is limited to strings, but Redis is a data structure server that can serve up many different data types. Memcached仅限于字符串，但是Redis是一个数据结构服务器，可以提供许多不同的数据类型。 It also provides the commands you need to make the most of those data types. 它还提供了充分利用这些数据类型所需的命令。
Strings ( commands ) 字符串（ 命令 ）
Simple text or binary values that can be up to 512MB in size. 简单文本或二进制值，最大可为512MB。 This is the only data type redis and memcached share, though memcached strings are limited to 1MB. 这是唯一的数据类型redis和memcached共享，尽管memcached字符串限制为1MB。
Redis gives you more tools for leveraging this datatype by offering commands for bitwise operations, bit-level manipulation, floating point increment/decrement support, range queries, and multi-key operations. Redis通过提供用于按位操作，位级别操作，浮点增量/减量支持，范围查询和多键操作的命令，为您提供了更多利用此数据类型的工具。 Memcached doesn't support any of that. Memcached不支持任何一种。
Strings are useful for all sorts of use cases, which is why memcached is fairly useful with this data type alone. 字符串对于各种用例都是有用的，这就是为什么memcached仅对这种数据类型有用。
Hashes ( commands ) 散列（ 命令 ）
Hashes are sort of like a key value store within a key value store. 哈希有点像键值存储中的键值存储。 They map between string fields and string values. 它们在字符串字段和字符串值之间映射。 Field->value maps using a hash are slightly more space efficient than key->value maps using regular strings. 使用散列的Field-> value映射比使用常规字符串的key-> value映射在空间效率上略高。
Hashes are useful as a namespace, or when you want to logically group many keys. 散列可用作名称空间，或者在逻辑上将许多键分组时很有用。 With a hash you can grab all the members efficiently, expire all the members together, delete all the members together, etc. Great for any use case where you have several key/value pairs that need to grouped. 使用散列，您可以有效地捕获所有成员，一起使所有成员过期，一起删除所有成员，等等。对于需要将多个键/值对进行分组的用例而言，它非常有用。
One example use of a hash is for storing user profiles between applications. 哈希的一种示例用法是在应用程序之间存储用户配置文件。 A redis hash stored with the user ID as the key will allow you to store as many bits of data about a user as needed while keeping them stored under a single key. 使用用户ID作为密钥存储的redis哈希将允许您根据需要存储有关用户的数据，同时将其存储在单个密钥下。 The advantage of using a hash instead of serializing the profile into a string is that you can have different applications read/write different fields within the user profile without having to worry about one app overriding changes made by others (which can happen if you serialize stale data). 使用散列而不是将配置文件序列化为字符串的优点是，您可以让不同的应用程序在用户配置文件中读/写不同的字段，而不必担心一个应用程序覆盖其他应用程序所做的更改（如果您将陈旧序列化，则会发生这种情况数据）。
Lists ( commands ) 列表（ 命令 ）
Redis lists are ordered collections of strings. Redis列表是字符串的有序集合。 They are optimized for inserting, reading, or removing values from the top or bottom (aka: left or right) of the list. 它们经过优化，可从列表的顶部或底部（又名：左侧或右侧）插入，读取或删除值。
Redis provides many commands for leveraging lists, including commands to push/pop items, push/pop between lists, truncate lists, perform range queries, etc. Redis的提供许多命令为利用列表，包括列表之间弹出命令推/弹出的项目，推/，截断列表，执行范围查询等
Lists make great durable, atomic, queues. 列表使持久的，原子的队列成为可能。 These work great for job queues, logs, buffers, and many other use cases. 这些非常适合作业队列，日志，缓冲区和许多其他用例。
Sets ( commands ) 设置（ 命令 ）
Sets are unordered collections of unique values. 集是唯一值的无序集合。 They are optimized to let you quickly check if a value is in the set, quickly add/remove values, and to measure overlap with other sets. 它们经过优化，可让您快速检查值是否在集合中，快速添加/删除值，以及测量与其他集合的重叠。
These are great for things like access control lists, unique visitor trackers, and many other things. 这些功能非常适合访问控制列表，唯一的访客跟踪器以及许多其他功能。 Most programming languages have something similar (usually called a Set). 大多数编程语言都有类似的东西（通常称为Set）。 This is like that, only distributed. 就是这样，只有分布式。
Redis provides several commands to manage sets. Redis提供了一些命令来管理集合。 Obvious ones like adding, removing, and checking the set are present. 存在诸如添加，删除和检查集合之类的显而易见的内容。 So are less obvious commands like popping/reading a random item and commands for performing unions and intersections with other sets. 因此，不太明显的命令（例如弹出/读取随机项）以及用于执行与其他集合的并集和交集的命令。
Sorted Sets ( commands ) 排序集（ 命令 ）
Sorted Sets are also collections of unique values. 排序集也是唯一值的集合。 These ones, as the name implies, are ordered. 顾名思义，这些是有序的。 They are ordered by a score, then lexicographically. 它们按分数排序，然后按字典顺序排序。
This data type is optimized for quick lookups by score. 此数据类型经过优化，可按分数快速查找。 Getting the highest, lowest, or any range of values in between is extremely fast. 获得最高，最低或介于两者之间的任何值都非常快。
If you add users to a sorted set along with their high score, you have yourself a perfect leader-board. 如果将用户以及他们的高分添加到排序的集合中，则您将拥有一个完美的排行榜。 As new high scores come in, just add them to the set again with their high score and it will re-order your leader-board. 随着新的高分出现，只需将他们的高分再次添加到集合中，它将重新排列排行榜。 Also great for keeping track of the last time users visited and who is active in your application. 也非常适合跟踪用户上次访问的时间以及谁在您的应用程序中处于活动状态。
Storing values with the same score causes them to be ordered lexicographically (think alphabetically). 存储具有相同分数的值会使它们按字典顺序（按字母顺序思考）排序。 This can be useful for things like auto-complete features. 这对于自动完成功能等很有用。
Many of the sorted set commands are similar to commands for sets, sometimes with an additional score parameter. 许多排序的set 命令类似于set 命令 ，有时带有附加的score参数。 Also included are commands for managing scores and querying by score. 还包括用于管理分数和按分数查询的命令。
Geo 地缘
Redis has several commands for storing, retrieving, and measuring geographic data. Redis的具有几个命令用于存储，检索，以及测量的地理数据。 This includes radius queries and measuring distances between points. 这包括半径查询和测量点之间的距离。
Technically geographic data in redis is stored within sorted sets, so this isn't a truly separate data type. 从技术上讲，Redis中的地理数据存储在排序集中，因此这不是真正的独立数据类型。 It is more of an extension on top of sorted sets. 它更多地是对排序集的扩展。
Bitmap and HyperLogLog 位图和HyperLogLog
Like geo, these aren't completely separate data types. 像geo一样，这些也不是完全独立的数据类型。 These are commands that allow you to treat string data as if it's either a bitmap or a hyperloglog. 这些命令使您可以将字符串数据视为位图或超级日志。
Bitmaps are what the bit-level operators I referenced under Strings are for. 位图是我在“ Strings下引用的位级运算符的作用。 This data type was the basic building block for reddit's recent collaborative art project: r/Place . 这种数据类型是reddit最近的合作艺术项目r / Place的基本构建块。
HyperLogLog allows you to use a constant extremely small amount of space to count almost unlimited unique values with shocking accuracy. HyperLogLog允许您使用恒定的极少量空间以惊人的精度计算几乎无限的唯一值。 Using only ~16KB you could efficiently count the number of unique visitors to your site, even if that number is in the millions. 仅使用〜16KB，您就可以有效地计算网站唯一身份访问者的数量，即使该数量是数百万。
Transactions and Atomicity 交易和原子性
Commands in redis are atomic, meaning you can be sure that as soon as you write a value to redis that value is visible to all clients connected to redis. Redis中的命令是原子性的，这意味着您可以确保在向Redis写入值后，该值对于连接到Redis的所有客户端都是可见的。 There is no wait for that value to propagate. 无需等待该值传播。 Technically memcached is atomic as well, but with redis adding all this functionality beyond memcached it is worth noting and somewhat impressive that all these additional data types and features are also atomic. 从技术上讲，memcached也是原子的，但是redis在memcached之外添加了所有这些功能，值得注意的是，所有这些其他数据类型和功能也是原子的。
While not quite the same as transactions in relational databases, redis also has transactions that use "optimistic locking" ( WATCH / MULTI / EXEC ). 尽管与关系数据库中的事务不太相同，redis也具有使用“乐观锁定”的事务 （ WATCH / MULTI / EXEC ）。
Pipelining 流水线
Redis provides a feature called ' pipelining '. Redis提供了一个称为“ 流水线 ”的功能。 If you have many redis commands you want to execute you can use pipelining to send them to redis all-at-once instead of one-at-a-time. 如果要执行许多redis命令，则可以使用流水线将它们一次发送一次，而不是一次发送到redis。
Normally when you execute a command to either redis or memcached, each command is a separate request/response cycle. 通常，当您执行命令以进行redis或memcached时，每个命令都是一个单独的请求/响应周期。 With pipelining, redis can buffer several commands and execute them all at once, responding with all of the responses to all of your commands in a single reply. 使用流水线，redis可以缓冲多个命令并一次执行所有命令，并在一次回复中对所有命令的所有响应进行响应。
This can allow you to achieve even greater throughput on bulk importing or other actions that involve lots of commands. 这可以使您在批量导入或涉及许多命令的其他操作上获得更大的吞吐量。
Pub/Sub 发布/订阅
Redis has commands dedicated to pub/sub functionality , allowing redis to act as a high speed message broadcaster. Redis具有专用于发布/订阅功能的 命令 ，从而允许Redis充当高速消息广播者。 This allows a single client to publish messages to many other clients connected to a channel. 这允许单个客户端将消息发布到连接到通道的许多其他客户端。
Redis does pub/sub as well as almost any tool. Redis可以执行发布/订阅以及几乎所有工具。 Dedicated message brokers like RabbitMQ may have advantages in certain areas, but the fact that the same server can also give you persistent durable queues and other data structures your pub/sub workloads likely need, Redis will often prove to be the best and most simple tool for the job. 像RabbitMQ这样的专用消息代理可能在某些方面具有优势，但是事实是，同一台服务器还可以为您提供持久的持久队列以及您的发布/订阅工作负载可能需要的其他数据结构，Redis通常被证明是最好，最简单的工具为了工作。
Lua Scripting Lua脚本
You can kind of think of lua scripts like redis's own SQL or stored procedures. 您可以想到lua脚本，例如redis自己的SQL或存储过程。 It's both more and less than that, but the analogy mostly works. 它的大小不一，但这个类比大都可行。
Maybe you have complex calculations you want redis to perform. 也许您希望redis执行复杂的计算。 Maybe you can't afford to have your transactions roll back and need guarantees every step of a complex process will happen atomically. 也许您负担不起事务回滚，需要保证复杂过程的每一步都将自动发生。 These problems and many more can be solved with lua scripting. 这些问题以及更多问题可以通过lua脚本解决。
The entire script is executed atomically, so if you can fit your logic into a lua script you can often avoid messing with optimistic locking transactions. 整个脚本是原子执行的，因此，如果您可以使逻辑适合lua脚本，则通常可以避免混淆乐观的锁定事务。
Scaling 缩放比例
As mentioned above, redis includes built in support for clustering and is bundled with its own high availability tool called redis-sentinel . 如上所述，redis包括对集群的内置支持，并与它自己的称为redis-sentinel的高可用性工具捆绑在一起。
Conclusion 结论
Without hesitation I would recommend redis over memcached for any new projects, or existing projects that don't already use memcached. 毫不犹豫地，对于任何新项目或尚未使用memcached的现有项目，我建议在memcached上使用redis。
The above may sound like I don't like memcached. 以上听起来像我不喜欢memcached。 On the contrary: it is a powerful, simple, stable, mature, and hardened tool. 相反：它是一个功能强大，简单，稳定，成熟和强化的工具。 There are even some use cases where it's a little faster than redis. 甚至在某些用例中，它比redis快一点。 I love memcached. 我喜欢记忆快取。 I just don't think it makes much sense for future development. 我只是认为这对未来的发展没有多大意义。
Redis does everything memcached does, often better. Redis可以做memcached所做的一切，通常更好。 Any performance advantage for memcached is minor and workload specific. memcached的任何性能优势都是次要的且特定于工作负载。 There are also workloads for which redis will be faster, and many more workloads that redis can do which memcached simply can't. 还有一些工作量的Redis会更快，而Redis可以做的事情更多，而Memcached根本做不到。 The tiny performance differences seem minor in the face of the giant gulf in functionality and the fact that both tools are so fast and efficient they may very well be the last piece of your infrastructure you'll ever have to worry about scaling. 面对功能上的巨大鸿沟，微小的性能差异似乎微不足道，而且两个工具是如此之快和高效，它们很可能成为基础架构的最后一部分，您将不必担心扩展。
There is only one scenario where memcached makes more sense: where memcached is already in use as a cache. 只有一种情况使memcached更有意义：将memcached用作缓存。 If you are already caching with memcached then keep using it, if it meets your needs. 如果您已经使用memcached进行缓存，请在满足您需要的情况下继续使用它。 It is likely not worth the effort to move to redis and if you are going to use redis just for caching it may not offer enough benefit to be worth your time. 迁移到Redis可能不值得，如果您仅将Redis用于缓存，则可能无法提供足够的好处，值得您花时间。 If memcached isn't meeting your needs, then you should probably move to redis. 如果memcached不能满足您的需求，那么您可能应该改用Redis。 This is true whether you need to scale beyond memcached or you need additional functionality. 无论您需要扩展到内存缓存之外还是需要其他功能，这都是事实。
#5楼
Another bonus is that it can be very clear how memcache is going to behave in a caching scenario, while redis is generally used as a persistent datastore, though it can be configured to behave just like memcached aka evicting Least Recently Used items when it reaches max capacity. 另一个好处是，可以非常清楚地了解内存缓存在缓存情况下的表现方式，而redis通常用作持久性数据存储，尽管它可以配置为就像内存缓存一样，也就是在达到最大值时退出最近最少使用的项目容量。
Some apps I've worked on use both just to make it clear how we intend the data to behave - stuff in memcache, we write code to handle the cases where it isn't there - stuff in redis, we rely on it being there. 我研究过的一些应用程序都使用了这两种方法，只是为了弄清楚我们打算如何处理数据-内存缓存中的内容，我们编写代码来处理数据不存在的情况-Redis中的内容，我们依靠它在那里。
Other than that Redis is generally regarded as superior for most use cases being more feature-rich and thus flexible. 除此之外，对于大多数用例而言，Redis通常被认为是优越的，因为它们具有更多功能，因此更加灵活。
#6楼
Use Redis if 如果使用Redis
You require selectively deleting/expiring items in the cache. 您需要有选择地删除/过期缓存中的项目。 (You need this) （你需要这个）
You require the ability to query keys of a particular type. 您需要能够查询特定类型的键。 eq. eq。 'blog1:posts:*', 'blog2:categories:xyz:posts:*'. 'blog1：posts：*'，'blog2：categories：xyz：posts：*'。 oh yeah! 哦耶！ this is very important. 这个非常重要。 Use this to invalidate certain types of cached items selectively. 使用此选项有选择地使某些类型的缓存项无效。 You can also use this to invalidate fragment cache, page cache, only AR objects of a given type, etc. 您还可以使用它来使片段缓存，页面缓存，仅给定类型的AR对象等无效。
Persistence (You will need this too, unless you are okay with your cache having to warm up after every restart. Very essential for objects that seldom change) 持久性（您也将需要此持久性，除非您对每次重新启动后都必须预热的缓存没有问题。对于很少更改的对象非常重要）
Use memcached if 如果使用memcached
- Memcached gives you headached! Memcached让您头疼！
- umm... clustering? 嗯...群集吗？ meh. 嗯 if you gonna go that far, use Varnish and Redis for caching fragments and AR Objects. 如果要走的那么远，请使用Varnish和Redis缓存片段和AR对象。
From my experience I've had much better stability with Redis than Memcached 根据我的经验，Redis的稳定性要比Memcached好得多