memcached和redis的比较
1 网络IO模型
Memcached是多线程,非阻塞IO复用的网络模型,分为监听主线程和worker子线程,监听线程监听网络连接,接受请求后,将连接描述字pipe 传递给worker线程,进行读写IO, 网络层使用libevent封装的事件库,多线程模型可以发挥多核作用,但是引入了cache coherency和锁的问题,比如,Memcached最常用的stats 命令,实际Memcached所有操作都要对这个全局变量加锁,进行计数等工作,带来了性能损耗。
(Memcached网络IO模型)
Redis使用单线程的IO复用模型,自己封装了一个简单的AeEvent事件处理框架,主要实现了epoll、kqueue和select,对于单纯只有IO操作来说,单线程可以将速度优势发挥到最大,但是Redis也提供了一些简单的计算功能,比如排序、聚合等,对于这些操作,单线程模型实际会严重影响整体吞吐量,CPU计算过程中,整个IO调度都是被阻塞住的。
2.内存管理方面
Memcached使用预分配的内存池的方式,使用slab和大小不同的chunk来管理内存,Item根据大小选择合适的chunk存储,内存池的方式可以省去申请/释放内存的开销,并且能减小内存碎片产生,但这种方式也会带来一定程度上的空间浪费,并且在内存仍然有很大空间时,新的数据也可能会被剔除,原因可以参考Timyang的文章:http://timyang.NET/data/Memcached-lru-evictions/
Redis使用现场申请内存的方式来存储数据,并且很少使用free-list等方式来优化内存分配,会在一定程度上存在内存碎片,Redis跟据存储命令参数,会把带过期时间的数据单独存放在一起,并把它们称为临时数据,非临时数据是永远不会被剔除的,即便物理内存不够,导致swap也不会剔除任何非临时数据(但会尝试剔除部分临时数据),这点上Redis更适合作为存储而不是cache。
3.数据一致性问题
Memcached提供了cas命令,可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令,并不能保证这点,不过Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断。
4.存储方式及其它方面
Memcached基本只支持简单的key-value存储,不支持枚举,不支持持久化和复制等功能
Redis除key/value之外,还支持list,set,sorted set,hash等众多数据结构,提供了KEYS
进行枚举操作,但不能在线上使用,如果需要枚举线上数据,Redis提供了工具可以直接扫描其dump文件,枚举出所有数据,Redis还同时提供了持久化和复制等功能。
5.关于不同语言的客户端支持
在不同语言的客户端方面,Memcached和Redis都有丰富的第三方客户端可供选择,不过因为Memcached发展的时间更久一些,目前看在客户端支持方面,Memcached的很多客户端更加成熟稳定,而Redis由于其协议本身就比Memcached复杂,加上作者不断增加新的功能等,对应第三方客户端跟进速度可能会赶不上,有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。
根据以上比较不难看出,当我们不希望数据被踢出,或者需要除key/value之外的更多数据类型时,或者需要落地功能时,使用Redis比使用Memcached更合适。
1. redis是什么
这个问题的结果影响了我们怎么用redis。如果你认为redis是一个key value store, 那可能会用它来代替mysql;如果认为它是一个可以持久化的cache, 可能只是它保存一些频繁访问的临时数据。redis是remote dictionary server的缩写,在redis在官方网站的的副标题是a persistent key-value database with built-in net interface written in ansi-c for posix systems,这个定义偏向key value store。还有一些看法则认为redis是一个memory database,因为它的高性能都是基于内存操作的基础。另外一些人则认为redis是一个data structure server,因为redis支持复杂的数据特性,比如list, set等。对redis的作用的不同解读决定了你对redis的使用方式。
互联网数据目前基本使用两种方式来存储,关系数据库或者key value。但是这些互联网业务本身并不属于这两种数据类型,比如用户在社会化平台中的关系,它是一个list,如果要用关系数据库存储就需要转换成一种多行记录的形式,这种形式存在很多冗余数据,每一行需要存储一些重复信息。如果用key value存储则修改和删除比较麻烦,需要将全部数据读出再写入。redis在内存中设计了各种数据类型,让业务能够高速原子的访问这些数据结构,并且不需要关心持久存储的问题,从架构上解决了前面两种存储需要走一些弯路的问题。
2. redis不可能比memcache快
很多开发者都认为redis不可能比memcached快,memcached完全基于内存,而redis具有持久化保存特性,即使是异步的,redis也不可能比memcached快。但是测试结果基本是redis占绝对优势。一直在思考这个原因,目前想到的原因有这几方面。
libevent。和memcached不同,redis并没有选择libevent。libevent为了迎合通用性造成代码庞大(目前redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议redis使用另外一个libevent高性能替代libev,但是作者还是坚持redis应该小巧并去依赖的思路。一个印象深刻的细节是编译redis之前并不需要执行./configure。
cas问题。cas是memcached中比较方便的一种防止竞争修改资源的方法。cas实现需要为每个cache key设置一个隐藏的cas token,cas相当value版本号,每次set会token需要递增,因此带来cpu和内存的双重开销,虽然这些开销很小,但是到单机10g+ cache以及qps上万之后这些开销就会给双方相对带来一些细微性能差别(5)。
3. 单台redis的存放数据必须比物理内存小
redis的数据全部放在内存带来了高速的性能,但是也带来一些不合理之处。比如一个中型网站有100万注册用户,如果这些资料要用redis来存储,内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户,1周来访问过1次的也只有15万用户,因此全部100万用户的数据都放在内存有不合理之处,ram需要为冷数据买单。
这跟操作系统非常相似,操作系统所有应用访问的数据都在内存,但是如果物理内存容纳不下新的数据,操作系统会智能将部分长期没有访问的数据交换到磁盘,为新的应用留出空间。现代操作系统给应用提供的并不是物理内存,而是虚拟内存(virtual memory)的概念。
基于相同的考虑,redis 2.0也增加了vm特性。让redis数据容量突破了物理内存的限制。并实现了数据冷热分离。
4. redis的vm实现是重复造轮子
redis的vm依照之前的epoll实现思路依旧是自己实现。但是在前面操作系统的介绍提到os也可以自动帮程序实现冷热数据分离,redis只需要os申请一块大内存,os会自动将热数据放入物理内存,冷数据交换到硬盘,另外一个知名的“理解了现代操作系统(3)”的varnish就是这样实现,也取得了非常成功的效果。
作者antirez在解释为什么要自己实现vm中提到几个原因(6)。主要os的vm换入换出是基于page概念,比如os vm1个page是4k, 4k中只要还有一个元素即使只有1个字节被访问,这个页也不会被swap, 换入也同样道理,读到一个字节可能会换入4k无用的内存。而redis自己实现则可以达到控制换入的粒度。另外访问操作系统swap内存区域时block进程,也是导致redis要自己实现vm原因之一。
5. 用get/set方式使用redis
作为一个key value存在,很多开发者自然的使用set/get方式来使用redis,实际上这并不是最优化的使用方法。尤其在未启用vm情况下,redis全部数据需要放入内存,节约内存尤其重要。
假如一个key-value单元需要最小占用512字节,即使只存一个字节也占了512字节。这时候就有一个设计模式,可以把key复用,几个key-value放入一个key中,value再作为一个set存入,这样同样512字节就会存放10-100倍的容量。
这就是为了节约内存,建议使用hashset而不是set/get的方式来使用redis,详细方法见参考文献(7)。
6. 使用aof代替snapshot
redis有两种存储方式,默认是snapshot方式,实现方法是定时将内存的快照(snapshot)持久化到硬盘,这种方法缺点是持久化之后如果出现crash则会丢失一段数据。因此在完美主义者的推动下作者增加了aof方式。aof即append only mode,在写入内存数据的同时将操作命令保存到日志文件,在一个并发更改上万的系统中,命令日志是一个非常庞大的数据,管理维护成本非常高,恢复重建时间会非常长,这样导致失去aof高可用性本意。另外更重要的是redis是一个内存数据结构模型,所有的优势都是建立在对内存复杂数据结构高效的原子操作上,这样就看出aof是一个非常不协调的部分。
其实aof目的主要是数据可靠性及高可用性,在redis中有另外一种方法来达到目的:replication。由于redis的高性能,复制基本没有延迟。这样达到了防止单点故障及实现了高可用。
小结
要想成功使用一种产品,我们需要深入了解它的特性。redis性能突出,如果能够熟练的驾驭,对国内很多大型应用具有很大帮助。
用户登录
还没有账号?立即注册
用户注册
投稿取消
文章分类: |
|
还能输入300字
上传中....