动机

  • 构建消息系统
  • 构建IM
  • 学习用缓存加速web应用

资源

入门文章

经验分享

书籍

  • the-little-redis-book

    • 表格既复杂又灵活,基于表格的存储和管理,没有多少东西是你不能进行建模的,然而,这种通用性并不是没有缺点。具体来说就是,事情并不是总能达到假设中的简单或者快速
    • 针对特定类型的问题使用特定的数据结构?我们不就是这样进行编程的吗?
    • 典型的数据库应用案例是,将一个程序的所有数据组织起来,使之与另一个程序的数据保持独立。
      • 在Redis里,数据库简单的使用一个数字编号来进行辨认,默认数据库的数字编号是0
    • 在大多数情况下,Redis会把值看做是一个字节序列,而不会关注它们实质上是什么。要注意,不同的Redis载体处理序列化会有所不同
    • 查询:对于Redis而言,关键字就是一切,而值是没有任何意义。更通俗来看就是,Redis不允许你通过值来进行查询
      • 在我们生活的世界里,数据查询是如此的灵活和强大,而Redis的方式看起来是这么的原始和不高效。Redis不是一种普遍使用(one-size-fits-all)的解决方案
      • 值可以是任何东西,因为Redis从来不需要去读取或理解它们。这也可以帮助我们理清思路,然后去思考如何在这个新世界里建立模型。
    • 存储器和持久化:你可以对此进行设置,如果X个关键字已变更,那么每隔Y秒存储数据库一次。
    • “今天我们有多少个独立用户访问”是个在Web应用里常见的问题,有一篇精彩的博文,在里面可以看到Spool是如何使用这两个命令有效地解决此问题。对于1.28亿个用户,一部笔记本电脑在不到50毫秒的时间里就给出了答复,而且只用了16MB的存储空间。
    • 当你理解了那些常用的应用案例后,你将发现Redis对于许多类型的问题
    • 常数时间复杂度O(1)被认为是最快速的
      • 许多Redis命令都具有O(1)的时间复杂度
    • 对数时间复杂度O(log(N))被认为是第二快速的
      • zadd
    • 线性时间复杂度O(N)
      • 在一个表格的非索引列里进行查找就需要O(N)次操作。ltrim命令具有O(N)的时间复杂度
        • N不是列表所拥有的元素数量,而是被删除的元素数量
    • 在Redis里,当我们发现一些操作具有O(N)的时间复杂度时,我们可能可以找到更为好的方法去处理
    • 仿多关键字查询:很受启发
    • 性能或存储空间等问题,经过测试后,才会有真正的理解
    • Redis命令都具有原子性,Redis实际上是单线程运行的
      • 使用multi运行具有原子性的一组命令,执行exec命令去实际执行命令,使用discard命令放弃执行命令
    • 关键是要理解基本的数据结构。你将能领悟到,这些数据结构是如何能够实现你最初视角之外的东西。
    • 使用期限(Expiration):让Redis能成为一个理想的缓冲引擎
    • 发布和订阅:一流支持
    • sort命令是Redis最强大的命令之一
    • 复制:当你向一个Redis实例(Master)进行写入时,一个或多个其他实例(Slaves)能通过Master实例来保持更新
    • 备份文件:Redis会把快照存储为一个名为dump.rdb的文件
    • 复制功能(Replication)是一个成长中的网站可以利用的第一个工具。有一些命令会比另外一些来的昂贵(例如sort命令),将这些运行载荷转移到一个Slave实例里,可以保持整体系统对于查询的快速响应。
  • redis-cookbook

生产使用

论坛

文档

Redis 命令参考

练习

常见问题

我的理解

  • redis是个类似数据库的东西,支持更丰富的数据结构,更少的约束
  • 如何将这些数据结构用于典型案例,捷径是一边理解redis的数据结构一遍看别人的案例