技术实践｜Redis基础知识及集群搭建（下）

​

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。本篇文章围绕Redis基础知识及集群搭建相关内容进行了分享，希望与各位同仁交流探讨。

在Redis基础知识及集群搭建（上）篇中，我们介绍了Redis基本的数据结构及常用命令、数据类型的场景、Redis主从复制机制以及内存优化等内容。在今天的文章里，将分享有关于Redis集群搭建方面的内容。

二、Redis集群搭建

1. 集群及集群目的

集群指的是将几台服务器集中在一起，实现同一业务。

集群

目的：高可用、负载均衡、易扩展、数据安全、性能提升

技术：集群地址（虚拟IP）、网络通信（监控消息）

功能：负载均衡、读写分离、故障转移

​编辑

2. Redis集群部署方案1

方案1：Haproxy+Keepalived+Redis集群

​

编辑

■　方案1

①Redis：通过Redis的配置文件，可以实现主从复制、读写分离的工作。

②Haproxy：通过Haproxy的配置文件，实现负载均衡，Haproxy负载均衡算法有多种，一般采用轮询方式，当某台redis-salve故障时，Haproxy会将其摘除。

③Keepalived：是一个基于VRRP协议来实现服务器高可用方案，可以利用其来避免Haproxy单点故障，保证高可用。

​编辑

３. Redis部署目标

​编辑

４. Redis部署

​编辑

机器1

以root用户创建以下目录

​编辑​编辑

进入/usr/local/src目录

​编辑​编辑

Redis下载：

wget http://download.redis.io/releases/redis-2.8.9.tar.gz

解压redis安装包

​编辑​编辑

编译redis

​编辑

​

编辑

复制配置文件，执行如下

​

编辑

修改redis.conf

bind设为10.1.49.53 #redis服务跟该IP绑定

dir设为/usr/local/redis/data

pidfile /var/run/redis.pid

dbfilename设为dump.rdb

daemonize 设为yes

port 6379

修改redis-slave1

bind 10.1.49.53 #绑定IP

pidfile /var/run/redis-slave1.pid

dbfilename dump-slave1.rdb

dir /usr/local/redis/data

port 63791

slaveof 10.1.49.53 6379 #是10.1.49.53 6379的从存储

daemonize yes #后台开启守护进程

slave-read-only yes #slave只读

注：不要覆盖原文件，找到相应的字段修改即可，其他保持原样

修改redis-slave2

bind 10.1.49.53

pidfile /var/run/redis-slave2.pid

dbfilename dump-slave2.rdb

dir /usr/local/redis/data

port 63792

slaveof 10.1.49.53 6379

daemonize yes

启动slave的redis服务

​

编辑

机器2

机器2上的部署如同机器1，只要配置从服务器文件即可

启动机器1上的redis-master

​

编辑

注：可通过ps –ef|grep redis 查看服务是否启动

验证

首先确认已启动

机器1上：

redis-server redis.conf

redis-server redis-slave1

redis-server redis-slave2

机器2上：

redis-server redis-slave3

redis-server redis-slave4

到现在已完成redis集群配置，且只有10.1.49.53 6379可写数据，其余slave机器只能读数据

redis-cli -h 10.1.49.53 -p 6379

Info

可以看到这样子就是成功了

​

编辑

​

编辑

注1：配置文件中默认主从复制是开启的，通过上图可以看到命令机器为master，下挂4个从服务器

注2：查看编写的redis启动关闭脚本redis，该脚本放在/etc/init.d/ 中，通过service redis start/stop使用

5. Redis部署报错处理

■　如果报下面的错，说明master的redis没有启动，启动它即可

​

编辑

■　在2号机子上执行报错，请检查防火墙策略

​

编辑

6. Haproxy部署目标

​

编辑

7. Haproxy部署

机器1与机器2上的haproxy配置部署是一样的，通过Keeplived采用单活方式对外提供服务

进入机器1

安装

cd /usr/local/src

tar -zxvf haproxy-1.3.15.10

