redis Cluster集群(3.2.10版本)三主三从,五主五从集群搭建

Redis Cluster高可用支持root用户安装,也支持非root用户安装,安装和启动方法一致

redis-cluster-3.2.10版本百度云链接:https://pan.baidu.com/s/1tncis5ZsqihtGmeyfaN7CQ 
提取码:0njl 

Redis非root用户安装,home目录下创建一个用户test01

[root@localhost home]# useradd test01

[root@localhost home]# passwd test01

将redis_cluster.zip包传到/home/test01/redis目录下,并且解压安装包

unzip reddis_cluster.zip

然后修改你所有的redis-xxx.conf文件

内容主要有bind,port,dir ,如下图,下图修改的是redis-9000.conf,如果还有9001,9002,9003就依次在每个conf文件中修改即可

 

 

#redis-9000.conf

pidfile /home/test01/redis/data/redis-9000.pid

port 9000

bind 172.31.223.35

unixsocket /home/test01/redis/data/redis-9000.sock

logfile /home/test01/redis/log/redis-9000.log

dbfilename dump-9000.rdb

dir /home/test01/redis/data

masterauth test    --test是密码,有就写没有就空着不写

requirepass test  --test是密码,有就写没有就空着不写

appendfilename "appendonly-9000.aof"

cluster-config-file /home/test01/redis/data/nodes-9000.conf

 

  1. cluster.xml文件nodepad打开,配置好主节点和从节点及端口号,上传到/home/test01/redis/bin目录下

,注意每个redis-xxx.conf中配置都需要修改,修改成自己对应的配置端口和统一路径和密码

redis Cluster集群(3.2.10版本)三主三从,五主五从集群搭建_第1张图片

 

  1. 按照下面的方法启动redis,进入/home/test01/redis/bin目录下

注意把每个redis-xxx.conf都上传到指定的服务器上然后还需要在自己对应ip服务器上进行重新重启

 

chmod +x *

./redis-server ../cfg/redis-9000.conf

./redis-server ../cfg/redis-9001.conf

./redis-server ../cfg/redis-9002.conf

./redis-server ../cfg/redis-9003.conf

./redis-server ../cfg/redis-9004.conf

建立集群,进入/home/test01/redis/bin目录下

./redis_builder -a create -f cluster.xml -p test  在某一台redis服务器上执行就行test是密码,如果没有密码可不写

redis Cluster集群(3.2.10版本)三主三从,五主五从集群搭建_第2张图片

 

免编译redis 非root用户安装启动方法与root用户安装启动方法一样。

  1. Redis高可用部署参考

Redis的高可用部署方式比较灵活,redis集群主从节点可以是一对一的方式,也可以是1个主节点对应多个从节点,这里以五主五从部署在3台服务器上为例,可以实现一台服务器挂掉或者

由于redis的主从节点是相对应的

测试场景设置redis集群主节点:A、B、C、D、E,从节点:A1、B1、C1、D1、E1,测试机器3台,节点5主5从,具体分配如下

机器A

A1

C

D

E1

机器B

B1

E

D1

 

机器C

A

B

C1

 

 

高可用方案部署

1、由于redis集群主从节点是相对应的,一对对应的主从节点挂掉,整个redis集群服务即不可用,所以部署建议redis主从节点部署,主节点和其对应的从节点不要部署在同一台服务器上(防止1台机器挂掉导致整个redis集群不能使用)

2、当一台机器的主节点小于N/2(N为redis主节点个数),这台机器挂掉,这台机器主节点对应在另一台机器上的从节点会变成主节点;这台挂掉的机器的redis服务重启后,这台机器上原来的主节点变为从节点,原来的从节点还是从节点,主从节点对并不会还原重机器挂掉前的样子

3、当一台机器的主节点大于N/2(N为redis主节点个数),这台机器挂掉,整个redis集群状态显示failed,所以部署在一台服务器上的主节点尽量小于N/2

