Redis简介
Redis安装及基本配置
Redis持久化
Redis多数据类型开发(了解)
Redis复制及高可用
Redis 集群分片
Redis API支持(Python篇)
Redis.io
Download/redis.io
Redisdoc.com
redis.cn
高速读写
数据类型丰富
支持持久化
多种内存分配及回收策略
支持事务
消息队列、消息订阅
支持高可用
支持分布式分片集群
与memeched区别
支持事务
数据类型丰富
支持持久化
支持高可用
支持分布式分片集群
下载:
上传至 /data
[root@db02 ~]# cd /data
[root@db02 data]# wget http://download.redis.io/releases/redis-3.2.12.tar.gz
解压:
[root@db02 data]# tar xzf redis-3.2.12.tar.gz
[root@db02 data]# mv redis-3.2.12 redis
安装:
[root@db02 data]# cd redis
[root@db02 redis]# make
修改环境变量
[root@db02 data]#vim /etc/profile
export PATH=/application/mysql/bin/:/data/redis/src:$PATH
[root@db02 data]#source /etc/profile
启动和简易连接:
[root@db02 data]# redis-server &
[1] 4794
[root@db02 data]# 4794:C 11 Apr 12:32:00.180 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
4794:M 11 Apr 12:32:00.181 # Server started, Redis version 3.2.12
4794:M 11 Apr 12:32:00.181 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add ‘vm.overcommit_memory = 1‘ to /etc/sysctl.conf and then reboot or run the command ‘sysctl vm.overcommit_memory=1‘ for this to take effect.
4794:M 11 Apr 12:32:00.181 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command ‘echo never > /sys/kernel/mm/transparent_hugepage/enabled‘ as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
4794:M 11 Apr 12:32:00.181 * The server is now ready to accept connections on port 6379
^C
[root@db02 data]# redis-c
redis-check-aof redis-check-rdb redis-cli
[root@db02 data]# redis-cli
127.0.0.1:6379>
127.0.0.1:6379> set name zhansan
OK
127.0.0.1:6379> get name
"zhansan"
127.0.0.1:6379> keys *
1."name"
127.0.0.1:6379>
[root@db01 6379]#mkdir /data/6379
[root@db01 6379]#vim /data/6379/redis.conf
daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379
dbfilename dump.rdb
停掉数据库,重新启动
[root@db02 data]# redis-cli
127.0.0.1:6379> shutdown
not connected> exit
或
[root@db02 data]# redis-cli shutdown
启动
[root@db01 6379]# redis-server /data/6379/redis.conf
[root@db03 ~]# netstat -lnp|grep 6379
[root@db02 data]# netstat -antlp|grep 6379
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 4824/redis-server *
tcp 0 0 :::6379 :::* LISTEN 4824/redis-server *
[root@db02 data]#
+++++++++++配置文件说明++++++++++++++
redis.conf
是否后台运行:
daemonize yes
默认端口:
port 6379
日志文件位置
logfile /var/log/redis.log
持久化文件存储位置
dir /data/6379
RDB持久化数据文件:
dbfilename dump.rdb
(1)redis没有用户概念,redis只有密码
(2)redis默认在工作在保护模式下。不允许远程任何用户登录的(protected-mode)
protected-mode yes/no (保护模式,是否只允许本地访问)
(1)Bind :指定IP进行监听
vim /data/6379/redis.conf
bind 10.0.0.52 127.0.0.1
(2)增加requirepass {password}
vim /data/6379/redis.conf
requirepass root
重启生效:
redis-cli shutdown
redis-server /data/6379/redis.conf
----------验证密码-----
方法一:
[root@db03 ~]# redis-cli -a root
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> exit
方法二:
[root@db03 ~]# redis-cli
127.0.0.1:6379> auth root
OK
127.0.0.1:6379> set a b
10.0.0.52:6379> CONFIG GET *
1) "dbfilename"
2) "dump.rdb"
3) "requirepass"
4) "root"
5) "masterauth"
6) ""
10.0.0.52:6379> CONFIG GET requirepass
1) "requirepass"
2) "root"
10.0.0.52:6379> CONFIG SET requirepass 123456
OK
10.0.0.52:6379> CONFIG GET requirepass
1) "requirepass"
2) "123456"
10.0.0.52:6379> auth 123456
OK
10.0.0.52:6379>
RDB 持久化
可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)。
优点:速度快,适合于用做备份,主从复制也是基于RDB持久化功能实现的。
缺点:会有数据丢失
rdb持久化核心配置参数:
vim /data/6379/redis.conf
dir /data/6379
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
配置分别表示:
900秒(15分钟)内有1个更改
300秒(5分钟)内有10个更改
60秒内有10000个更改
AOF 持久化(append-only log file)
记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。
AOF 文件中的命令全部以 Redis 协议的格式来保存,新命令会被追加到文件的末尾。
优点:可以最大程度保证数据不丢
缺点:日志记录量级比较大
AOF持久化配置
appendonly yes #是否打开aof日志功能
appendfsync always #每1个命令,都立即同步到aof
appendfsync everysec #每秒写1次
appendfsync no #写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof.
vim /data/6379/redis.conf
appendonly yes
appendfsync everysec
redis 持久化方式有哪些?有什么区别?
rdb:基于快照的持久化,速度更快,一般用作备份,主从复制也是依赖于rdb持久化功能
aof:以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全,类似于mysql的binlog
应用场景:
(1)非常基本的键值对存储
(2)计数器
互联网当中,点击量,访问量,关注量等
网页游戏应用当中的,血量、蓝量等
基本操作:
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> get name
"zhangsan"
127.0.0.1:6379> mset id 101 name zhangsan age 20 gender male
OK
127.0.0.1:6379> mget id name age gender
1) "101"
2) "zhangsan"
3) "20"
4) "male"
计数器应用
127.0.0.1:6379> incr fensi
127.0.0.1:6379> DECR fensi
127.0.0.1:6379> INCRBY fensi 10000
127.0.0.1:6379> DECRBY fensi 10003
127.0.0.1:6379> get fensi
应用场景:最接近于MySQL表结构的数据类型
存储部分变更的数据,如用户信息等。
基本操作:
127.0.0.1:6379> hset zhangsan name zs
(integer) 1
127.0.0.1:6379> hmset student id 101 name zs age 20 gender male
OK
127.0.0.1:6379> hmset stu id 102 name lisi age 21 gender male
OK
127.0.0.1:6379> hmget stu id name age gender
1) "102"
2) "lisi"
3) "21"
4) "male"
127.0.0.1:6379> hgetall stu
1) "id"
2) "102"
3) "name"
4) "lisi"
5) "age"
6) "21"
7) "gender"
8) "male"
小扩展:
MySQL 中 city表中前10行数据,灌入到redis中
MySQL:
id name age gender
101 zhangsan 20 male
hmset zhangsan_stu id 101 name zhangsan age 20 gender male
思路:
mysql> desc t1;
+-------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id | int(11) | YES | | NULL | |
| name | varchar(20) | YES | | NULL | |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
mysql>
mysql>
mysql>
mysql>
mysql> select concat("hmset stu_",name," id ",id," name ",name) from t1;
+---------------------------------------------------+
| concat("hmset stu_",name," id ",id," name ",name) |
+---------------------------------------------------+
| hmset stu_zhang3 id 1 name zhang3 |
| hmset stu_li4 id 2 name li4 |
| hmset stu_wang5 id 3 name wang5 |
+---------------------------------------------------+
应用场景:朋友圈应用
在Redis中我们的最新微博ID使用了常驻缓存,这是一直更新的。
但是做了限制不能超过5000个ID,因此获取ID的函数会一直询问Redis。
只有在start/count参数超出了这个范围的时候,才需要去访问数据库。?
系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。
SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。
例子:微信朋友圈应用
127.0.0.1:6379> LPUSH wechat "today is 1"
(integer) 1
127.0.0.1:6379> LPUSH wechat "today is 2"
(integer) 2
127.0.0.1:6379> LPUSH wechat "today is 3"
(integer) 3
127.0.0.1:6379> LPUSH wechat "today is 4"
(integer) 4
127.0.0.1:6379> LPUSH wechat "today is 5"
-1意思是到结尾
127.0.0.1:6379> LRANGE wechat 0 -1
1) "today is 5"
2) "today is 4"
3) "today is 3"
4) "today is 2"
5) "today is 1"
127.0.0.1:6379>
应用场景:
案例:?在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。
Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,
对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
127.0.0.1:6379> sadd lxl pg1 pg2 baoqiang masu marong
(integer) 5
127.0.0.1:6379> sadd jnl baoqiang yufan baobeier zhouxingchi
(integer) 4
127.0.0.1:6379> SUNION lxl jnl
1) "zhouxingchi"
2) "baobeier"
3) "pg2"
4) "yufan"
5) "masu"
6) "baoqiang"
7) "pg1"
8) "marong"
127.0.0.1:6379>
127.0.0.1:6379> SINTER lxl jnl
1) "baoqiang"
127.0.0.1:6379> SDIFF lxl jnl
1) "masu"
2) "pg1"
3) "marong"
4) "pg2"
127.0.0.1:6379> SDIFF jnl lxl
1) "yufan"
2) "zhouxingchi"
3) "baobeier"
排行榜应用,取TOP N操作?
这个需求与上面需求的不同之处在于,前面操作以时间为权重,这个是以某个条件为权重,
比如按顶的次数排序,这时候就需要我们的sorted set出马了,将你要排序的值设置成sorted set的score
,将具体的数据设置成相应的value,每次只需要执行一条ZADD命令即可。
例子: 歌曲排行榜
最初值
127.0.0.1:6379> zadd music 0 fskl 0 fshkl 0 lzlsfs 0 tm 0 ass
(integer) 5
127.0.0.1:6379>
127.0.0.1:6379> ZINCRBY music 1000 fskl
"1000"
127.0.0.1:6379> ZINCRBY music 10000 fshkl
"10000"
127.0.0.1:6379> ZINCRBY music 100000 lzlsfs
"100000"
127.0.0.1:6379> ZINCRBY music 1000000 tm
"1000000"
127.0.0.1:6379> ZINCRBY music 100 ass
"100"
##排行
10.0.0.52:6379> ZREVRANGE music 0 -1
1) "tm"
2) "lzlsfs"
3) "fshkl"
4) "fskl"
5) "ass"
127.0.0.1:6379> ZREVRANGE music 0 -1 withscores
1) "tm"
2) "1000000"
3) "lzlsfs"
4) "100000"
5) "fshkl"
6) "10000"
7) "fskl"
8) "1000"
9) "ass"
10) "100"
PUBLISH channel msg
将信息 message 发送到指定的频道 channel
SUBSCRIBE channel [channel ...]
订阅频道,可以同时订阅多个频道
UNSUBSCRIBE [channel ...]
取消订阅指定的频道, 如果不指定频道,则会取消订阅所有频道
PSUBSCRIBE pattern [pattern ...]
订阅一个或多个符合给定模式的频道,每个模式以 * 作为匹配符,比如 it* 匹配所 有以 it 开头的频道( it.news 、 it.blog 、 it.tweets 等等), news.* 匹配所有 以 news. 开头的频道( news.it 、 news.global.today 等等),诸如此类
PUNSUBSCRIBE [pattern [pattern ...]]
退订指定的规则, 如果没有参数则会退订所有规则
PUBSUB subcommand [argument [argument ...]]
查看订阅与发布系统状态
注意:使用发布订阅模式实现的消息队列,当有客户端订阅channel后只能收到后续发布到该频道的消息,之前发送的不会缓存,必须Provider和Consumer同时在线。
发布订阅例子:
窗口1:
127.0.0.1:6379> SUBSCRIBE baodi
窗口2:
127.0.0.1:6379> PUBLISH baodi "jin tian zhen kaixin!"
订阅多频道:
窗口1:
127.0.0.1:6379> PSUBSCRIBE wang*
窗口2:
10.0.0.52:6379> PUBLISH wangbaoqiang "jintian zhennanshou "
(integer) 1
10.0.0.52:6379> PUBLISH wangbao "jintian zhennanshou "
(integer) 1
[root@db02 ~]# redis-cli -h 10.0.0.52 -a 123456
10.0.0.52:6379> PSUBSCRIBE wang*
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "wang*"
3) (integer) 1
1) "pmessage"
2) "wang*"
3) "wangbaoqiang"
4) "jintian zhennanshou "
1) "pmessage"
2) "wang*"
3) "wangbao"
4) "jintian zhennanshou "
**操作命令:**
DISCARD
取消事务,放弃执行事务块内的所有命令。
EXEC
执行所有事务块内的命令。
MULTI
标记一个事务块的开始。
UNWATCH
取消 WATCH 命令对所有 key 的监视。
WATCH key [key ...]
监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。
**开启事务功能时(multi)**
multi
command1
command2
command3
command4
4条语句作为一个组,并没有真正执行,而是被放入同一队列中。
如果,这是执行discard,会直接丢弃队列中所有的命令,而不是做回滚。
exec
当执行exec时,对列中所有操作,要么全成功要么全失败
----------
127.0.0.1:6379> set a b
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set a b
QUEUED
127.0.0.1:6379> set c d
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
举例:我正在买票
Ticket -1 , money -100
而票只有1张, 如果在我multi之后,和exec之前, 票被别人买了,即ticket变成0了.
我该如何观察这种情景,并不再提交
悲观的想法:
世界充满危险,肯定有人和我抢, 给ticket上锁, 只有我能操作. [悲观锁]
乐观的想法:
没有人会和我抢,因此,我只需要注意,有没有人更改ticket的值就可以了 [乐观锁]
发布一张票
10.0.0.52:6379>set ticket 1
窗口1:
10.0.0.52:6379>watch ticket
10.0.0.52:6379>multi
10.0.0.52:6379>set ticket 0 1---->0
窗口2:
10.0.0.52:6379>multi
10.0.0.52:6379>set ticket 0
10.0.0.52:6379>exec
窗口1:
10.0.0.52:6379>exec
(nil)
10.0.0.52:6379> info
#Server
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:40e20ad08a75cec4
redis_mode:standalone
os:Linux 2.6.32-696.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:4879
10.0.0.52:6379> client list
id=4 addr=10.0.0.52:53849 fd=7 name= age=6485 idle=578 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=exec
id=7 addr=10.0.0.52:53855 fd=8 name= age=629 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
10.0.0.52:6379> client kill ip:port
10.0.0.52:6379> config get *
10.0.0.52:6379> CONFIG RESETSTAT 重置统计
10.0.0.52:6379> CONFIG GET/SET 动态修改
10.0.0.52:6379> dbsize
10.0.0.52:6379> dbsize
(integer) 14
10.0.0.52:6379> keys *
1) "a"
2) "jnl"
3) "gender"
4) "music"
5) "zhansan"
6) "lxl"
7) "wechat"
8) "ticket"
9) "age"
10) "b"
11) "id"
12) "student"
13) "fensi"
14) "name"
10.0.0.52:6379>
10.0.0.52:6379>FLUSHALL 清空所有数据
select 1
10.0.0.52:6379>FLUSHDB 清空当前库
10.0.0.52:6379> select 1 选择哪个数据库
OK
10.0.0.52:6379>MONITOR 监控实时指令
10.0.0.52:6379> monitor
OK
1554967195.170124 [0 10.0.0.52:53849] "set" "ticket" "0"##在另一个窗口set,在当前窗口查看
10.0.0.52:6379>SHUTDOWN 关闭服务器
10.0.0.52:6379>save将当前数据保存 rdb持久化的命令,执行了save,会进行rdb持久化
10.0.0.52:6379>SLAVEOF host port 主从配置
10.0.0.52:6379>SLAVEOF NO ONE
10.0.0.52:6379>SYNC 主从同步
10.0.0.52:6379>ROLE返回主从角色
10.0.0.52:6379> del a
(integer) 1
10.0.0.52:6379> exists a
(integer) 0
10.0.0.52:6379> type student
hash
10.0.0.52:6379> expire student 120 设置存活时间,单位是秒
(integer) 1
10.0.0.52:6379> pexpire student 1200 设置存活时间,单位是毫秒
(integer) 1
10.0.0.52:6379> expire fensi 120000
(integer) 1
10.0.0.52:6379> TTL fensi TTL/PTTL以秒\毫秒为单位返回还剩余的存活时间
(integer) 119995
10.0.0.52:6379> TTL fensi
(integer) 11×××
10.0.0.52:6379> TTL fensi
(integer) 119987
10.0.0.52:6379>
10.0.0.52:6379> persist fensi 取消生存时间设置
(integer) 1
10.0.0.52:6379> TTL fensi 永久有效
(integer) -1
关闭数据库:
redis-cli -a root shutdown
使用异步复制。
一个主服务器可以有多个从服务器。
从服务器也可以有自己的从服务器。
复制功能不会阻塞主服务器。
可以通过复制功能来让主服务器免于执行持久化操作,由从服务器去执行持久化操作即可
当配置Redis复制功能时,强烈建议打开主服务器的持久化功能。 否则的话,由于延迟等问题,部署的服务应该要避免自动拉起。
为了帮助理解主服务器关闭持久化时自动拉起的危险性,参考一下以下会导致主从服务器数据全部丢失的例子:
1. 假设节点A为主服务器,并且关闭了持久化。 并且节点B和节点C从节点A复制数据
2. 节点A崩溃,然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了,所以重启之后没有任何数据
3. 节点B和节点C将从节点A复制数据,但是A的数据是空的, 于是就把自身保存的数据副本删除。
在关闭主服务器上的持久化,并同时开启自动拉起进程的情况下,即便使用Sentinel来实现Redis的高可用性,也是非常危险的。 因为主服务器可能拉起得非常快,以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启,然后还是会执行上面的数据丢失的流程。
无论何时,数据安全都是极其重要的,所以应该禁止主服务器关闭持久化的同时自动拉起。
如果不开,有可能主库重启操作,造成所有主从数据丢失!
**原理:**
1. 从服务器向主服务器发送 SYNC 命令。
2. 接到 SYNC 命令的主服务器会调用BGSAVE 命令,创建一个 RDB 文件,并使用缓冲区记录接下来执行的所有写命令。
3. 当主服务器执行完 BGSAVE 命令时,它会向从服务器发送 RDB 文件,而从服务器则会接收并载入这个文件。
4. 主服务器将缓冲区储存的所有写命令发送给从服务器执行。
命令传播
在主从服务器完成同步之后,主服务器每执行一个写命令,它都会将被执行的写命令发送给从服务器执行,这个操作被称为“命令传播”(command propagate)。
命令传播是一个持续的过程:只要复制仍在继续,命令传播就会一直进行,使得主从服务器的状态可以一直保持一致。
复制中的SYNC与PSYNC
在 Redis 2.8 版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作。
从 Redis 2.8 开始,Redis 使用 PSYNC命令代替 SYNC 命令。
PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步(partial resync)
特性:在主从服务器断线并且重新连接的时候,只要条件允许,PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据,而不用重新向从服务器同步整个数据库。
总结:
SYNC处理断线重连,需要同步所有数据
PSYNC处理断线重连,不需要同步所有数据
在读写分离环境下,客户端向主服务器发送写命令 SET n 10086,主服务器在执行这个写命令之后,向客户端返回回复,并将这个写命令传播给从服务器。
接到回复的客户端继续向从服务器发送读命令 GET n ,并且因为网络状态的原因,客户端的 GET命令比主服务器同步 SET 命令更快到达了从服务器。
因为从服务器键 n 的值还未被更新,所以客户端在从服务器读取到的将是一个错误(过期)的 n值。
主从数据一致性保证:
min-slaves-to-write 1
min-slaves-max-lag
这个特性的运作原理:
从服务器以每秒一次的频率 PING 主服务器一次, 并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置, 指定网络延迟的最大值 min-slaves-max-lag ,
以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。
如果至少有 min-slaves-to-write 个从服务器, 并且这些服务器的延迟值都少于 min-slaves-max-lag秒,
那么主服务器就会执行客户端请求的写操作。
你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本: 尽管不能保证写操作的持久性,
但起码丢失数据的窗口会被严格限制在指定的秒数中。
另一方面, 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件, 那么写操作就不会被执行
主服务器会向请求执行写操作的客户端返回一个错误。
1、环境:
准备两个或两个以上redis实例
[root@db02 ~]# mkdir /data/638{0..2}
配置文件示例:
[root@db02 ~]# cat >> /data/6380/redis.conf<<EOF
port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
protected-mode no
EOF
[root@db02 ~]# cat >> /data/6381/redis.conf<<EOF
port 6381
daemonize yes
pidfile /data/6381/redis.pid
loglevel notice
logfile "/data/6381/redis.log"
dbfilename dump.rdb
dir /data/6381
protected-mode no
EOF
[root@db02 ~]# cat >> /data/6382/redis.conf<<EOF
port 6382
daemonize yes
pidfile /data/6382/redis.pid
loglevel notice
logfile "/data/6382/redis.log"
dbfilename dump.rdb
dir /data/6382
protected-mode no
EOF
启动:
[root@db02 ~]#redis-server /data/6380/redis.conf
[root@db02 ~]#redis-server /data/6381/redis.conf
[root@db02 ~]#redis-server /data/6382/redis.conf
主节点:6380
从节点:6381、6382
2、开启主从:
6381/6382命令行:
[root@db02 ~]#redis-cli -p 6381
127.0.0.1:6381> SLAVEOF 127.0.0.1 6380
OK
[root@db02 ~]#redis-cli -p 6382
127.0.0.1:6382> SLAVEOF 127.0.0.1 6380
OK
3、查询主从状态
从库:
[root@db02 ~]#redis-cli -p 6382
127.0.0.1:6382> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:29
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
127.0.0.1:6382>
[root@db02 ~]#redis-cli -p 6381
127.0.0.1:6381> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:99
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
主库:
[root@db02 ~]# redis-cli -p 6380
127.0.0.1:6380> info replication
#Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=183,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=183,lag=0
master_repl_offset:183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:182
127.0.0.1:6380>
主库故障模拟及切换(failover过程):
4、从库切为主库
模拟主库故障
[root@db02 ~]# redis-cli -p 6380
127.0.0.1:6380>shutdown
[root@db02 ~]# redis-cli -p 6381
127.0.0.1:6381> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:435
master_link_down_since_seconds:19
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
127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> info replication
#Replication
role:master
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
127.0.0.1:6381>
6382连接到6381:
[root@db02 ~]# redis-cli -p 6382
##查看
127.0.0.1:6382> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:435
master_link_down_since_seconds:106
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
##取消当前所属master
127.0.0.1:6382> slaveof no one
OK
##换maser为6381端口
127.0.0.1:6382> slaveof 127.0.0.1 6381
OK
##查看
127.0.0.1:6382> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:15
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
127.0.0.1:6382>
sentinel介绍
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,
而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。
Sentinel 是一个监视器,它可以根据被监视实例的身份和状态来判断应该执行何种动作。
sentinel功能--监控(Monitoring):
Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒(Notification):
当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):
当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器;
当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
发现并连接主服务器
Sentinel 会与被监视的主服务器创建两个网络连接:
命令连接用于向主服务器发送命令。
订阅连接用于订阅指定的频道,从而发现监视同一主服务器的其他 Sentinel (细节马上会介绍)。
发现并连接从服务器
Sentinel 通过向主服务器发送 INFO 命令来自动获得所有从服务器的地址。
跟主服务器一样,Sentinel 会与每个被发现的从服务器创建命令连接和订阅连接。
发现其他 Sentinel
Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息,该消息包含 Sentinel 的 IP、端口号、ID 等内容,以此来向其他 Sentinel 宣告自己的存在。
与此同时Sentinel 会通过订阅连接接收其他 Sentinel 的“HELLO” 信息,以此来发现监视同一个主服务器的其他 Sentinel 。
sentinel1 通过发送HELLO 信息来让sentinel2 和 sentinel3发现自己,其他两个sentinel 也会进行类似的操作。
多个Sentienl之间的链接
Sentinel 之间只会互相创建命令连接,用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介,所以 Sentinel之间不会创建订阅连接。
检测实例的状态
Sentinel 使用 PING 命令来检测实例的状态:如果实例在指定的时间内没有返回回复,或者返回错误的回复,那么该实例会被 Sentinel 判断为下线。
Redis 的 Sentinel 中关于下线(down)有两个不同的概念:
主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。 (一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。)
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内, 对向它发送 PING 命令的 Sentinel 返回一个有效回复(valid reply), 那么 Sentinel 就会将这个服务器标记为主观下线。
故障转移FAILOVER
一次故障转移操作由以下步骤组成:
发现主服务器已经进入客观下线状态。
基于Raft leader election 协议 , 进行投票选举
如果当选失败,那么在设定的故障迁移超时时间的两倍之后,重新尝试当选。 如果当选成功, 那么执行以下步骤。
选出一个从服务器,并将它升级为主服务器。
向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。
通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel ,其他 Sentinel 对它们自己的配置进行更新。
向已下线主服务器的从服务器发送 SLAVEOF 命令,让它们去复制新的主服务器。
当所有从服务器都已经开始复制新的主服务器时, leader Sentinel 终止这次故障迁移操作。
sentinel搭建过程
恢复6380为master,6381 6382为slave的状态
启动6380
[root@db02 ~]# redis-server /data/6380/redis.conf
设置6382的master
[root@db02 ~]# redis-cli -p 6382
127.0.0.1:6382> slaveof no one
OK
127.0.0.1:6382> slaveof 127.0.0.1 6380
OK
127.0.0.1:6382> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:1
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
设置6381的master
[root@db02 ~]# redis-cli -p 6381
127.0.0.1:6381> info replication
#Replication
role:master
connected_slaves:0
master_repl_offset:1009
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1008
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK
127.0.0.1:6381> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:71
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:2
repl_backlog_histlen:1036
127.0.0.1:6381> exit
[root@db02 ~]#
##查看主从复制状态
[root@db02 ~]# redis-cli -p 6380
127.0.0.1:6380> info replication
#Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6382,state=online,offset=197,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=197,lag=0
master_repl_offset:197
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:196
127.0.0.1:6380>
##搭建sentinel
[root@db02 ~]# mkdir /data/26380
[root@db02 ~]# cd /data/26380/
[root@db02 26380]# vim sentinel.conf
port 26380
dir "/data/26380"
sentinel monitor mymaster 127.0.0.1 6380 1
sentinel down-after-milliseconds mymaster 5000
配置文件讲解
指定监控master
sentinel monitor mymaster 127.0.0.1 6370 2
{2表示多少个sentinel同意}
安全信息
sentinel auth-pass mymaster root
sentinel超过15000毫秒后连接不到redis master,认为主机宕机,这个时间不能过长
sentinel down-after-milliseconds mymaster 15000
当主从切换多久后认为主从切换失败
sentinel failover-timeout mymaster 900000
这两个配置后面的数量主从机需要一样,epoch为master的版本
sentinel leader-epoch mymaster 1
sentinel config-epoch mymaster 1
启动:
[root@db02 26380]#redis-sentinel /data/26380/sentinel.conf &
停主库测试:
[root@db01 ~]# redis-cli -p 6380
shutdown
##master变为了6381
[root@db01 ~]# redis-cli -p 6381
127.0.0.1:6381> info replication
#Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6382,state=online,offset=3153,lag=1
master_repl_offset:3153
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:3152
127.0.0.1:6381> exit
启动源主库(6380),看状态。
##master仍然是6381
[root@db02 26380]# redis-cli /data/6380/redis.conf
[root@db02 26380]# redis-cli -p 6381
127.0.0.1:6381> info replication
#Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6382,state=online,offset=9287,lag=1
slave1:ip=127.0.0.1,port=6380,state=online,offset=9287,lag=1
master_repl_offset:9287
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:9286
127.0.0.1:6381>
Redis集群
Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施(installation)。
Redis 集群不支持那些需要同时处理多个键的 Redis 命令, 因为执行这些命令需要在多个 Redis 节点之间移动数据, 并且在高负载的情况下, 这些命令将降低 Redis 集群的性能, 并导致不可预测的行为。
Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。
将数据自动切分(split)到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时, 仍然可以继续处理命令请求的能力。
Redis 集群数据共享
Redis 集群使用数据分片(sharding)而非一致性哈希(consistency hashing)来实现: 一个 Redis 集群包含 16384 个哈希槽(hash slot), 数据库中的每个键都属于这 16384 个哈希槽的其中一个, 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽, 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。
槽的计算公式
集群使用公式 CRC16(key) & 16383 计算键 key属于哪个槽。
运行机制
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
节点的fail是通过集群中超过半数的master节点检测失效时才生效.
客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->key
集群的复制
为了使得集群在一部分节点下线或者无法与集群的大多数(majority)节点进行通讯的情况下, 仍然可以正常运作, Redis 集群对节点使用了主从复制功能: 集群中的每个节点都有 1 个至 N 个复制品(replica), 其中一个复制品为主节点(master), 而其余的 N-1 个复制品为从节点(slave)。
在之前列举的节点 A 、B 、C 的例子中, 如果节点 B 下线了, 那么集群将无法正常运行, 因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。
假如在创建集群的时候(或者至少在节点 B 下线之前), 我们为主节点 B 添加了从节点 B1 , 那么当主节点 B 下线的时候, 集群就会将 B1 设置为新的主节点, 并让它代替下线的主节点 B , 继续处理 5501 号至 11000 号的哈希槽, 这样集群就不会因为主节点 B 的下线而无法正常运作了。
不过如果节点 B 和 B1 都下线的话, Redis 集群还是会停止运作。
集群的复制特性重用了 SLAVEOF 命令的代码,所以集群节点的复制行为和 SLAVEOF 命令的复制行为完全相同。
集群的故障转移
在集群里面,节点会对其他节点进行下线检测。
当一个主节点下线时,集群里面的其他主节点负责对下线主节点进行故障移。
换句话说,集群的节点集成了下线检测和故障转移等类似 Sentinel 的功能。
因为 Sentinel 是一个独立运行的监控程序,而集群的下线检测和故障转移等功能是集成在节点里面的,它们的运行模式非常地不同,所以尽管这两者的功能很相似,但集群的实现没有重用 Sentinel 的代码。
在集群里面执行命令的两种情况
命令发送到了正确的节点:命令要处理的键所在的槽正好是由接收命令的节点负责,那么该节点执行命令,就像单机 Redis 服务器一样。
命令发送到了错误的节点:接收到命令的节点并非处理键所在槽的节点,那么节点将向客户端返回一个转向(redirection)错误,告知客户端应该到哪个节点去执行这个命令,客户端会根据错误提示的信息,重新向正确的节点发送命令。
命令发送给正确的节点
键 date 位于 2022 槽,该槽由节点 7000 负责,命令会直接执行。
命令发送给了错误的节点
键 date 位于 2022 槽,该槽由节点 7000 负责,但错误发送到了7001节点
转向错误的实现
集群中的节点会互相告知对方,自己负责处理哪些槽。
集群中的每个节点都会记录 16384 个槽分别由哪个节点负责,从而形成一个“槽表”(slot table)。
节点在接收到命令请求时,会通过槽表检查键所在的槽是否由本节点处理:
如果是的话,那么节点直接执行命令;
如果不是的话,那么节点就从槽表里面提取出正确节点的地址信息,然后返回转向错误。
1、安装集群插件
EPEL源安装ruby支持
[root@db02 26380]# yum install ruby rubygems -y
使用国内源
[root@db02 26380]# gem sources -l
*** CURRENT SOURCES ***
http://rubygems.org/
[root@db02 26380]# gem sources -a http://mirrors.aliyun.com/rubygems/
[root@db02 26380]# gem sources --remove http://rubygems.org/
[root@db02 26380]# gem install redis -v 3.3.3
[root@db02 26380]# gem sources -l
*** CURRENT SOURCES ***
http://mirrors.aliyun.com/rubygems/
或者:
[root@db02 26380]# gem sources -a http://mirrors.aliyun.com/rubygems/ --remove http://rubygems.org/
2、集群节点准备
[root@db02 26380]# mkdir /data/700{0..5}
[root@db02 26380]#cat >> /data/7000/redis.conf<<EOF
port 7000
daemonize yes
pidfile /data/7000/redis.pid
loglevel notice
logfile "/data/7000/redis.log"
dbfilename dump.rdb
dir /data/7000
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#cat >> /data/7001/redis.conf<<EOF
port 7001
daemonize yes
pidfile /data/7001/redis.pid
loglevel notice
logfile "/data/7001/redis.log"
dbfilename dump.rdb
dir /data/7001
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#cat >> /data/7002/redis.conf<<EOF
port 7002
daemonize yes
pidfile /data/7002/redis.pid
loglevel notice
logfile "/data/7002/redis.log"
dbfilename dump.rdb
dir /data/7002
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#cat >> /data/7003/redis.conf<<EOF
port 7003
daemonize yes
pidfile /data/7003/redis.pid
loglevel notice
logfile "/data/7003/redis.log"
dbfilename dump.rdb
dir /data/7003
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#cat >> /data/7004/redis.conf<<EOF
port 7004
daemonize yes
pidfile /data/7004/redis.pid
loglevel notice
logfile "/data/7004/redis.log"
dbfilename dump.rdb
dir /data/7004
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#cat >> /data/7005/redis.conf<<EOF
port 7005
daemonize yes
pidfile /data/7005/redis.pid
loglevel notice
logfile "/data/7005/redis.log"
dbfilename dump.rdb
dir /data/7005
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
启动节点:
[root@db02 26380]# redis-server /data/7000/redis.conf
[root@db02 26380]# redis-server /data/7001/redis.conf
[root@db02 26380]# redis-server /data/7002/redis.conf
[root@db02 26380]# redis-server /data/7003/redis.conf
[root@db02 26380]# redis-server /data/7004/redis.conf
[root@db02 26380]# redis-server /data/7005/redis.conf
[root@db02 26380]# ps -ef |grep redis
root 8854 1 0 03:56 ? 00:00:00 redis-server *:7000 [cluster]
root 8858 1 0 03:56 ? 00:00:00 redis-server *:7001 [cluster]
root 8860 1 0 03:56 ? 00:00:00 redis-server *:7002 [cluster]
root 8864 1 0 03:56 ? 00:00:00 redis-server *:7003 [cluster]
root 8866 1 0 03:56 ? 00:00:00 redis-server *:7004 [cluster]
root 8874 1 0 03:56 ? 00:00:00 redis-server *:7005 [cluster]
3、将节点加入集群管理
[root@db02 26380]#redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
Creating cluster
Performing hash slots allocation on 6 nodes...
Using 3 masters:
127.0.0.1:7000
127.0.0.1:7001
127.0.0.1:7002
Adding replica 127.0.0.1:7003 to 127.0.0.1:7000
Adding replica 127.0.0.1:7004 to 127.0.0.1:7001
Adding replica 127.0.0.1:7005 to 127.0.0.1:7002
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
S: 3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003
replicates 563df9317b87d1ac4a1fbbece6d661abca0a6640
S: 7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004
replicates bfc0aed2099b70d8e240e1adc918cbdfe0846c96
S: 35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005
replicates ebd18f50778deeb00a498d3e57fe659113fbd7d0
Can I set the above configuration? (type ‘yes‘ to accept): yes
Nodes configuration updated
Assign a different config epoch to each node
Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join...
Performing Cluster Check (using node 127.0.0.1:7000)
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: 3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003
slots: (0 slots) slave
replicates 563df9317b87d1ac4a1fbbece6d661abca0a6640
S: 7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004
slots: (0 slots) slave
replicates bfc0aed2099b70d8e240e1adc918cbdfe0846c96
S: 35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005
slots: (0 slots) slave
replicates ebd18f50778deeb00a498d3e57fe659113fbd7d0
[OK] All nodes agree about slots configuration.
Check for open slots...
Check slots coverage...
[OK] All 16384 slots covered.
[root@db02 26380]#
4、集群状态查看
集群主节点状态
[root@db02 26380]# redis-cli -p 7000 cluster nodes | grep master
ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002 master - 0 1554983371422 3 connected 10923-16383
bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001 master - 0 1554983370918 2 connected 5461-10922
563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000 myself,master - 0 0 1 connected 0-5460
集群从节点状态
[root@db02 26380]# redis-cli -p 7000 cluster nodes | grep slave
3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003 slave 563df9317b87d1ac4a1fbbece6d661abca0a6640 0 1554983423795 4 connected
7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004 slave bfc0aed2099b70d8e240e1adc918cbdfe0846c96 0 1554983422788 5 connected
35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005 slave ebd18f50778deeb00a498d3e57fe659113fbd7d0 0 1554983423292 6 connected
5、集群节点管理
5.1 增加新的节点
[root@db02 26380]#mkdir /data/7006
[root@db02 26380]#mkdir /data/7007
[root@db02 26380]#cat >> /data/7006/redis.conf<<EOF
port 7006
daemonize yes
pidfile /data/7006/redis.pid
loglevel notice
logfile "/data/7006/redis.log"
dbfilename dump.rdb
dir /data/7006
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#cat >> /data/7007/redis.conf<<EOF
port 7007
daemonize yes
pidfile /data/7007/redis.pid
loglevel notice
logfile "/data/7007/redis.log"
dbfilename dump.rdb
dir /data/7007
protected-mode no
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
EOF
[root@db02 26380]#redis-server /data/7006/redis.conf
[root@db02 26380]#redis-server /data/7007/redis.conf
[root@db02 26380]# ps -ef|grep redis
root 7145 1 0 19:47 ? 00:00:00 redis-server *:7000 [cluster]
root 7147 1 0 19:47 ? 00:00:00 redis-server *:7001 [cluster]
root 7151 1 0 19:47 ? 00:00:00 redis-server *:7002 [cluster]
root 7157 1 0 19:47 ? 00:00:00 redis-server *:7003 [cluster]
root 7159 1 0 19:47 ? 00:00:00 redis-server *:7004 [cluster]
root 7165 1 0 19:47 ? 00:00:00 redis-server *:7005 [cluster]
root 7199 1 0 19:51 ? 00:00:00 redis-server *:7006 [cluster]
root 7201 1 0 19:51 ? 00:00:00 redis-server *:7007 [cluster]
5.2 添加主节点:
[root@db02 26380]#redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000
Adding node 127.0.0.1:7006 to cluster 127.0.0.1:7000
Performing Cluster Check (using node 127.0.0.1:7000)
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: 3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003
slots: (0 slots) slave
replicates 563df9317b87d1ac4a1fbbece6d661abca0a6640
S: 7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004
slots: (0 slots) slave
replicates bfc0aed2099b70d8e240e1adc918cbdfe0846c96
S: 35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005
slots: (0 slots) slave
replicates ebd18f50778deeb00a498d3e57fe659113fbd7d0
[OK] All nodes agree about slots configuration.
Check for open slots...
Check slots coverage...
[OK] All 16384 slots covered.
Send CLUSTER MEET to node 127.0.0.1:7006 to make it join the cluster.
[OK] New node added correctly.
[root@db02 26380]#
5.3 转移slot(重新分片)
[root@db02 26380]# redis-trib.rb reshard 127.0.0.1:7000
Performing Cluster Check (using node 127.0.0.1:7000)
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
M: 8f6bf715d1d73b4b8e0a987f77f441221c700b5c 127.0.0.1:7006
slots: (0 slots) master
0 additional replica(s)
S: 3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003
slots: (0 slots) slave
replicates 563df9317b87d1ac4a1fbbece6d661abca0a6640
S: 7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004
slots: (0 slots) slave
replicates bfc0aed2099b70d8e240e1adc918cbdfe0846c96
S: 35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005
slots: (0 slots) slave
replicates ebd18f50778deeb00a498d3e57fe659113fbd7d0
[OK] All nodes agree about slots configuration.
Check for open slots...
Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096 ###16384/4的结果
What is the receiving node ID? 8f6bf715d1d73b4b8e0a987f77f441221c700b5c ###7006的ID
Please enter all the source node IDs.
Type ‘all‘ to use all the nodes as source nodes for the hash slots.
Type ‘done‘ once you entered all the source nodes IDs.
Source node #1:all ###从现有的master节点中抽选slot
Ready to move 4096 slots.
Source nodes:
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
Destination node:
M: 8f6bf715d1d73b4b8e0a987f77f441221c700b5c 127.0.0.1:7006
slots: (0 slots) master
0 additional replica(s)
Resharding plan:
Moving slot 5461 from bfc0aed2099b70d8e240e1adc918cbdfe0846c96
Moving slot 5462 from bfc0aed2099b70d8e240e1adc918cbdfe0846c96
Moving slot 5463 from bfc0aed2099b70d8e240e1adc918cbdfe0846c96
Moving slot 5464 from bfc0aed2099b70d8e240e1adc918cbdfe0846c96
....
##查看slot分配
[root@db02 26380]# redis-cli -p 7000 cluster nodes|grep master
ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002 master - 0 1554984502399 3 connected 12288-16383
bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001 master - 0 1554984501391 2 connected 6827-10922
8f6bf715d1d73b4b8e0a987f77f441221c700b5c 127.0.0.1:7006 master - 0 1554984501895 7 connected 0-1364 5461-6826 10923-12287
563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000 myself,master - 0 0 1 connected 1365-5460
[root@db02 26380]#
5.4 添加从节点
[root@db02 26380]# redis-trib.rb add-node --slave --master-id 8f6bf715d1d73b4b8e0a987f77f441221c700b5c 127.0.0.1:7007 127.0.0.1:7000
Adding node 127.0.0.1:7007 to cluster 127.0.0.1:7000
Performing Cluster Check (using node 127.0.0.1:7000)
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:1365-5460 (4096 slots) master
1 additional replica(s)
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:12288-16383 (4096 slots) master
1 additional replica(s)
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:6827-10922 (4096 slots) master
1 additional replica(s)
M: 8f6bf715d1d73b4b8e0a987f77f441221c700b5c 127.0.0.1:7006
slots:0-1364,5461-6826,10923-12287 (4096 slots) master
0 additional replica(s)
S: 3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003
slots: (0 slots) slave
replicates 563df9317b87d1ac4a1fbbece6d661abca0a6640
S: 7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004
slots: (0 slots) slave
replicates bfc0aed2099b70d8e240e1adc918cbdfe0846c96
S: 35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005
slots: (0 slots) slave
replicates ebd18f50778deeb00a498d3e57fe659113fbd7d0
[OK] All nodes agree about slots configuration.
Check for open slots...
Check slots coverage...
[OK] All 16384 slots covered.
Send CLUSTER MEET to node 127.0.0.1:7007 to make it join the cluster.
Waiting for the cluster to join.
Configure node as replica of 127.0.0.1:7006.
[OK] New node added correctly.
[root@db02 26380]# redis-cli -p 7000 cluster nodes|grep slave
3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003 slave 563df9317b87d1ac4a1fbbece6d661abca0a6640 0 1554984913690 4 connected
f7ef84f8362a90b2495fae845df9d55ca09005d8 127.0.0.1:7007 slave 8f6bf715d1d73b4b8e0a987f77f441221c700b5c 0 1554984913994 7 connected
7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004 slave bfc0aed2099b70d8e240e1adc918cbdfe0846c96 0 1554984914196 5 connected
35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005 slave ebd18f50778deeb00a498d3e57fe659113fbd7d0 0 1554984914196 6 connected
[root@db02 26380]#
6.删除节点
6.1 将需要删除节点上的slot移动走
[root@db02 26380]# redis-trib.rb reshard 127.0.0.1:7000
Performing Cluster Check (using node 127.0.0.1:7000)
M: 563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000
slots:1365-5460 (4096 slots) master
1 additional replica(s)
M: ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002
slots:12288-16383 (4096 slots) master
1 additional replica(s)
M: bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001
slots:6827-10922 (4096 slots) master
1 additional replica(s)
M: 8f6bf715d1d73b4b8e0a987f77f441221c700b5c 127.0.0.1:7006
slots:0-1364,5461-6826,10923-12287 (4096 slots) master
1 additional replica(s)
S: 3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003
slots: (0 slots) slave
replicates 563df9317b87d1ac4a1fbbece6d661abca0a6640
S: f7ef84f8362a90b2495fae845df9d55ca09005d8 127.0.0.1:7007
slots: (0 slots) slave
replicates 8f6bf715d1d73b4b8e0a987f77f441221c700b5c
S: 7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004
slots: (0 slots) slave
replicates bfc0aed2099b70d8e240e1adc918cbdfe0846c96
S: 35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005
slots: (0 slots) slave
replicates ebd18f50778deeb00a498d3e57fe659113fbd7d0
[OK] All nodes agree about slots configuration.
Check for open slots...
Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 4096
What is the receiving node ID? 563df9317b87d1ac4a1fbbece6d661abca0a6640 ##这里只能选择一个节点,这里选择7000节点
Please enter all the source node IDs.
Type ‘all‘ to use all the nodes as source nodes for the hash slots.
Type ‘done‘ once you entered all the source nodes IDs.
Source node #1:8f6bf715d1d73b4b8e0a987f77f441221c700b5c ##从7006节点上移走slot
Source node #2:done ##没有别的节点了,只从7006上移走
Moving slot 12286 from 8f6bf715d1d73b4b8e0a987f77f441221c700b5c
Moving slot 12287 from 8f6bf715d1d73b4b8e0a987f77f441221c700b5c
Do you want to proceed with the proposed reshard plan (yes/no)? yes ##输入yes
6.2删除一个节点
删除master节点之前首先要使用reshard移除master的全部slot,然后再删除当前节点
从节点删除:
[root@db02 26380]# redis-trib.rb del-node 127.0.0.1:7007 f7ef84f8362a90b2495fae845df9d55ca09005d8
Removing node f7ef84f8362a90b2495fae845df9d55ca09005d8 from cluster 127.0.0.1:7007
Sending CLUSTER FORGET messages to the cluster...
SHUTDOWN the node.
主节点删除:
[root@db02 26380]# redis-trib.rb del-node 127.0.0.1:7006 8f6bf715d1d73b4b8e0a987f77f441221c700b5c
Removing node 8f6bf715d1d73b4b8e0a987f77f441221c700b5c from cluster 127.0.0.1:7006
Sending CLUSTER FORGET messages to the cluster...
SHUTDOWN the node.
[root@db02 26380]# redis-cli -p 7000 cluster nodes|grep slave
3343b510ea04d94af422ff667b871d11cbca24e8 127.0.0.1:7003 slave 563df9317b87d1ac4a1fbbece6d661abca0a6640 0 1554985276645 8 connected
7f34ef703cbc83041fbb97f80ebc9b406acff921 127.0.0.1:7004 slave bfc0aed2099b70d8e240e1adc918cbdfe0846c96 0 1554985276646 5 connected
35e0c82a9d032fc427844d49f79fbf2958d7263d 127.0.0.1:7005 slave ebd18f50778deeb00a498d3e57fe659113fbd7d0 0 1554985277653 6 connected
[root@db02 26380]# redis-cli -p 7000 cluster nodes|grep master
ebd18f50778deeb00a498d3e57fe659113fbd7d0 127.0.0.1:7002 master - 0 1554985286225 3 connected 12288-16383
bfc0aed2099b70d8e240e1adc918cbdfe0846c96 127.0.0.1:7001 master - 0 1554985285721 2 connected 6827-10922
563df9317b87d1ac4a1fbbece6d661abca0a6640 127.0.0.1:7000 myself,master - 0 0 8 connected 0-6826 10923-12287
[root@db02 26380]#
原文:https://blog.51cto.com/10983441/2426283