cd haproxy-1.3.15.10

make TARGET=linux26 PREFIX=/usr/local/haproxy

make install PREFIX=/usr/local/haproxy

注：要查看linux系统的内核信息，要与TARGET匹配

配置

cd /usr/local/haproxy

# haproxy 默认是没有配置文件的，需要自己手机创建

vi haproxy.cfg

查看是否成功

/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.cfg #启动

ps -ef | grep haproxy  #查进程

访问1 10.1.49.53:8888/haproxyadmin

8. Keepalived部署

进入机器1

cd /usr/local/src/

wget http://www.keepalived.org/software/keepalived-1.2.12.tar.gz

tar -zxvf keepalived-1.2.12.tar.gz

cd keepalived-1.2.12

./configure

make&&make install

注：若这里报错提示没有装openssl，则执行yum -y install openssl-devel安装，若还有其他的包没装，则执行yum命令进行安装。

cp /usr/local/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/

cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/

mkdir /etc/keepalived

cp /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/

ln -s /usr/local/sbin/keepalived /usr/sbin/

vi /etc/keepalived/keepalived.conf

注1：此处注意 { 与之前的字符之间必须有空格，否则无法正常调用，例如VI_1{ 这样写，就在keepalived启动时无法建立VIP 10.1.49.200

vi /etc/keepalived/check_haproxy.sh

注1：`是esc下面的符号，不是单引号。另外if\[]\表达式注意空格，另外要注意/etc/keepalived/check_haproxy.sh必须赋予可执行权限：chmod 777 /etc/keepalived/check_haproxy.sh，否则会启动不起来。

9. Keepalived配置文件

​

编辑

10. keepalived验证

机器1、2上分别执行

/etc/rc.d/init.d/keepalived start

通过 ip add，出现如下表示VIP建立

​

编辑

通过ps -ef|grep haproxy查看是否启动haproxy

通过ps -ef|grep keepalived查看是否启动keepalived

​编辑

通过tail -f /var/log/messages，出现以下信息为正确

​编辑

如果出现以下错误，请检查/etc/keepalived/check_haproxy.sh是否是可执行文件

​

编辑

11. 集群方案1验证

验证方式

①主从复制验证

在master中执行set key1 “test” ，在slave1、 slave2、 slave3、 slave4中执行get  key1，获得“test”，测试通过

②读写分离验证

在各slave中执行set key1 “test”，报以下错误测试通过

(error) READONLY You can't write against a read only slave.

③负载均衡验证

redis-cli –h 10.1.49.200 –p 63790

get  key1 得“test”，测试通过

④负载均衡高可用验证

kill -9 haproxy进程号，redis-cli –h 10.1.49.200 –p 63790

get  key1 得“test” ”，测试通过

⑤扩展性验证

slave3上执行slaveof 10.1.49.30 63798 脱离master，再执行slaveof 10.1.49.53 6379 加入到master，说明slave可不宕机扩展

12. Redis集群部署方案2

方案2：Redis官方Sentinel集群管理工具

​

编辑

■　方案2

Sentinel：负责对Redis群中的主从服务器监控、提醒和自动故障转移。

Redis群：对外提供Redis服务

​

编辑

13. Sentinel原理

①综述

Redis Sentinel是一个分布式系统，你可以在一个架构中运行多个Sentinel进程（progress），个数与Redis集群中服务个数没有关联关系。这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息，并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

②流言协议

Sentinel服务通过ping命令来确认监控服务是否正常，当足够多数量的Sentinel都确认监控的同一服务停止了（主观下线），则判定该服务停止（客观下线）。跟流言很相似，一个哨兵说看不到目标了，他会向其他哨兵询问是否看得到目标，足够多的哨兵说看不到目标，则说明目标消失。一般来说，足够多就是一半及以上。

③投票协议

投票协议就像选举，Sentinel群根据一定的规则，从Redis群中选择一个新的主服务器，并使其他Redis服务器作为新服务器的Slave，并修改自身的配置文件。

14. Sentinel配置

Sentinel集群部署很简单，而且它跟Redis集群逻辑上是独立，可以启动任意多个（当然最少要两个才有效果）服务，只需要配置Sentinel.conf文件即可：

port 26378　　　　#sentinel服务端口

daemonize yes　　#开启守护进程

logfile“/var/log/redis/sentinel1.log“ # sentinel运行日志

sentinel monitor mymaster 10.1.49.53 6379 2  #监控主服务及判定客观下线所需要的最少主观下线sentinel服务数

sentinel down-after-milliseconds mymaster 60000  #本sentinel服务多长时间收不到消息才能判定主观下线

sentinel failover-timeout mymaster 180000  #故障转移判定超时间

sentinel parallel-syncs mymaster 1 #故障转移后，允许最多几个slave可以同时从新服务器同步数据。

15. Sentinel问题及注意事项

①配置文件自动生成内容：服务在配置文件中指定从服务器地址及其他Sentinel服务地址，Sentinel的发布订阅功能支持向所监控Master服务发布和订阅消息，而消息中会包含从服务器地址、端口，其他Sentinel的信息，Sentinel拿到其他Sentinel服务消息后，会写入自己的配置文件中。

②Failover时间：当新Master代替老Master后，其他的Slave会自动使用新Master，同时向新Master发布同步数据请求，所有Slave同步完成后，这次故障转移才算完成。而本参数就是规定最多有几个Slave可以同时进行数据同步，Failover总时长是：（slaveCount% parallel-syncs+1）次*单位同步时长

③parallel-syncs：从2中看出参数越小，故障转移时间越长。基础中提到过同步数据的fork子进程虽然不会阻塞服务，但是会占用内存，可能使主服务不能响应指令。所以本参数越大，同时不能响应指令的Slave就越多，就越影响对外服务，甚至使对外服务能力中断。所以在配置参数时，我们要尽量减少故障转移时长，同时也要预留足够的Slave对外提供服务。

16. Sentinel部署

环境

​编辑

配置文件

​编辑

启动Sentinel

​编辑

启动Redis

​编辑

观察日志

■　命令1：\

​

编辑

绿色：sentinel启动后监控master，6秒后未收到响应，判定客观下线（ +sdown ）

红色：master启动后，sentinel发布消息至master，也收到其他sentinel发布的消息，将这些sentinel添加到配置文件，并开始监控。Sentinel们判定master活着，取消主观下线和客观下线状态。

​

编辑

■　命令2：redis-cli -h 10.1.49.53 -p 63791 slaveof 10.1.49.53 6379

​

编辑

说明：一个新的从服务器已经被Sentinel识别并关联（ +slave ）

■　命令3：在53与30上执行slaveof 10.1.49.53 6379

​编辑

说明：redis集群已经启动，并纳入sentinel群监控

■　命令4：redis-cli -h 10.1.49.53 -p 6379 shutdown

​

编辑

说明：Master判定主观下线（+sdown），Sentinel投票选举10.1.49.30 63794为新Master (+switch-master)，其他Slave自动执行Slaveof，故障转移成功。

■　命令5：redis-server redis.conf

​

编辑

说明：Master启动后被加入到Redis集群，并将角色转换为Slave，并不抢占主服务。

17. 集群总结

①目前官方redis_cluster尚在开发之中，目前bate只实现了部分功能，业界采用的多是zookeeper、Keepalived结合主从复制，或者Twemproxy开源架构，淘宝、百度、京东等公司使用的自主封装的Redis集群架构。

②方案1中进一步优化，通过双Master热备，可以减少集群宕机风险；方案2中解决了Master宕机问题，但是需要进一步封装，已达到负载均衡及对外透明。

③以上介绍的两个集群方案，都未能实现数据分片（sharding），面对大数据时纵向扩展（scale out）受限。当前官方集群中已经提供能分片功能，与方案2结合以期达到“高可用、易扩展、读写分离、负载均衡”目标。

​