4、redis集群的主从节点对是不变的,所谓的漂移只是主节点对中主节点变为从节点,从节点变为主节点,节点对和节点对之间不会有漂移

 

  1. Redis集群状态检查

根据cluster info和cluster nodes指令查询redis集群是否正常

 

使用命令,查看集群信息:

./redis_builder -s 172.31.223.35:9000 -a nodes -p test

 

 

集群测试:

使用redis客户端redis-cli进行添加数据操作。到/home/test01/redis/bin

  1. ./redis-cli -c -h 192.168.36.189 -p 6380  -a test
  2. 192.168.36.189:6380> set abc 123  
  3. OK  
  4. 192.168.36.189:6380> set xxx 123  
  5. -> Redirected to slot [4038] located at 192.168.36.54:6380  
  6. OK  
  7. 192.168.36.54:6380> set ttt aaa  
  8. -> Redirected to slot [15942] located at 192.168.36.54:6381  
  9. OK  

$ ./redis-cli -c -h 172.31.223.35 -p 9000 -a 密码 --raw

172.31.223.14:9000> set zs 张三

OK

192.168.77.127:9002> get zs

"\xd3\xba\xcd\xf2\xd2\xf8"

 $ ./redis-cli -c -h 172.31.223.38 -p 9000 -a test --raw   #--raw参数可get出keys的文本不会出现乱码

192.168.77.127:9000> get zs

"\xd3\xba\xcd\xf2\xd2\xf8"  --加raw能显示具体文本

 

  1. Redis开机自启动设置

1、手动配置shell脚本stat_redis.sh

#!/bin/sh

### BEGIN INIT INFO

# Provides:          test.sh

# Required-Start:    $local_fs $remote_fs $network $syslog

# Required-Stop:     $local_fs $remote_fs $network $syslog

# Default-Start:     2 3 4 5

# Default-Stop:      0 1 6

# Short-Description: starts the php_fastcgi daemon

# Description:       starts php_fastcgi using start-stop-daemon

### END INIT INFO

/home/test01/redis/bin/redis-server /home/test01/redis/cfg/redis-9000.conf //配置redis绝对路径

/home/test01/redis/bin/redis-server /home/test01/redis/cfg/redis-9001.conf //配置redis绝对路径

/home/test01/redis/bin/redis-server /home/test01/redis/cfg/redis-9002.conf  //配置redis绝对路径

/home/test01/redis/bin/redis-server /home/test01/redis/cfg/redis-9003.conf  //配置redis绝对路径

/home/test01/redis/bin/redis-server /home/test01/redis/cfg/redis-9004.conf //配置redis绝对路径

/home/test01/redis/bin/redis-server /home/test01/redis/cfg/redis-9005.conf //配置redis绝对路径

将stat_redis.sh脚本上传到/etc/init.d下面,设置开机自启动

chkconfig --list start_redis.sh

chkconfig start_redis.sh on

执行上面命令遇到以下报错,执行下一条命令即可解决
insserv: warning: script 'start_redis.sh' missing LSB tags and overrides
insserv: warning: script 'start_redis.sh ' missing LSB tags and overrides
insserv: warning: script ' start_redis.sh ' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (empty) of script `start_redis.sh ' overwrites defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0) of script ` start_redis.sh ' overwrites defaults (0 1 6).
insserv: dryrun, not creating .depend.boot, .depend.start, and .depend.stop

insserv -v -d /etc/init.d/start_redis.sh

 

注意事项:

1Redis集群节点异常重启或者所在服务器重启后,redis被自动拉起后,最好清一下redis中脏数据

登录redis客户端,然后用flushdb,flushall命令清除redis中的数据

./redis-cli -c -h 172.31.3.82 -p 7000 --raw    #用--raw参数get时能查看文本内容

flushdb

flushall

2、对于redis若操作flushdbflushall和重启redis操作的有以下的约束条件:

(1)、在操作前,保证没有用户使用鉴权,等待3分钟,确保所有的用户心跳都被处理,实时授权量回到初值;

(2)、在操作后的5分钟内,鉴权功能同样不能使用,并且不能通过页面修改授权量上限,确保授权量恢复

  1. Redis cluster(redis3.x)设计要点

Redis Cluster设计要点:
 

架构:无中心

Redis Cluster采用无中心结构,每个节点都保存数据和整个集群的状态
每个节点都和其他所有节点连接,这些连接保持活跃
使用gossip协议传播信息以及发现新节点
node不作为client请求的代理,client根据node返回的错误信息重定向请求
 

数据分布:预分桶

预分好16384个桶,根据 CRC16(key) mod 16384的值,决定将一个key放到哪个桶中
每个Redis物理结点负责一部分桶的管理,当发生Redis节点的增减时,调整桶的分布即可
例如,假设Redis Cluster三个节点A/B/C,则
Node A 包含桶的编号可以为: 0 5500.
Node B 
包含桶的编号可以为: 5500  11000.
Node C
包含桶的编号可以为: 11001  16384.
当发生Redis节点的增减时,调整桶的分布即可。
预分桶的方案介于Hash”一致性Hash”之间,牺牲了一定的灵活性,但相比一致性Hash“,数据的管理成本大大降低。

 

可用性:Master-Slave

为了保证服务的可用性,Redis Cluster采取的方案是的Master-Slave
每个Redis Node可以有一个或者多个Slave。当Master挂掉时,选举一个Slave形成新的Master
一个Redis  Node包含一定量的桶,当这些桶对应的MasterSlave都挂掉时,这部分桶对应的数据不可用。

写操作

Redis Cluster使用异步复制
一个完整的写操作步骤:
1.client写数据到master
2.master
告诉client "ok"
3.master
传播更新到slave
存在数据丢失的风险:
1. 上述写步骤1)和2)成功后,master crash,而此时数据还没有传播到slave
2.
由于分区导致同时存在两个masterclient向旧的master写入了数据。
当然,由于Redis Cluster存在超时及故障恢复机制,第2个风险基本上不可能发生
 

数据迁移

Redis Cluster支持在线增/减节点。
基于桶的数据分布方式大大降低了迁移成本,只需将数据桶从一个Redis Node迁移到另一个Redis Node即可完成迁移。
当桶从一个Node A向另一个Node B迁移时,Node ANode B都会有这个桶,Node A上桶的状态设置为MIGRATINGNode B上桶的状态被设置为IMPORTING
当客户端请求时:
所有在Node A上的请求都将由A来处理,所有不在A上的key都由Node B来处理。同时,Node A上将不会创建新的key
 

key操作

当系统从单节点向多节点扩展时,多key的操作总是一个非常难解决的问题,Redis Cluster方案如下:
1. 不支持多key操作

2. 如果一定要使用多key操作,请确保所有的key都在一个node上,具体方法是使用“hash tag”方案
hash tag方案是一种数据分布的例外情况

 

 

  1. Redis主从同步方案

Redis主从配置(Master-Slave
一、 Redis Replication的特点:


1):一个Master可以同步多个Slave
2)
:不仅Master可以同步多个SlaveSlave也可以同步其它Slave,可以构成一个图形结构,同时还能分担Master的同步压力
3)Redis Replication使用的是异步复制。从2.8开始,Slave会周期性发起一个Ack确认replication stream被处理进度
4):复制在Master Server是以非阻塞模式完成数据同步。即使多个Master-Slave同时同步,Master Server仍然可以提供查询或修改
5):复制在Slave Server也是以非阻塞的方式完成数据同步。在同步期间,Slave Server可以提供数据查询,但返回的是同步之前的数据,同时还能配置当MasterSlave失去联系时,让Slave返回客户端一个错误提示
6)Slave Server可以为客户端提供只读操作的服务,但写服务仍然必须由Master来完成,这样可以分载Master的读操作压力,在分压的同时还供了数据冗余,同时还可以通过增加Slave进行只读操作来提升扩展性
7):可以通过修改Master Serverredis.config配置文件来将持久化操作交给Slave Server去操作
注:Slave是只读的,只可以读取数据,而不能写入数据
   
   

