数据库
  当前位置:首页 > 技术支持 > 数据库
对Redis的理解
发布时间:2019-08-24 浏览:69次
        一、 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在内存中设计了各种数据类型,让业务能够高速原子的访问这些数据结构,并且不需要关心持久存储的问题,从架构上解决了前面两种存储需要走一些弯路的问题。
     
     二、Redis不可能比Memcache快?
      很多开发者都认为 Redis 不可能比 Memcached 快, Memcached 完全基于内存,而Redis 具有持久化保存特性,即使是异步的,Redis 也不可能比Memcached 快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因,目前想到的原因有这几方面。
     
      Libevent 和Memcached 不同,Redis并没有选择Libevent 。Libevent 为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent 中两个文件修改实现了自己的epoll event loop 。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev,但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure 。
     
      CAS 问题。CAS 是Memcached 中比较方便的一种防止竞争修改资源的方法。CAS 实现需要为每个cache key设置一个隐藏的cas token ,cas 相当value 版本号,每次set 会token 需要递增,因此带来CPU和内存的双重开销,虽然这些开销很小,但是到单机10G+ cache以及QPS 上万之后这些开销就会给双方相对带来一些细微性能差别。
     
     三、单台Redis的存放数据必须比物理内存小
      Redis 的数据全部放在内存带来了高速的性能,但是也带来一些不合理之处。比如一个中型网站有100万注册用户,如果这些资料要用Redis来存储,内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户,1周来访问过1次的也只有15万用户,因此全部100万用户的数据都放在内存有不合理之处,RAM需要为冷数据买单。
     
     这跟操作系统非常相似,操作系统所有应用访问的数据都在内存,但是如果物理内存容纳不下新的数据,操作系统会智能将部分长期没有访问的数据交换到磁盘,为新的应用留出空间。现代操作系统给应用提供的并不是物理内存,而是虚拟内存(Virtual Memory )的概念。
     
     基于相同的考虑,Redis 2.0 也增加了VM特性。让Redis 数据容量突破了物理内存的限制。并实现了数据冷热分离。
     
     四、Redis的VM实现是重复造轮子
     Redis 的VM依照之前的epoll实现思路依旧是自己实现。但是在前面操作系统的介绍提到OS也可以自动帮程序实现冷热数据分离,Redis只需要OS申请一块大内存,OS会自动将热数据放入物理内存,冷数据交换到硬盘,另外一个知名的“理解了现代操作系统(3)”的Varnish就是这样实现,也取得了非常成功的效果。
     
     作者antirez在解释为什么要自己实现VM中提到几个原因。主要OS的VM换入换出是基于Page 概念,比如OS VM1 个Page 是4K, 4K中只要还有一个元素即使只有1个字节被访问,这个页也不会被SWAP, 换入也同样道理,读到一个字节可能会换入4K无用的内存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block进程,也是导致Redis要自己实现VM原因之一。
     
     五、用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。
     
     六、使用aof代替snapshot
      Redis 有两种存储方式,默认是snapshot 方式,实现方法是定时将内存的快照(snapshot )持久化到硬盘,这种方法缺点是持久化之后如果出现crash则会丢失一段数据。因此在完美主义者的推动下作者增加了aof 方式。aof 即append only mode ,在写入内存数据的同时将操作命令保存到日志文件,在一个并发更改上万的系统中,命令日志是一个非常庞大的数据,管理维护成本非常高,恢复重建时间会非常长,这样导致失去aof 高可用性本意。另外更重要的是Redis 是一个内存数据结构模型,所有的优势都是建立在对内存复杂数据结构高效的原子操作上,这样就看出aof 是一个非常不协调的部分。
     
     其实aof 目的主要是数据可靠性及高可用性,在 Redis 中有另外一种方法来达到目的:Replication 。由于 Redis 的高性能,复制基本没有延迟。这样达到了防止单点故障及实现了高可用。
 
 
    
 
 
版权所有 © 2005-2019 安徽省艾佳信息技术有限公司 皖ICP备06002923号  皖公网安备 34019202000659号
地址:安徽省合肥市高新区天元路1号留学人员创业园1号楼205 电话:0551-64935878 邮箱:admin@ajsoft.cn