闲聊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修改快，客户端比较悲剧，不断需要和服务端保持同步的修改。