首页 > 代码库 > Redis安装及HA(High Availability)配置

Redis安装及HA(High Availability)配置

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与redisha3上,进入/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判断已经停止。

Objectively Down condition (ODOWN) 客户判断redis已停止,quorum参数指定的数量n,当当前有n个sentinel投票此redis已经down,则进入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的昵称

 

Redis安装及HA(High Availability)配置