几个认识误区.docx

Redis几个认识误区前几天微博发生了一起大的HYPERLINK"http://tech.sina.com.cn/i/2010-12-01/15324930344.shtml"系统故障，很多技术的朋友都比较关心，其中的原因不会超出JamesHamilton在OnDesigningandDeployingInternet-ScaleService(1)概括的那几个范围，James第一条经验“Designforfailure”是所有互联网架构成功的一个关键。互联网系统的工程理论其实非常简单，Jamespaper中内容几乎称不上理论，而是多条实践经验分享，每个公司对这些经验的理解及执行力决定了架构成败。题外话说完，最近又研究了HYPERLINK"http://code.google.com/p/redis/"Redis。去年曾做过一个HYPERLINK"http://timyang.net/data/mcdb-tt-redis/"MemcacheDB,TokyoTyrant,Redisperformancetest，到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的keyvalue存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用HBase(2))，当再回头再去看HYPERLINK"http://www.w3ccollege.org/category/redis"Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大家探讨。1.Redis是什么这个问题的结果影响了我们怎么用Redis。如果你认为Redis是一个keyvaluestore,那可能会用它来代替MySQL；如果认为它是一个可以持久化的cache,可能只是它保存一些频繁访问的临时数据。Redis是REmoteDIctionaryServer的缩写，在Redis在官方网站的的副标题是Apersistentkey-valuedatabasewithbuilt-innetinterfacewritteninANSI-CforPosixsystems，这个定义偏向keyvaluestore。还有一些看法则认为Redis是一个memorydatabase，因为它的高性能都是基于内存操作的基础。另外一些人则认为Redis是一个datastructureserver，因为Redis支持复杂的数据特性，比如List,Set等。对Redis的作用的不同解读决定了你对Redis的使用方式。互联网数据目前基本使用两种方式来存储，关系数据库或者keyvalue。但是这些互联网业务本身并不属于这两种数据类型，比如用户在社会化平台中的关系，它是一个list，如果要用关系数据库存储就需要转换成一种多行记录的形式，这种形式存在很多冗余数据，每一行需要存储一些重复信息。如果用keyvalue存储则修改和删除比较麻烦，需要将全部数据读出再写入。Redis在内存中设计了各种数据类型，让业务能够高速原子的访问这些数据结构，并且不需要关心持久存储的问题，从架构上解决了前面两种存储需要走一些弯路的问题。2.Redis不可能比Memcache快很多开发者都认为Redis不可能比HYPERLINK"http://www.w3ccollege.org/category/memcached"Memcached快，Memcached完全基于内存，而Redis具有持久化保存特性，即使是异步的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。HYPERLINK"http://monkey.org/~provos/libevent/"Libevent。和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epolleventloop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每