Redis 早期版本曾经测试过。由于缺乏我需要的PHP/Perl binding,后来就放弃了。
但Redis开发神速，目前已经接近1.0-rc1，据作者自言，可以用了。呵呵。
Redis的神奇之处在于对于value的处理，除了String类型，还增加了Set、List。这点是超越Memcached之所在。
Redis支持对list的pop/push,range原子操作，很容易实现类似Queue,Stack等的数据结构.为此，作者说，可以把redis看做data structures server。
安装
Redis使用posix c编写，所以安装直接make就完事。 运行可以直接用内置配置跑，还是非常方便的。如果一个软件是否能够快速安装测试部署，会得到更多人的青睐。尤其是像需要短时间测试体验类似的东西，要是配置麻烦，我直接就放弃了。
协议
Redis没有使用memcached协议，而是使用自己的一套规范。
速度
Redis的速度很快，110000 SETs/second, 81000 GETs/second。和普通版的memcached相当。
命令
除了针对String的set/get外，redis支持针对Set/List的操作,如LPUSH,RPUSH。
这里有完整的命令列表
多Db
这是另一个有意思的东西，Redis支持不同的db空间，通过selectdb来切换到不同的db空间。从而实现数据的隔离。redis允许key在不同的db之间移动，也支持flush某个db。这个特性可以解决原来memcached中不支持tag/namespace的问题。
Sharding
和Flare不一样,Redis本身没有内置的sharding功能，而是需要通过client api来实现。比如和libmemcached一样通过实现consistent hashing来实现sharding。
Replication
仅支持简单master-slave。 slave支持只读查询，slave也可以通过上级slave来获得同步数据。
缺陷：
1. redis将所有数据放入内存中，而通过后台进程定时将数据dump到磁盘上，从而实现持久存储。这是redis为什么这么快的原因。因此，如果你的存储数据超过可用内存大小，就会导致OS使用swap文件。作者解释，鱼和熊掌不可兼得，既然要快，就多费点内存吧，反正现在内存也很便宜，呵呵。
2.由于只能通过client端实现sharding，而redis并不支持master之间的复制，因此如何实现动态节点添加和删除，只能由client端来实现。从这个方面说，redis还只能作为一个高级的memcached。
＝＝＝＝＝
我准备测试用Redis解决以下场景的问题:
1. 高速消息队列
2. 访客列表类
常见的最近来访啊，这篇文章谁看过啊，谁谁点评过啊，等等
3. SNS中常见的事件，最近发生了什么
4. 最近更新名单
虽然以上这些通过将数据结构unserialize为string后可以用memcached来实现，但既然redis是data structures server,那么会更加高效好用。
同时，这些数据也不是关键数据，即便丢失也无伤大雅，对于需要可靠保存的数据，要么使用flare，更为安全则应使用传统的数据库。
redis的作者提供一个例子，可以参考: