NoSQL的学习(1)——Redis学习笔记

屌丝最近开始学习大数据处理,主要是NoSQL数据库的学习。

Redis是一种“键值数据库”(key-value),目前新浪微博的数据存储就是使用Redis。其他的NoSQL数据库正在逐步学习中。

Redis是一种内存数据库,整个数据库加载在内存中进行数据操作,并通过异步操作将数据写回磁盘实现数据的持久化。Redis的性能非常出色,每秒可以处理超过10万次的读写操作。

Redis是一个基于内存的Key-Value存储的NoSQL引擎。与其他Key-Value引擎不同,Redis的Value可以支持多种数据结构,如哈希、List、Set等。但是一直以来,Redis的持久化方案并非完美。从rdb到aof,再到已经夭折的vm,Redis的持久化之路一直走的很坎坷。由于持久化的不完美,以及全部在内存中处理数据的特性,使得Redis在面对数据量持续增长的时候,总体拥有成本(TCO)也随之线性增长。

基于相同的考虑,Redis 2.0也增加了VM特性。让Redis数据容量突破了物理内存的限制。并实现了数据冷热分离。

Redis的数据全部放在内存带来了高速的性能,但是也带来一些不合理之处。比如一个中型网站有100万注册用户,如果这些资料要用Redis来存储,内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户,1周来访问过1次的也只有15万用户,因此全部100万用户的数据都放在内存有不合理之处,RAM需要为冷数据买单。

新浪微博从2010年底开始使用Redis,各项业务指标在经历了2011年全年的疯狂增长之后,他们发现在很多场合Redis已经不再适用。唐福林认为,Redis适用于数据量不太大的存储,以及数据量大的缓存。在选择数据存储介质的时候要分清数据量的大小和数据的冷热。小而热的数据适合使用内存,大而冷的数据适合使用磁盘,大而热的数据是否适合使用SSD,仍待探讨。

(以上内容节选自http://tech.it168.com/a2012/0415/1337/000001337489.shtml,http://timyang.net/data/redis-misunderstanding/ )

 

下面是meshin公司用Redis的方式及扩展方法(参考自:http://petrohi.me/post/6323289515/scaling-redis )

1、 一共是16台redis数据服务器,每台服务器是96G内存,这样一共是1.3T的内存容量
2、每台服务器有16个核,每台机器上运行了160个redis实例(因为一个redis实例最多只能占用一个核,所以需要跑多个实例来充分利用机器的资源)
3、同一份数据会复制到另外两台机器上,采用redis自带的数据复制机制对数据进行复制。写到主redis实例上,轮询读取写实例和另外两个读实例
4、另外有几台机器上面也运行redis实例,以保存实例IP地址、实例端口、负责的数据位置、健康状态信息。它们管这个叫目录服务。也是采用redis的数据复制机制复制目录信息到多个目录redis实例上。
5、目录服务大部分是读取,修改的情况比较少,所以读写比例非常高。应用程序采取轮询的方式轮流访问主目录实例和多个辅目录实例
6、当应用程序发现一个实例没有响应,它会去修改该实例对应的目录信息,将健康状态标专为离线,这样别的应用和实例都不会再去访问出问题的实例
7、当数据分片对应的辅redis实例出错离线时,该分片对应的数据仍然能够正常读取,只是冗余性下降了
8、当数据分片对应的主redis实例出错离线时,该分片对应的数据只能提供读取服务,数据不能再被修改
9、运行了一个特殊的代理进程,它不断查询目录节点,当发现有一个分片的主redis实例离线时,由它来推动从剩下的辅redis实例中选举一个做新的主redis实例,并配置别的实例是它的辅redis实例,然后再清掉分片对应的目录信息,从只读模式中恢复成读写模式。这个过程还没有做到完全的自动化,他们有计划做到完全自动地恢复
10、所有redis数据服务器用单独的网卡接到专用的网络中,里面有网络存储,这样所有redis实例会定时将数据快照存到网络存储上
11、因为redis保存数据快照需要额外的内存,具体数据跟写的比例和io速度有关系,这样如果一台redis数据服务器上的所有实例同时都写快照,这样会因内存的占用而影响服务。为了避免这个问题,他们的作法是在每台redis数据服务器运行一个单独的进程,轮流访问上面的每个实例,调用save命令来保存快照
12、采用一致性哈希算法按用户邮件名,将用户索引数据分片到对应的redis实例上。具体是用sha1算法将邮箱名64位无符号整数空间内

5374d6e3ta5f92a7a6e85&690

按实例数平均分配64位空间,每个实例占用相同的区间大小。用sha1计算用户邮箱对应的数值,按顺时针方面寻找最近的实例,由该实例负责对应的用户

5374d6e3ta5f92c0b37fd&690

 

13、他们对比多个哈希函数,最后选定sha1,因为它能均匀分布用户到多个redis实例上
14、当增加新的实例时,它会占据在两个实例的中间位置。但不是从老的实例中搬移数据到新的节点上。当一个实例没有对应的数据时,会按顺时针方向转发请求到下一个实例

5374d6e3ta5f92eaeff8d&690

 

15、当一个实例内存已经用满,它也会按顺时针方向转发请求给下一个实例

5374d6e3ta5f930e0a8eb&690

16、在应用端会缓存用户对应的实例信息,这样避免每次都进行上面的定位和转发步骤
17、没有使用libredis(采用了ketama)原因是自己写的方式比较好一步一步地跟踪,同时能解决redis环境下的特定的问题
18、一致性哈希采用C++实现,另外用了一些tcl脚本。开源了Redis C++客户端库, 计划把一致性哈希实现也发到这个开源客户端中

 

5条评论


  1. 刀同学也在学习Redis呢!

    话说Redis的源码的更新速度太快了,记得11年我第一次看的时候只有2W行还不到,之后EMC聘用了antirez让他全职开发Redis,从此代码量爆炸式增长,几乎每天都会更新100行以上,真受不了。。。

    如果读源码的话, https://github.com/huangz1990 huangz同学的源码注释还是不错的

    Google Chrome 28.0.1500.95 Google Chrome 28.0.1500.95 GNU/Linux x64 GNU/Linux x64
    回复

  2. 我神马只有我一个人评论?

    Google Chrome 28.0.1500.95 Google Chrome 28.0.1500.95 GNU/Linux x64 GNU/Linux x64
    回复

    1. 估计是因为内容的门槛都有点高吧。

      我不是很了解NoSQL数据库,这是一类数据库的泛称吧?与常见的relation-based model数据库区分? NoSQL的出现是为了解决大量并发请求下老式数据库存在性能瓶颈问题么?

      FYI: huangz的redis源码注释经常能看到有人推荐~

      Google Chrome 28.0.1500.95 Google Chrome 28.0.1500.95 Windows 7 x64 Edition Windows 7 x64 Edition
      回复

    2. 门槛高+1
      买了本mongoDB还只看了一点点,这应该都同属NoSql吧?

      Google Chrome 28.0.1500.72 Google Chrome 28.0.1500.72 Windows XP Windows XP
      回复

  3. 介个。。。门槛很高么。。。 不懂也完全可以吐槽啊,就像我一样

    Google Chrome 28.0.1500.95 Google Chrome 28.0.1500.95 Windows 8 x64 Edition Windows 8 x64 Edition
    回复

发表评论

电子邮件地址不会被公开。