1 Server
info
以一种易于理解和阅读的格式，返回关于Redis服务器的各种信息和统计数值
select
选择一个数据库，下标值从0开始，一个新连接默认连接的数据库是DB0
flushdb
删除当前数据库里面的所有数据
这个命令永远不会出现失败
这个操作的时间复杂度是O(N),N是当前数据库的keys数量
flushall
删除所有数据库里面的所有数据，注意不是当前数据库，而是所有数据库
这个命令永远不会出现失败
这个操作的时间复杂度是O(N),N是数据库的数量
ping
如果后面没有参数时返回PONG，否则会返回后面带的参数
这个命令经常用来测试一个连接是否还是可用的，或者用来测试一个连接的延时
如果客户端处于频道订阅模式下，它将是一个multi-bulk返回，第一次时返回”pong”，之后返回空（empty bulk），除非命令后面更随了参数
##quit
请求服务器关闭连接。连接将会尽可能快的将未完成的客户端请求完成处理
save
执行一个同步操作，以RDB文件的方式保存所有数据的快照 很少在生产环境直接使用SAVE 命令，因为它会阻塞所有的客户端的请求，可以使用BGSAVE 命令代替. 如果在BGSAVE命令的保存数据的子进程发生错误的时,用 SAVE命令保存最新的数据是最后的手段,详细的说明请参考持久化文档
dbsize
自 1.0.0 起可用。
返回当前数据里面keys的数量
2 keys 命令集
2.1 keys
1.0.0 起可用。
时间复杂度：O（N）与N是数据库中的键数，假设数据库中的键名称和给定的模式的长度有限。
返回所有键匹配模式。
虽然此操作的时间复杂性为 O（N），但常量时间相当低。例如，在入门级笔记本电脑上运行的 Redis 可以在 40 毫秒内扫描 100 万个key数据库。
注意，将 KEYS 视为一个命令，该命令应仅在生产环境中使用。当对大型数据库执行时，可能会破坏性能。此命令用于调试和特殊操作，例如更改key空间布局。不要在常规应用程序代码中使用 KEYS。如果你想在key空间子集中查找key，请考虑使用 SCAN 命令或sets结构。
keys * 遍历所有 key。一般不在生产环境使用
那何时使用该命令呢？
- 热备从节点
- 使用scan替代吧
2.2 set
将键key设定为指定的“字符串”值
如果key 已经保存了一个值，那么这个操作会直接覆盖原来的值，并且忽略原始类型
当set命令执行成功之后，之前设置的过期时间都将失效
如果SET命令正常执行那么回返回OK，否则如果加了NX 或者 XX选项，但是没有设置条件。那么会返回nil
2.3 del
删除指定的一批keys，如果删除中的某些key不存在，则直接忽略。
返回值:被删除的keys的数量
2.4 exists
自 1.0.0 起可用。
时间复杂度：O（1）
如果key存在，则返回。
由于 Redis 3.0.3 可以指定多个键而不是单个键。在这种情况下，它将返回现有key的总数。请注意，为单个键返回 1 或 0 只是 variadic 使用的特殊情况，因此该命令完全向后兼容。
用户应该知道，如果在参数中多次提到相同的现有key，则将多次计数该key。因此，如果存在某些key，则存在某些key，则返回 2。
返回值
- 1 key存在
- 0 key不存在
2.5 ttl（pttl）
返回key剩余的过期时间。 这种反射能力允许Redis客户端检查指定key在数据集里面剩余的有效期。
从Redis2.8开始，错误返回值的结果:
- 若key不存在或已过期，返回
-2 - 若key存在且没有设置过期时间，返回 -1
- 与之相关的 PTTL 命令实现完全相同，返回相同的信息，只不过其时间单位是毫秒（仅适用于Redis 2.6及更高版本）。
返回值
key有效的秒数（TTL in seconds），或者一个负值的错误 (参考上文)
2.6 expire key seconds
自 1.0.0 起可用。
时间复杂度：O（1）
设置key的过期时间。超时后，将会自动删除该key。在Redis的术语中一个key的相关超时是volatile的。
超时后只有对key执行DEL、SET、GETSET时才会清除。 这意味着，从概念上讲所有改变key而不用新值替换的所有操作都将保持超时不变。 例如，使用 INCR 递增key的值，执行 LPUSH 将新值推到 list 中或用 HSET 改变hash的field，这些操作都使超时保持不变。
使用 PERSIST 命令可以清除超时，使其变成一个永久key
若 key 被 RENAME 命令修改，相关的超时时间会转移到新key
若 key 被 RENAME 命令修改，比如原来就存在 Key_A，然后调用 RENAME Key_B Key_A 命令，这时不管原来 Key_A 是永久的还是设为超时的，都会由Key_B的有效期状态覆盖
注意，使用非正超时调用 EXPIRE/PEXPIRE 或具有过去时间的 EXPIREAT/PEXPIREAT 将导致key被删除而不是过期（因此，发出的key事件将是 del，而不是过期）。
刷新过期时间
对已经有过期时间的key执行EXPIRE操作，将会更新它的过期时间。有很多应用有这种业务场景，例如记录会话的session。
Redis 之前的 2.1.3 的差异
在 Redis 版本之前 2.1.3 中，使用更改其值的命令更改具有过期集的密钥具有完全删除key的效果。由于现在修复的复制层中存在限制，因此需要此语义。
EXPIRE 将返回 0，并且不会更改具有超时集的键的超时。
返回值
-
1如果成功设置过期时间。 -
0如果key不存在或者不能设置过期时间。
示例
假设有一 Web 服务，对用户最近访问的最新 N 页感兴趣，这样每个相邻页面视图在上一个页面之后不超过 60 秒。从概念上讲，可以将这组页面视图视为用户的导航会话，该会话可能包含有关ta当前正在寻找的产品的有趣信息，以便你可以推荐相关产品。
可使用以下策略轻松在 Redis 中对此模式建模：每次用户执行页面视图时，您都会调用以下命令：
MULTI RPUSH pagewviews.user:<userid> http://..... EXPIRE pagewviews.user:<userid> 60 EXEC
如果用户空闲超过 60 秒，则将删除该key，并且仅记录差异小于 60 秒的后续页面视图。
此模式很容易修改，使用 INCR 而不是使用 RPUSH 的列表。
带过期时间的 key
通常，创建 Redis 键时没有关联的存活时间。key将永存，除非用户以显式方式（例如 DEL 命令）将其删除。
EXPIRE 族的命令能够将过期项与给定key关联，但代价是该key使用的额外内存。当key具有过期集时，Redis 将确保在经过指定时间时删除该key。
可使用 EXPIRE 和 PERSIST 命令（或其他严格命令）更新或完全删除生存的关键时间。
过期精度
在 Redis 2.4 中，过期可能不准确，并且可能介于 0 到 1 秒之间。
由于 Redis 2.6，过期误差从 0 到 1 毫秒。
过期和持久化
过期信息的键存储为绝对 Unix 时间戳（Redis 版本 2.6 或更高版本为毫秒）。这意味着即使 Redis 实例不处于活动状态，时间也在流动。
要使过期工作良好，必须稳定计算机时间。若将 RDB 文件从两台计算机上移动，其时钟中具有大 desync，则可能会发生有趣的事情（如加载时加载到过期的所有key）。
即使运行时的实例，也始终会检查计算机时钟，例如，如果将一个key设置为 1000 秒，然后在将来设置计算机时间 2000 秒，则该key将立即过期，而不是持续 1000 秒。
Redis 如何使key过期
键的过期方式有两种：被动方式和主动方式。
当某些客户端尝试访问key时，key会被动过期，并且该key已定时。
当然，这是不够的，因为有过期的key，永远不会再访问。无论如何，这些key都应过期，因此请定期 Redis 在具有过期集的key之间随机测试几个key。已过期的所有key将从key空间中删除。
具体来说，如下 Redis 每秒 10 次：
测试 20 个带有过期的随机键
删除找到的所有已过期key
如果超过 25% 的key已过期，从步骤 1 重新开始
这是一个微不足道的概率算法，基本上假设我们的样本代表整个key空间，继续过期，直到可能过期的key百分比低于 25%。
这意味着在任何给定时刻，使用内存的已过期的最大键量等于最大写入操作量/秒除以 4。
在复制链路和 AOF 文件中处理过期的方式
为了在不牺牲一致性的情况下获得正确行为，当key过期时，DEL 操作将同时在 AOF 文件中合成并获取所有附加的从节点。这样，过期的这个处理过程集中到主节点中，还没有一致性错误的可能性。
但是，虽然连接到主节点的从节点不会独立过期key（但会等待来自master的 DEL），但它们仍将使用数据集中现有过期的完整状态，因此，当选择slave作为master时，它将能够独立过期key，完全充当master。