Redis安装及HA(High Availability)配置(转)

出处：http://www.cnblogs.com/morvenhuang/p/4184262.html

Redis是一种内存数据库，以KEY-VALUE(即键值对)的形式存储数据。这篇文章主要介绍的是Redis安装及配置，所以不对Redis本身作详细介绍了。

下载：

http://redis.io/download (另外，Redis作者有一博客：http://antirez.com/latest/0，有兴趣的可以关注)

解压：

以redis-2.8.19.tar.gz为例，解压放在某目录下，这里选择/usr/local目录。

编译：

进入/usr/local/redis-2.8.19，执行

#make

如遇到gcc: Command not found错误，表示需要安装gcc

#yum install gcc

如遇到zmalloc.h:50:31: error: jemalloc/jemalloc.h: No such file or directory错误，则要进入deps目录，执行：

#make hiredis

#make jemalloc

#make linenoise

#make lua

然后再回到上级目录执行make即可。

启动：

make成功之后，会在src目录生成redis-server等可执行文件，执行：

#src/redis-server

或

#src/redis-server &//加&为了可以让鼠标退出Redis的命令行

查看：

#ps aux|grep redis//查看是否有相应的进程

或

#telnet localhost 6379//登录Redis

或更常用的

#src/redis-cli//进入Redis交互命令行

这里介绍三个最基本的Redis命令(1)keys *，显示数据库中所有的key；(2)set foo bar，即为键foo设置值bar；(3)get foo，查看键foo的值。

关闭：

#src/redis-cli shutdown

日志：

不管对什么应用程序，日志对于诊断工作有很大的作用，所以这里提一下Redis的日志。我们发现按上面的方法启动Redis，我们在系统中找不到Redis的日志，即便我们配置了/usr/local/redis-2.8.19/redis.conf文件中的logfile，指向/var/log/redis.log，仍然找不到日志。

同时，通过src/redis-cli CONFIG GET *来查看配置项，则提示命令参数错误ERR Wrong number of arguments for CONFIG GET

其实，造成这些问题的原因是在启动Redis时没有明确指定配置文件，可以这样指定：

#src/redis-server redis.conf &//可以使用绝对路径来指定redis.conf

这样就一切正常了，日志文件也生成了。

HA配置：

我们先介绍Redis怎么配置Replication，这里准备了两台机器：redisha1(153.65.171.99)，这个作master；redisha2(153.65.170.156)，这个我们用来作slave，修改它的redis.conf：

slaveof 153.65.171.99 6379

表示我是redisha1的slave。这样设置之后，如果我们在redisha1中通过set foo bar2，在redisha2中通过get foo就可以取到值bar2。Redis自动完成了同步。

需要注意的是，配置完Replication后，作为slave的redisha2则进入read-only模式，也就是我们不能在redisha2上使用set命令写入数据了，set操作会收到(error) READONLY You can't write against a read only slave。

配置完Replication并不意味着就万事大吉了，试想如果redisha1宕机了，则基本意味着这套Redis系统失效了，因为这个时候剩下的redisha2是一个read-only的slave。

我们期望能有一个监控程序可以自动完成Redis Replication系统中的角色切换，而这正是我们要介绍的Redis Sentinel的设计目的（sentinel本身有哨兵、放哨之意）。同样，也准备了两台机器，都用来运行Sentinel：redisha3(153.65.171.168)，redisha4(153.65.170.145)，并且和前面的redisha1和redisha2一样，都部署了redis-2.8.19，所不同的是，我们并不改动redis.conf进行，要改动的是sentinel.conf：

sentinel monitor test 153.65.171.99   6379   2

这一行配置表示我要监控153.65.171.99这台机器上的Redis实例，并为它取了一个昵称叫test(默认是mymaster，如果你改动了，注意要搜索这个文件中所有mymaster的地方，并都改过来)。6379则是99上Redis监听的端口。

最后的2这个数字则是quorum数，对于一个Redis主从系统，可以有多个sentinel同时监控它，以避免当唯一的一个sentinel宕掉后影响redis系统的运行。多个sentinel之间采用一种“投票”机制，即某一sentinel发现某一redis实例宕掉了，它不能直接将它移出系统，而要询问所有的sentinel，只有当n个sentinel都投票同意说这个redis实例确实宕掉了，才能将它移出。而这个这n值正是由quorum参数指定。

启动Sentinel：

在redisha3与redisha4上，进入/usr/local/redis-2.8.19目录，执行：

#src/redis-server sentinel.conf --sentinel

测试：

关闭redisha1上的redis实例，则在sentinel的窗口中：

+switch-master test 153.65.171.99 6379 153.65.170.156 6379

也就是说原来的redisha1(153.65.171.99)的master角色现在由于redisha2(153.65.170.156)来承担了。

同时你会发现看到redisha2的redis.conf中的slaveof配置被移除了，因为它现在是master了。

启动redisha1上的redis，redisha1会被以slave的身份加入到redis系统中，可以在sentinel的窗口中看到：

+convert-to-slave slave 153.65.171.99:6379 153.65.171.99 6379 @ test 153.65.170.156 6379

而redisha1中的redis.conf文件的最后一行会被自动添加上slaveof配置，指向现在的master即redisha2。

需要注意的是，这个自动发现新redis实例并把它作为slave加入到系统中的功能，在2.6版本中是没有的。

关闭redisha4上的sentinel，redisha3上可以看到：

+sdown sentinel 153.65.170.145:26379 153.65.170.145 26379 @ test 153.65.170.156 6379

这个时候我关闭redisha2（它现在是master），sentinel无法进行自动角色切换了，这跟quorum的配置有关，因为它现在没有办法收到2个投票，这个上面介绍过了。

SDOWN, ODOWN：

在sentinel的输出中，经常可以看到这两个状态：

Subjectively Down condition (SDOWN) 主观觉得某redis实例已停止，即当前sentinel判断某redis实例已经停止。

Objectively Down condition (ODOWN) 客户判断某redis实例已停止，quorum参数指定的数量n，当当前有n个sentinel投票此redis已经宕了，则进入ODOWN状态。

其它几个命令：

#redis-cli -h {IP} -p 26379 info Sentinel//查看sentinel的信息

#redis-cli -h {IP} -p 6379 info Replication//查看replication的信息

#redis-cli -h {IP} -p 26379 sentinel slaves test//查看所有slave的信息。test是sentinel.conf中配置的master的昵称