第五章 - 管理

在最后一章里，我们将集中谈论Redis运行中的一些管理方面内容。这是一个不完整的Redis管理指南，我们将会回答一些基本的问题，初接触Redis的新用户可能会很感兴趣。

配置（Configuration）

当你第一次运行Redis的服务器，它会向你显示一个警告，指redis.conf文件没有被找到。这个文件可以被用来配置Redis的各个方面。一个充分定义（well-documented）的redis.conf文件对各个版本的Redis都有效。范例文件包含了默认的配置选项，因此，对于想要了解设置在干什么，或默认设置是什么，都会很有用。你可以在https://github.com/antirez/redis/raw/2.4.6/redis.conf找到这个文件。

这个配置文件针对的是Redis 2.4.6，你应该用你的版本号替代上面URL里的"2.4.6"。运行info命令，其显示的第一个值就是Redis的版本号。

因为这个文件已经是充分定义（well-documented），我们就不去再进行设置了。

除了通过redis.conf文件来配置Redis，config set命令可以用来对个别值进行设置。实际上，在将slowlog-log-slower-than设置为0时，我们就已经使用过这个命令了。

还有一个config get命令能显示一个设置值。这个命令支持模式匹配，因此如果我们想要显示关联于日志（logging）的所有设置，我们可以这样做：

config get *log*

验证（Authentication）

通过设置requirepass（使用config set命令或redis.conf文件），可以让Redis需要一个密码验证。当requirepass被设置了一个值（就是待用的密码），客户端将需要执行一个auth password命令。

一旦一个客户端通过了验证，就可以在任意数据库里执行任何一条命令，包括flushall命令，这将会清除掉每一个数据库里的所有关键字。通过配置，你可以重命名一些重要命令为混乱的字符串，从而获得一些安全性。

rename-command CONFIG 5ec4db169f9d4dddacbfb0c26ea7e5ef
rename-command FLUSHALL 1041285018a942a4922cbf76623b741e

或者，你可以将新名字设置为一个空字符串，从而禁用掉一个命令。

大小限制（Size Limitations）

当你开始使用Redis，你可能会想知道，我能使用多少个关键字？还可能想知道，一个散列数据结构能有多少个域（尤其是当你用它来组织数据时），或者是，一个列表数据结构或集合数据结构能有多少个元素？对于每一个实例，实际限制都能达到亿万级别（hundreds of millions）。

复制（Replication）

Redis支持复制功能，这意味着当你向一个Redis实例（Master）进行写入时，一个或多个其他实例（Slaves）能通过Master实例来保持更新。可以在配置文件里设置slaveof，或使用slaveof命令来配置一个Slave实例。对于那些没有进行这些设置的Redis实例，就可能一个Master实例。

为了更好保护你的数据，复制功能拷贝数据到不同的服务器。复制功能还能用于改善性能，因为读取请求可以被发送到Slave实例。他们可能会返回一些稍微滞后的数据，但对于大多数程序来说，这是一个值得做的折衷。

遗憾的是，Redis的复制功能还没有提供自动故障恢复。如果Master实例崩溃了，一个Slave实例需要手动的进行升级。如果你想使用Redis去达到某种高可用性，对于使用心跳监控（heartbeat monitoring）和脚本自动开关（scripts to automate the switch）的传统高可用性工具来说，现在还是一个棘手的难题。

备份文件（Backups）

备份Redis非常简单，你可以将Redis的快照（snapshot）拷贝到任何地方，包括S3、FTP等。默认情况下，Redis会把快照存储为一个名为dump.rdb的文件。在任何时候，你都可以对这个文件执行scp、ftp或cp等常用命令。

有一种常见情况，在Master实例上会停用快照以及单一附加文件（aof），然后让一个Slave实例去处理备份事宜。这可以帮助减少Master实例的载荷。在不损害整体系统响应性的情况下，你还可以在Slave实例上设置更多主动存储的参数。

缩放和Redis集群（Scaling and Redis Cluster）

复制功能（Replication）是一个成长中的网站可以利用的第一个工具。有一些命令会比另外一些来的昂贵（例如sort命令），将这些运行载荷转移到一个Slave实例里，可以保持整体系统对于查询的快速响应。

此外，通过分发你的关键字到多个Redis实例里，可以达到真正的缩放Redis（记住，Redis是单线程的，这些可以运行在同一个逻辑框里）。随着时间的推移，你将需要特别注意这些事情（尽管许多的Redis载体都提供了consistent-hashing算法）。对于数据水平分布（horizontal distribution）的考虑不在这本书所讨论的范围内。这些东西你也很可能不需要去担心，但是，无论你使用哪一种解决方案，有一些事情你还是必须意识到。

好消息是，这些工作都可在Redis集群下进行。不仅提供水平缩放（包括均衡），为了高可用性，还提供了自动故障恢复。

高可用性和缩放是可以达到的，只要你愿意为此付出时间和精力，Redis集群也使事情变得简单多了。

小结

在过去的一段时间里，已经有许多的计划和网站使用了Redis，毫无疑问，Redis已经可以应用于实际生产中了。然而，一些工具还是不够成熟，尤其是一些安全性和可用性相关的工具。对于Redis集群，我们希望很快就能看到其实现，这应该能为一些现有的管理挑战提供处理帮忙。