动机

  • 构建消息系统
  • 构建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的数据结构一遍看别人的案例