前几天微博发生了一起大的系统故障,很多技术的朋友都比较关心,其中的原因不会超出James Hamilton在On Designing and Deploying Internet-Scale Service(1)概括的那几个范围,James第一条经验“Design for failure”是所有互联网架构成功的一个关键。互联网系统的工程理论其实非常简单,James paper中内容几乎称不上理论,而是多条实践经验分享,每个公司对这些经验的理解及执行力决定了架构成败。
题外话说完,最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test,到目前为止,这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑,从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用HBase(2)),当再回头再去看Redis,发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人,国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外,业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大家探讨。
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性能突出,如果能够熟练的驾驭,对国内很多大型应用具有很大帮助。希望更多同行加入到Redis使用及代码研究行列。
参考文献
- On Designing and Deploying Internet-Scale Service(PDF)
- Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month
- What’s wrong with 1975 programming
- Linux epoll is now supported(Google Groups)
- CAS and why I don’t want to add it to Redis(Google Groups)
- Plans for Virtual Memory(Google Groups)
- Full of keys(Salvatore antirez Sanfilippo)
-EOF-
上一篇博文多IDC数据时序问题及方法论在新浪微博上面有更多讨论及留言,有兴趣可以去围观。http://t.sina.com.cn/10503/zF0tex7z7b(需登录)
[…] 国内: Redis几个认识误区 Redis新的存储模式diskstore Redis使用系列:配置文件篇 Redis在Windows下的使用 […]
云集国内redis大佬的QQ群正在招募各路redis朋友,不管你是正在使用redis,还是在研究redis,或者是对redis感兴趣,你都可以加入到我们的阵营。大家一起讨论redis各类用法,key-value、list、set、map使用,redis优化、内存监控、主从配置等等问题,这里都会有高手给你解决。
注意啦,国内顶尖级别的redisQQ群是 43016055
访问操作系统的 SWAP 需要 block 进程。实际上自己实现 VM,访问存在磁盘上的冷数据时肯定是要 block 进程的。所以这点理由有点牵强。
[…] 1. Redis官方文档对VM的使用提出了一些建议: 当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大. 当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value. 最好使用linux ext3 等对稀疏文件支持比较好的文件系统保存你的swap文件. vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数.如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证. 2. 关于Redis新的存储模式diskstore(http://timyang.net/data/redis-diskstore),节选: 适合Web 2.0数据访问最佳的方式就是完全基于内存,比如用Memcached或者Redis snapshot方式。但是更多的业务场景是数据规模会超过RAM容量,因此有几种不同的设计模式。 VM方式: 将数据分页存放,由应用(如Redis)或者操作系统(如Varnish)将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中。应用实现VM缺点是代码逻辑复杂,如果业务上冷热数据边界并不分明,则换入换出代价太高,系统整体性能低。不少抢鲜的网友在微博上也反馈过使用VM种种不稳定情况。操作系统实现缺点在于主要OS的VM换入换出是基于Page概念,比如OS VM1个Page是4K, 4K中只要还有一个元素即使只有1个字节被访问,这个页也不会被SWAP,换入也同样道理,读到一个字节可能会换入4K无用的内存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block进程,也是导致Redis要自己实现VM原因之一。 磁盘方式: 所有的数据读写访问都是基于磁盘,由操作系统来只能的缓存访问的数据。由于现代操作系统都非常聪明,会将频繁访问的数据加入到内存中,因此应用并不需要过多特殊逻辑。MongoDB就是这种设计方式。这种方式也有一些已知的缺点,比如操作MMap写入磁盘由操作系统控制,操作系统先写哪里后写哪里应用并不知情,如果写入过程中发生了crash则数据一致性会存在问题。这个也是MongoDB饱受争议的单机Durability问题 硬盘存储+cache方式: 实际原理和mysql+memcache方式类似,只不过将两者功能合二为一到一个底层服务中,简化了调用。 在上面几种方式中,除去VM,antirez觉得MongoDB方式也不太适合,因此选择了disktore方式来实现新的磁盘存储,具体细节是 1) 读操作,使用read through以及LRU方式。内存中不存在的数据从磁盘拉取并放入内存,内存中放不下的数据采用LRU淘汰。 2) 写操作,采用另外spawn一个线程单独处理,写线程通常是异步的,当然也可以把cache-flush-delay配置设成0,Redis尽量保证即时写入。但是在很多场合延迟写会有更好的性能,比如一些计数器用Redis存储,在短时间如果某个计数反复被修改,Redis只需要将最终的结果写入磁盘。这种做法作者叫per key persistence。由于写入会按key合并,因此和snapshot还是有差异,disk store并不能保证时间一致性。由于写操作是单线程,即使cache-flush-delay设成0,多个client同时写则需要排队等待,如果队列容量超过cache-max-memory,Redis设计会进入等待状态,造成调用方卡住。Google Group上有热心网友迅速完成了压力测试,当内存用完之后,set每秒处理速度从25k下降到10k再到后来几乎卡住。虽然通过增加cache-flush-delay可以提高相同key重复写入性能;通过增加cache-max-memory可以应对临时峰值写入。但是diskstore写入瓶颈最终还是在IO。 3) rdb 和新 diskstore 格式关系 rdb是传统Redis内存方式的存储格式,diskstore是另外一种格式,那两者关系如何? 1.通过BGSAVE可以随时将diskstore格式另存为rdb格式,而且rdb格式还用于Redis复制以及不同存储方式之间的中间格式。 2.通过工具可以将rdb格式转换成diskstore格式。 […]
redis java分群 163264749 是java的
Redis PHP分群 163265386 是php的
redis c,c++,c#分群 163269313 是.net的
redis shell,python群 69287882 是shell,python,prel脚本类的
非常好,尤其是对于redis的性能超过memcached的描述。
[…] 关于redis用途及作用,推荐看:http://timyang.net/data/redis-misunderstanding/ […]
写得非常好,我们也准备使用REDIS,对一些概念又更加清晰
[…] 这个问题看似可笑,其实不然,我很赞同Timyang的观点,架构者对Redis的理解不同、定位也不同,决定了Redis在整个系统结构中会扮演什么样的角色。我总结一下,主流有3种理解: […]
very good!
happy to see it!
[…] of keys(Salvatore antirez Sanfilippo) (本文转载自:http://timyang.net/data/redis-misunderstanding/) 分享到: var jiathis_config = […]
[…] Redis几个认识误区(原文地址:http://timyang.net/data/redis-misunderstanding/) Saturday, Dec 4th, 2010 by Tim | Tags: key value store, redis […]
看了评论,我都不怎么敢用了,本身出于用缓存来减少服务器的压力,而不是用NoSQL,这货貌似是NoSQL。。
[…] 1. Redis官方文档对VM的使用提出了一些建议: 当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大. 当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value. 最好使用linux ext3 等对稀疏文件支持比较好的文件系统保存你的swap文件. vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数.如果设置为0,那么所有对swap文件的操作都是串行的.可能会造成比较长时间的延迟,但是对数据完整性有很好的保证. 2. 关于Redis新的存储模式diskstore(http://timyang.net/data/redis-diskstore),节选: 适合Web 2.0数据访问最佳的方式就是完全基于内存,比如用Memcached或者Redis snapshot方式。但是更多的业务场景是数据规模会超过RAM容量,因此有几种不同的设计模式。 VM方式: 将数据分页存放,由应用(如Redis)或者操作系统(如Varnish)将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中。应用实现VM缺点是代码逻辑复杂,如果业务上冷热数据边界并不分明,则换入换出代价太高,系统整体性能低。不少抢鲜的网友在微博上也反馈过使用VM种种不稳定情况。操作系统实现缺点在于主要OS的VM换入换出是基于Page概念,比如OS VM1个Page是4K, 4K中只要还有一个元素即使只有1个字节被访问,这个页也不会被SWAP,换入也同样道理,读到一个字节可能会换入4K无用的内存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block进程,也是导致Redis要自己实现VM原因之一。 磁盘方式: 所有的数据读写访问都是基于磁盘,由操作系统来只能的缓存访问的数据。由于现代操作系统都非常聪明,会将频繁访问的数据加入到内存中,因此应用并不需要过多特殊逻辑。MongoDB就是这种设计方式。这种方式也有一些已知的缺点,比如操作MMap写入磁盘由操作系统控制,操作系统先写哪里后写哪里应用并不知情,如果写入过程中发生了crash则数据一致性会存在问题。这个也是MongoDB饱受争议的单机Durability问题 硬盘存储+cache方式: 实际原理和mysql+memcache方式类似,只不过将两者功能合二为一到一个底层服务中,简化了调用。 在上面几种方式中,除去VM,antirez觉得MongoDB方式也不太适合,因此选择了disktore方式来实现新的磁盘存储,具体细节是 1) 读操作,使用read through以及LRU方式。内存中不存在的数据从磁盘拉取并放入内存,内存中放不下的数据采用LRU淘汰。 2) 写操作,采用另外spawn一个线程单独处理,写线程通常是异步的,当然也可以把cache-flush-delay配置设成0,Redis尽量保证即时写入。但是在很多场合延迟写会有更好的性能,比如一些计数器用Redis存储,在短时间如果某个计数反复被修改,Redis只需要将最终的结果写入磁盘。这种做法作者叫per key persistence。由于写入会按key合并,因此和snapshot还是有差异,disk store并不能保证时间一致性。由于写操作是单线程,即使cache-flush-delay设成0,多个client同时写则需要排队等待,如果队列容量超过cache-max-memory,Redis设计会进入等待状态,造成调用方卡住。Google Group上有热心网友迅速完成了压力测试,当内存用完之后,set每秒处理速度从25k下降到10k再到后来几乎卡住。虽然通过增加cache-flush-delay可以提高相同key重复写入性能;通过增加cache-max-memory可以应对临时峰值写入。但是diskstore写入瓶颈最终还是在IO。 3) rdb 和新 diskstore 格式关系 rdb是传统Redis内存方式的存储格式,diskstore是另外一种格式,那两者关系如何? 1.通过BGSAVE可以随时将diskstore格式另存为rdb格式,而且rdb格式还用于Redis复制以及不同存储方式之间的中间格式。 2.通过工具可以将rdb格式转换成diskstore格式。 […]
[…] Redis几个认识误区 […]
[…] Redis误区 http://timyang.net/data/redis-misunderstanding/ […]
[…] 原文链接:http://timyang.net/data/redis-misunderstanding/ […]
[…] http://timyang.net/data/redis-misunderstanding/ […]
[…] Redis几个认识误区 […]
[…] 来源:http://timyang.net/data/redis-misunderstanding/ 此条目发表在 NoSQL 分类目录。将固定链接加入收藏夹。 ← 我到底需要多少流量的主机? […]
[…] http://timyang.net/data/redis-misunderstanding/ 作者:惊峰 | 分类目录:系统应用 | 标签: redis […]
[…] 转自Tim[后端技术] + 自己加工下介绍与vm部分。 […]
[…] http://timyang.net/data/redis-misunderstanding/ […]
[…] 转自:微博首席架构师-杨卫华 的博客 Tim[后端技术]|http://timyang.net/data/redis-misunderstanding/ […]
[…] http://timyang.net/data/redis-misunderstanding/ 未分类分发, 均衡器, 挂了, 是一个, 服务器, 自己的, 请求, 负载, 负载均衡, 静态 ← Terracotta 3.2.1简介 (一) wordpress 分类显示分类下文章的数目 → 发表评论?0 条评论。 […]
学习了,刚开始看redis。
MySQL 最新开发版 5.6.6 目前尚未发布,但从官网给出的 CHANGES 文档可得知,该版本将内嵌 memcached 的支持,以后可以用No SQL的方式使用mysql,在数据库中充分利用memcached的优点。缓存和数据的一致性问题不再是个问题。
[…] http://timyang.net/data/redis-misunderstanding/ […]
[…] Redis性能突出,但在去年的时候我们有过一次失败的经验,近期第四城技术团队再次对Redis做了一些学习、研究和测试,也正尝试着应用于我们社区论坛的一些数据存储,今天在微博技术团队博客中看到这篇文章,分享到这里供大家一起学习!转自:微博首席架构师-杨卫华 的博客 Tim[后端技术]|http://timyang.net/data/redis-misunderstanding/ […]
DDDDD!!