二、Redis Replication工作原理:


1)Slave启动后,无论是第一次连接还是重连到Master,它都会主动发出一个SYNC命令
2):当Master收到SYNC命令之后,将会执行BGSAVE(后台存盘进程),即在后台保存数据到磁盘(rdb快照文件),同时收集所有新收到的写入和修改数据集的命令存入缓冲区(非查询类)
3)Master在后台把数据保存到快照文件完成后,会传送整个数据库文件到Slave
4)
Slave接收到数据库文件后,会把内存清空,然后加载该文件到内存中以完成一次完全同步
5):然后Master会把之前收集到缓冲区中的命令和新的修改命令依次传送给Slave
6)
Slave接受到之后在本地执行这些数据修改命令,从而达到最终的数据同步
7):之后MasterSlave之间将会不断的通过异步方式进行命令的同步,从而保证数据的时时同步
8):如果MasterSlave之间的链接出现断连,Slave可以自动重连Master。根据版本的不同,断连后同步的方式也不同:
    2.8之前:重连成功之后,一次全量同步操作将被自动执行
    2.8之后:重连成功之后,进行部分同步操作

 

 

 

 

 

三、 redis 主从同步配置

下面是我使用的配置,使用主从模式,在master上关掉所有持久化,在slave上使用dba持久化:
$cat /opt/redis/etc/redis.conf

###Master config

###General 配置

daemonize yes                  #使用daemon 方式运行程序,默认为非daemon方式运行

pidfile /tmp/redis.pid       #pid文件位置

port 6379                       #使用默认端口

timeout 300                      # client 端空闲断开连接的时间

loglevel warning               #日志记录级别,默认是notice,我这边使用warning,是为了监控日志方便。使用warning后,只有发生告警才会产生日志,这对于通过判断日志文件是否为空来监控报警非常方便。

logfile /opt/logs/redis/redis.log   #日志产生的位置

databases 16              #默认是0,也就是只用1 db,我这边设置成16,方便多个应用使用同一个redis server。使用select n 命令可以确认使用的redis db ,这样不同的应用即使使用相同的key也不会有问题。

###下面是SNAPSHOTTING持久化方式的策略。为了保证数据相对安全,在下面的设置中,更改越频繁,SNAPSHOTTING越频繁,也就是说,压力越大,反而花在持久化上的资源会越多。所以我选择了master-slave模式,并在master关掉了SNAPSHOTTING

#save 900 1           #900秒之内,redis至少发生1次修改则redis抓快照到磁盘

#save 300 100         #300秒之内,redis至少发生100次修改则redis抓快照到磁盘

#save 60 10000       #60秒之内,redis至少发生10000次修改则redis抓快照到磁盘

rdbcompression yes        #使用压缩

dbfilename dump.rdb  #SNAPSHOTTING的文件名

dir /opt/data/redis/ #SNAPSHOTTING文件的路径

###REPLICATION 设置,

#slaveof   #如果这台机器是台redis slave,可以打开这个设置。如果使用master-slave模式,我就会在master上把SNAPSHOTTING关了,这样可以不用在master上做持久化,而是在slave上做,这样可以大大提高master 内存使用率和系统性能。

#slave-serve-stale-data yes  #如果slave 无法与master 同步,是否还可以读

### SECURITY 设置 

#requirepass iflytek     #redis性能太好,用个passwd 意义不大

#rename-command FLUSHALL ""  #可以用这种方式关掉非常危险的命令,如FLUSHALL这个命令,它清空整个 Redis 服务器的数据,而且不用确认且从不会失败

###LIMIT 设置

maxclients 0 #client连接数量限制

