共计 3213 个字符，预计需要花费 9 分钟才能阅读完成。
本篇内容介绍了“Redis 要比 Memcached 更火的原因有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
要分析它们的区别，主要从以下几个方面对比：
线程模型
数据结构
淘汰策略
管道与事务
持久化
高可用
集群化
线程模型
要说性能，必须要分析它们的服务模型。
Memcached 处理请求采用多线程模型，并且基于 IO 多路复用技术，主线程接收到请求后，分发给子线程处理。
这样做好的好处是，当某个请求处理比较耗时，不会影响到其他请求的处理。
当然，缺点是 CPU 的多线程切换必然存在性能损耗，同时，多线程在访问共享资源时必然要加锁，也会在一定程度上降低性能。
Redis 同样采用 IO 多路复用技术，但它处理请求采用是单线程模型，从接收请求到处理数据都在一个线程中完成。
这意味着使用 Redis，一旦某个请求处理耗时比较长，那么整个 Redis 就会阻塞住，直到这个请求处理完成后返回，才能处理下一个请求，使用 Redis 时一定要避免复杂的耗时操作。
单线程的好处是，少了 CPU 的上下文切换损耗，没有了多线程访问资源的锁竞争，但缺点是无法利用 CPU 多核的性能。
由于 Redis 是内存数据库，它的访问速度非常地快，所以它的性能瓶颈不在于 CPU，而在于内存和网络带宽，这也是作者采用单线程模型的主要原因。同时，单线程对于程序开发非常友好，调试起来也很方便。开发多线程程序必然会增加一定的调试难度。
因此，当我们的业务使用 key 的数据比较大时，Memcached 的访问性能要比 Redis 好一些。如果 key 的数据比较小，两者差别并不大。
“ 严格来说，Redis 的单线程指的是处理请求的线程，它本身还有其他线程在工作，例如有其他线程用来异步处理耗时的任务。
Redis6.0 又进一步完善了多线程，在接收请求和发送请求时使用多线，进一步提高了处理性能。
数据结构
Memcached 支持的数据结构很单一，仅支持 string 类型的操作。并且对于 value 的大小限制必须在 1MB 以下，过期时间不能超过 30 天。
而 Redis 支持的数据结构非常丰富，除了常用的数据类型 string、list、hash、set、zset 之外，还可以使用 geo、hyperLogLog 数据类型。
使用 Memcached 时，我们只能把数据序列化后写入到 Memcached 中。然后再从 Memcached 中读取数据，再反序列化为我们需要的格式，只能“整存整取”。
而 Redis 对于不同的数据结构可以采用不同的操作方法，非常灵活。
list：可以方便的构建一个链表，或者当作队列使用
hash：灵活地操作我们需要的字段，进行“整存零取”、“零存整取”以及“零存零取”
set：构建一个不重复的集合，并方便地进行差集、并集运算
zset：构建一个排行榜，或带有权重的列表
geo：用于地图相关的业务，标识两个地点的坐标，以及计算它们的距离
hyperLogLog：使用非常少的内存计算 UV
总之，Redis 正是因为提供了这么丰富的数据结构，近几年在内存数据库领域大放异彩，为我们的业务开发提供了极大的便利。
淘汰策略
Memcached 必须设置整个实例的内存上限，数据达到上限后触发 LRU 淘汰机制，优先淘汰不常用使用的数据。
但它的数据淘汰机制存在一些问题：刚写入的数据可能会被优先淘汰掉，这个问题主要是它本身内存管理设计机制导致的。
Redis 没有限制必须设置内存上限，如果内存足够使用，Redis 可以使用足够大的内存。
同时 Redis 提供了多种淘汰策略：
volatile-lru：从过期 key 中按 LRU 机制淘汰
allkeys-lru：在所有 key 中按 LRU 机制淘汰
volatile-random：在过期 key 中随机淘汰 key
allkeys-random：在所有 key 中随机淘汰 key
volatile-ttl：优先淘汰最近要过期的 key
volatile-lfu：在所有 key 中按 LFU 机制淘汰
allkeys-lfu：在过期 key 中按 LFU 机制淘汰
我们可以针对业务场景，使用不同的数据淘汰策略。
管道与事务
Redis 还支持管道功能，客户端一次性打包发送多条命令到服务端，服务端依次处理客户端发来的命令。这样可以减少来回往来的网络 IO 次数，提供高访问性能。
另外它还支持事务，这里所说的事务并不是 MySQL 那样严格的事务模型，这种事务模型是 Redis 特有的。
一般事务会配合管道一块使用，客户端一次性打包发送多条命令到服务端，并且标识这些命令必须严格按顺序执行，不能被其他客户端打断。同时执行事务之前，客户端可以告诉服务端某个 key 稍后会进行相关操作，如果这个客户端在操作这个 key 之前，有其他客户端对这个 key 进行更改，那么当前客户端在执行这些命令时会放弃整个事务操作，保证一致性。
持久化
Memcached 不支持数据的持久化，如果 Memcached 服务宕机，那么这个节点的数据将全部丢失。
Redis 支持将数据持久化磁盘上，提供 RDB 和 AOF 两种方式：
RDB：将整个实例中的数据快照到磁盘上，全量持久化
AOF：把每一个写命令持久到磁盘，增量持久化
Redis 使用这两种方式相互配合，完成数据完整性保障，最大程度降低服务宕机导致的数据丢失问题。
高可用
Memcached 没有主从复制架构，只能单节点部署，如果节点宕机，那么该节点数据全部丢失。业务需要对这种情况做兼容处理，当某个节点不可用时，把数据写入到其他节点以降低对业务的影响。
Redis 拥有主从复制架构，两个节点组成主从架构，从可以实时同步主的数据，提高整个 Redis 服务的可用性。
同时 Redis 还提供了哨兵节点，在主节点宕机时，主动把从节点提升为主节点，继续提供服务。
主从两个节点还可以提供读写分离功能，进一步提高程序访问的性能。
集群化
Memcached 和 Redis 都是由多个节点组成集群对外提供服务，但他们的机制也有所不同。
Memcached 的集群化是在客户端采用一致性哈希算法向指定节点发送数据，当一个节点宕机时，其他节点会分担这个节点的请求。
而 Redis 集群化采用的是每个节点维护一部分虚拟槽位，通过 key 的哈希计算，将 key 映射到具体的虚拟槽位上，这个槽位再映射到具体的 Redis 节点。
同时每个 Redis 节点都包含至少一个从节点，组成主从架构，进一步提高每个节点的高可用能力。
当增加或下线节点时，需要手动触发数据迁移，重新进行哈希槽位映射。
Redis 官方的集群化解决方案为 Redis cluster，它采用无中心化的设计。另外也有第三方的采用中心化设计 proxy 方式的集群化解决方案，例如 Codis、Twemproxy。
总结
从以上几个方面进行对比分析，总结如下表。
#MemcachedRedis 线程模型多线程单线程数据结构仅支持 string、value 最大 1M、过期时间不能超过 30 天 string、list、hash、set、zset、geo、hyperLogLog 淘汰策略 LRULRU、LFU、随机等多种策略管道与事务不支持支持持久化不支持支持高可用不支持主从复制 + 哨兵集群化客户端一致性哈希算法主从复制 + 哨兵 + 固定哈希槽位
整体来说，Redis 提供了非常丰富的功能，而且性能基本上与 Memcached 相差无几，这也是它最近这几年占领内存数据库鳌头的原因。
如果你的业务需要各种数据结构给予支撑，同时要求数据的高可用保障，那么选择 Redis 是比较合适的。
如果你的业务非常简单，只是简单的 set/get，并且对于内存使用并不高，那么使用简单的 Memcached 足够。
“Redis 要比 Memcached 更火的原因有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
