闲聊Redis

2011-08-03  sofes

闲聊Redis

Redis 是一个有趣的项目,与其把它说成键值存储、键值缓存还不如把它说成是一个远程的数据结构。

Redis的项目名是Remote Dictionary Server的缩写,我觉得还不如叫Remote Data Structure Server – Redss

很多人把它和memcached比较,把它和tt比较,我觉得Redis在提供了诸多功能的同时又保证了代码的简洁和实现的简洁,这个很好。

Redis中的很多功能是memcached/tt没有的,当然对于mongodb来说可能可以实现Redis的大多数功能但是又显得过于重量级了。

所谓程序就是数据结构加上算法,没错,但如果对于大多数应用级别的程序来说,就变成了逻辑加上关系型数据库(MSSQL/MYSQL)了。

关系型数据库是普适的,因此也就非常重,其实有的时候我们并不需要这么完备的数据库,那么有人会想到在内存中维护一个自己的数据结构,直接在内存中进行快速操作。

而Redis正是这么一种提供了多种value数据结构(现在有字符串/列表/集合/有序集合/哈希,或许将来还会有更多的数据结构)的远程键值存储。

集合和列表的好处不仅仅是可以在服务端进行直接操作,另一个好处也是节约了key占据的空间。

PS:Redis支持key的expire,但是不能为list/set中的一个item设置过期,如果需要的话貌似只能平板化成一级key,这样就丧失了很多特性,这点比较郁闷。

别小看这些丰富的数据结构,如果memcached只能用来做缓存的话,Redis就可以深深地和业务逻辑结合在一起,以高效的方式实现缓存或存储。

比如对于普通的键值存储,我们如果需要为值增加一项需要取出修改保存三个过程,但是现在只需要提交一次追加在头部/添加在尾部操作。

除此之外,Redis还提供其它一些很有用的特性:

1) 事务:允许让一组命令进入队列一次性执行,在执行的过程中不穿插其它命令(Redis的单线程保证)。但是要注意的是,并不能保证队列中操作的key没有 变化(并发环境),可以使用WATCH来监视并在并发时回滚(乐观并发)。当然,Redis中也提供了很多组合型的原子命令(比如检查并添加,删除后添 加,这些组合特别有用)。

2) 管道:一次性提交多个命令(如果只是进行一些设置,命令之间不需要依赖前置命令结果的话,可以提高不少效率)。当然,Redis还提供了很多Multi-的命令,允许一次性进行多个值的添加,获取等等。

3) 持久:有快照和日志两种方式。对于(后台)快照就是在保存的时候开启子进程(当然也可以前台方式)将整个(32G内存的dump过程想想真恐怖?)内存快 照写入临时文件(在此过程中的修改操作为父进程的内存页创建副本,那么最坏的情况可能要多用一倍内存),之后再替换原来的dump文件。所谓日志就是每一 次写操作生成日志(日志的持久化也有每秒/每次和依赖于OS三种方式),适用于不太适合丢失的数据的保存,当然效率也会差。

4) 复制:支持多层次的主从订阅。那么我们就有很多配置方式了,可以让主作为写,从作为运算,可以让主作为内存数据库,从作为持久化的备份。在建立订阅关系之 后,主会把内存映像在后台保存下来然后发动给各个从,并且保存后续的写操作命令,从收到文件后恢复文件中的快照再接受主保存的后续操作命令。

5) VM:操作系统的页过大,Redis默认使用32字节的页。把所有的键保存在内存中,把所有的值压缩(很厉害,保存10G的数据才占用2G不到的存储,我都怀疑我看错了)保存在swap中。也可以配置选择使用同步或异步方式进行换入换出。

Redis灵活的配置允许我们做各种优化,并且也提供了尽可能灵活和丰富的API。从效率上来说,我做过简单的性能测试,比memcached有略 微高一点的读写效率(比libevent更轻量级的网络实现?),但是在快照方式持久化的时候,读写效率一下子降低,可能大量的IO都用于内存映像的转存 了,CPU占用也很高。在达到500万数据量之后,读写效率可以降低一半。

另外要说明的是,每一个Redis的API都提供了Big O表示法,在使用之前需要了解,您不能期待双向链表的随机读取效率和hashtable的随机读取效率一样。

换一句话说,我们需要细致得去使用Redis,尽量确保比较少的大O,尽量确保比较少的网络传输,不能像使用关系型数据库一样。

现在再来说说另外一个问题,那就是集群/数据分区。对于memcached这样的缓存来说,一致性哈希就可以了,我们只需要保证在扩容的时候不会损 失大量的命中,并不一定要保证数据不能丢失。在业务系统重启的时候,缓存数据往往也需要重新来过,因此memcached服务端并没有实现集群,这一切都 是客户端进行的。对于存储就不一样了,比如mongodb实现了sharding,而如果现在希望把Redis用作存储并且一个节点不足以支持应用的话, 我们可以手动为业务分配不同的节点,也可以和memcached一样采取一致性哈希(在扩容的时候业务上可以忍受部分数据的丢失,Redis现在还没有支 持客户端哈希的.NET客户端)。

对于Redis 3.0,据说会支持Redis集群:

1) 节点之间可以互相通讯,和服务端口不同的端口通讯。

2) 所有数据的key被分成几千份(哈希槽),分布在现有的节点中。

3) 在增加了一个节点后,会把相应的数据转移过去。

4) 新的key的操作会转移到新节点,老的key的操作每一次都会询问老节点是否已转移。

5) 转移完成之后所有之后的请求会直接请求新的节点。

6) 节点支持主从多份备份,自动适应节点的故障(和mongodb的replica set类似)。

据说这都会在服务端实现,也就是proxy方式,那么到时候可能会有config/proxy/data不同形式的节点(和mongodb的sharding类似)。

其实如果能不根据key的数量而根据key的访问压力进行迁移的话那就更好了,不过这样config db可能需要存储更多的数据。

总而言之,Redis创新点是很多的,使用起来也是很灵活的,当然也就意味着配置和API的复杂。完全可以使用Redis完整实现一个应用。

Mongodb实现超大日志/报表数据存储,Redis实现部分业务数据的计算和缓存/存储,配合起来确实不错。

感叹一下,开源的东西变化快,BUG修改快,客户端比较悲剧,不断需要和服务端保持同步的修改。

最后这里推荐一个有关Redis的ppt:

当然,也可以看看这个我做的PPT,里面有对所有API的翻译:

Redis
View more presentations from powerzhuye.

    来自: sofes > 《服务器》

    以文找文   |   举报

    猜你喜欢
    发表评论评论公约
    喜欢该文的人也喜欢 更多