maxmemory 15032385536 #redis最大可使用的内存量,我的服务器内存是16G,如果使用redis SNAPSHOTTINGcopy-on-write的持久会写方式,会额外的使用内存,为了使持久会操作不会使用系统VM,使redis服务器性能下降,建议保留redis最大使用内存的一半8G来留给持久化使用,我个人觉得非常浪费。我没有在master上不做持久化,使用主从方式

maxmemory-policy volatile-lru  #使用LRU算法删除设置了过期时间的key,但如果程序写的时间没有写key的过期时间,建议使用allkeys-lru,这样至少保证redis不会不可写入。

###APPEND ONLY MODE 设置

appendonly no  #不使用AOFAOF是另一种持久化方式,我没有使用的原因是这种方式并不能在服务器或磁盘损坏的情况下,保证数据可用性。

appendfsync everysec 

no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

###SLOW LOG 设置

slowlog-log-slower-than 10000  #如果操作时间大于0.001秒,记录slow log,这个log是记录在内存中的,可以用redis-cli slowlog get 命令查看

slowlog-max-len 1024  #slow log 的最大长度

###VIRTUAL MEMORY 设置

vm-enabled no   #不使用虚拟内存,在redis 2.4版本,作者已经非常不建议使用VM

vm-swap-file /tmp/redis.swap

vm-max-memory 0

vm-page-size 32

vm-pages 134217728

vm-max-threads 4

###ADVANCED CONFIG 设置,下面的设置主要是用来节省内存的,我没有对它们做修改

hash-max-zipmap-entries 512  

hash-max-zipmap-value 64

list-max-ziplist-entries 512

list-max-ziplist-value 64

set-max-intset-entries 512

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

activerehashing yes

###INCLUDES 设置 ,使用下面的配置,可以配置一些个另其它的设置,如slave的配置

#include /path/to/local.conf

#include /path/to/other.conf

#include /opt/redis/etc/slave.conf  如果是slave server,把这个注释打开

slave 配置:
$cat /opt/redis/etc/slave.conf

###slave config

###REPLICATION 设置,

slaveof 192.168.xx.xx 6397    # 打开这个设置,修改成masterip和端口。如果使用master-slave模式,我就会在master上把SNAPSHOTTING关了,这样可以不用在master上做持久化,而是在slave上做,这样可以大大提高master 内存使用率和系统性能。

slave-serve-stale-data no  #如果slave 无法与master 同步,设置成slave不可读,方便监控脚本发现问题。

###下面是SNAPSHOTTING持久化方式的策略。为了保证数据相对安全,在下面的设置中,更改越频繁,SNAPSHOTTING越频繁,也就是说,压力越大,反而花在持久化上的资源会越多。所以我选择了master-slave模式,并在master关掉了SNAPSHOTTING。只需在slave上开启。

save 900 1           #900秒之内,redis至少发生1次修改则redis抓快照到磁盘

save 300 100         #300秒之内,redis至少发生100次修改则redis抓快照到磁盘

save 60 10000       #60秒之内,redis至少发生10000次修改则redis抓快照到磁盘

rdbcompression yes        #使用压缩

dbfilename dump.rdb  #SNAPSHOTTING的文件名

dir /opt/data/redis/ #SNAPSHOTTING文件的路径

 

四、测试:
1:在命令行界面进行查看(以上两个节点):
# /main/redis/src/redis-cli
127.0.0.1:6379> info replication


节点1显示如下(master)
# Replication
role:master    //主节点
connected_slaves:1
slave0:ip=192.168.xx.xx,port=6379,state=online,offset=41663,lag=1

master_repl_offset:41963
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:41962


节点2显示如下(slave1)
# Replication
role:slave       //从节点
master_host:192.168.xx.xx
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:41520
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

 

2:数据测试
Master
# /main/redis/src/redis-cli  set hello doiido

Slave
# /main/redis/src/redis-cli   get hello
"doiido"

 

你可能感兴趣的:(个人杂志)