ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

技术实践|Redis基础知识及集群搭建(下)

2022-07-04 00:00:52  阅读:215  来源: 互联网

标签:haproxy 10.1 Redis redis 基础知识 keepalived 集群 Sentinel


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

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有