技术实践|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单点故障,保证高可用。
编辑
3. Redis部署目标
编辑
4. 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结合以期达到“高可用、易扩展、读写分离、负载均衡”目标。
标签:haproxy,10.1,Redis,redis,基础知识,keepalived,集群,Sentinel 来源: https://www.cnblogs.com/zhongdianjinxin/p/16441362.html