本文介绍了“Redis比Memcached更受欢迎的原因是什么”的知识。很多人在实际案例的操作中会遇到这样的困难。让边肖带领你学习如何处理这些情况。希望大家认真阅读,学点东西!
要分析它们的区别,主要从以下几个方面对比:
线程模型
数据结构
消除策略
管道和交易
坚持
高度可用
聚类。
线程模型
要谈业绩,就要分析他们的服务模式。
Memcached采用多线程模型处理请求,基于IO复用技术,主线程接收请求后分发给子线程进行处理。
这样做的好处是,当一个请求很耗时时,它不会影响其他请求的处理。
当然缺点是CPU的多线程切换必然会有性能损失,同时多线程在访问共享资源时必然会锁定,也会在一定程度上降低性能。
Redis也使用IO复用技术,但它使用单线程模型来处理请求,从接收请求到在一个线程中处理数据。
这意味着在使用Redis时,一旦一个请求需要很长时间处理,整个Redis就会被阻塞,下一个请求要等到请求处理完毕并返回后才能处理。使用Redis时,必须避免复杂且耗时的操作。
单线程的优点是CPU上下文切换损失少,多线程访问资源没有锁竞争,缺点是不能利用CPU多核的性能。
由于Redis是内存数据库,其访问速度非常快,所以其性能瓶颈不在于CPU,而在于内存和网络带宽,这也是笔者采用单线程模型的主要原因。同时,单线程对程序开发非常友好,调试方便。开发多线程程序必然会增加调试难度。
因此,当我们使用key的业务数据相对较大时,Memcached的访问性能要优于Redis。如果密钥的数据很小,它们之间没有太大的区别。
“严格来说,Redis的单线程指的是处理请求的线程,它有其他线程在工作,比如用来异步处理耗时任务的其他线程。
Redis6.0进一步改进了多线程,在接收和发送请求时使用multiline,进一步提高了处理性能。
数据结构
Memcached支持简单的数据结构,只支持字符串类型的操作。值的大小限制必须在1MB以下,过期时间不能超过30天。
Redis支持的数据结构非常丰富。除了常用的数据类型string、list、hash、set和zset之外,还可以使用geo和hyperLogLog数据类型。
使用Memcached时,我们只能序列化数据并将其写入Memcached。然后从Memcached读取数据,再反序列化为我们需要的格式,只能是“一次总付”。
Redis可以针对不同的数据结构采用不同的操作方式,非常灵活。
列表:你可以很容易地建立一个链表或者把它作为一个队列。
Hash:灵活操作我们需要的字段,实行“全存零取”“零存零取”“零存零取”。
集合:建立一个不重复的集合,方便地进行差分和联合运算。
Zset:建立一个排行榜,或者有权重的列表。
Geo:用于地图相关业务,识别两个地方的坐标,计算两个地方的距离。
使用非常少的内存来计算紫外线。
总之,正因为提供了如此丰富的数据结构,Redis近年来在内存数据库领域取得了巨大的成就,为我们的业务发展提供了极大的便利。
淘汰策略
Memcached必须设置整个实例的内存上限。当数据达到上限时,触发LRU消除机制,优先消除不常用的数据。
但其数据消除机制存在一些问题:新写入的数据可能会被优先消除,这主要是其自身的内存管理设计机制造成的。
Redis没有限制。你必须设置内存上限。如果使用了足够的内存,Redis可以使用足够的内存。
同时,Redis提供了多种淘汰策略:
Volatile-lru:根据lru机制从过期密钥中废弃。
根据lru机制,所有的键都被消除了。
易失性-随机:在过期键中随机淘汰键
所有密钥-随机:在所有k
ey中随机淘汰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。
总结
从以上几个方面进行对比分析,总结如下表。
# | Memcached | Redis |
---|---|---|
线程模型 | 多线程 | 单线程 |
数据结构 | 仅支持string、value最大1M、过期时间不能超过30天 | string、list、hash、set、zset、geo、hyperLogLog |
淘汰策略 | LRU | LRU、LFU、随机等多种策略 |
管道与事务 | 不支持 | 支持 |
持久化 | 不支持 | 支持 |
高可用 | 不支持 | 主从复制+哨兵 |
集群化 | 客户端一致性哈希算法 | 主从复制+哨兵+固定哈希槽位 |
整体来说,Redis提供了非常丰富的功能,而且性能基本上与Memcached相差无几,这也是它最近这几年占领内存数据库鳌头的原因。
如果你的业务需要各种数据结构给予支撑,同时要求数据的高可用保障,那么选择Redis是比较合适的。
如果你的业务非常简单,只是简单的set/get,并且对于内存使用并不高,那么使用简单的Memcached足够。
“Redis要比Memcached更火的原因有哪些”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站,小编将为大家输出更多高质量的实用文章!
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/42406.html