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与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的昵称

 

---

送书了，送书了，关注公众号“程序员杂书馆”，送出O'Reilly《Spark快速大数据分析》纸质书（亦有一批PDF分享）！ —— 2018年12月