1
Kymair 2010 年 7 月 7 日
一个非常不错的Tutorial
http://simonwillison.net/static/2010/redis-tutorial/ |
2
zxn0 2010 年 8 月 5 日
GAE不是已经有自己的K/V了么。。
|
3
bruce 2010 年 8 月 5 日 via Android
这个是挺经典的kv数据库啊
|
4
rveo 2010 年 8 月 5 日
redis 缺点也非常突出。。
|
6
predator 2010 年 10 月 9 日
比较郁闷的一点是双L5520 @ 2.27GHz的机器跑不出官方文档中声称的性能
|
8
iwinux 2011 年 4 月 13 日
这个对服务器的配置要求比较高啊……
|
10
muxi 2011 年 4 月 13 日
@ksword 做简单消息队列基本靠谱,我已经在生产环境中使用,复杂的估计还得用专门的,比如ZeroMQ, 一个比较郁闷的是这个东西是双向链表,模拟队列的时候不能设置队列的最大长度,我的业务中需要这个东西,只能每次都去检测一次
@iwinux 我不知道你说的对服务器配置要求高是什么意思,需要很多的内存?还是IO性能?假如你使用其他的类似的产品,只要你的业务是同一个级别的,所需要的配置都是一样的,而且Redis相对于Memcache还能更好的使用大内存,不存在配置要求高的问题,如果是,那也是你的业务需要,跟Redis本身没有关系,你甚至可以在一个虚拟机或者比较垃圾的配置上使用它 @rveo 同样看不出来你表达什么意思,在我实际的使用中,没有发现有什么缺点,K/V模式能够有的东西,Redis基本上具备了,唯一不足的可能就是在自动分片上还需要优化,还没有跟TC/TT那样实现互为主从,但目前来说hash ring 的算法和M/S结构基本上能够应付绝大部分应用的需求了,没实现的部分只是锦上添花的功能,反而我用的最爽的keys *xx* 的功能,其他K/V都没有 |
11
virushuo 2011 年 4 月 13 日
这个东西不同的人会有不同的用法。
按照他支持的不同数据类型,可以做标准k-v库,做缓存,比memcached好,因为redis的分布较为容易,降低了memcached崩溃导致雪崩效应的机会。 也可以做一些计算,sorted sets可以做union之类的操作,对于一些集合归并操作比数据库快的多。 pub/sub可以做消息总线,配合long live http server,就是twitter stream API那种东西。 现在唯一的问题是容量取决于内存大小,所以如何做容量规划和设计架构是个学问。 |
12
ahu 2011 年 4 月 13 日
也可以看看MongoDB
|
13
bbayou 2011 年 5 月 8 日
redis持久化是个问题。。。
|
14
bruce 2011 年 5 月 8 日 via Android
早已不是问题
|