redis3.0集群特性
主从复制(读写分离)
主从复制的好处有2点:
- 1、 避免redis单点故障
- 2、 构建读写分离架构,满足读多写少的应用场景
设置主从
创建6379、6380、6381目录,分别将安装目录下的redis.conf拷贝到这三个目录下。
分别进入这三个目录,分别修改配置文件,将端口分别设置为:6379(Master)、6380(Slave)、6381(Slave)。同时要设置pidfile文件为不同的路径。
在redis中设置主从有2种方式:
- 1、 在redis.conf中设置slaveof
a) slaveof - 2、 使用redis-cli客户端连接到redis服务,执行slaveof命令
a) slaveof
第二种方式在重启后将失去主从复制关系。
查看主从信息:INFO replication
主:
role:角色
connected_slaves:从库数量
slave0:从库信息
从:
主从从架构
从库只读
默认情况下redis数据库充当slave角色时是只读的不能进行写操作。
可以在配置文件中开启非只读:slave-read-only no
复制的过程原理
- 1、 当从库和主库建立MS关系后,会向主数据库发送SYNC命令;
- 2、 主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程),并将期间接收到的写命令缓存起来;
- 3、 当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis;
- 4、 从Redis接收到后,会载入快照文件并且执行收到的缓存的命令;
- 5、 之后,主Redis每当接收到写命令时就会将命令发送从Redis,从而保证数据的一致;
无磁盘复制
通过前面的复制过程我们了解到,主库接收到SYNC的命令时会执行RDB过程,即使在配置文件中禁用RDB持久化也会生成,那么如果主库所在的服务器磁盘IO性能较差,那么这个复制过程就会出现瓶颈,庆幸的是,Redis在2.8.18版本开始实现了无磁盘复制功能(不过该功能还是处于试验阶段)。
原理:
Redis在与从数据库进行复制初始化时将不会将快照存储到磁盘,而是直接通过网络发送给从数据库,避免了IO性能差问题。
开启无磁盘复制:repl-diskless-sync yes
复制架构中出现宕机情况,怎么办?
如果在主从复制架构中出现宕机的情况,需要分情况看:
1、 从Redis宕机
不会的,因为在Redis2.8版本后就实现了,主从断线后恢复的情况下实现增量复制。
2、 主Redis宕机
这个相对而言就会复杂一些,需要以下2步才能完成
这个手动完成恢复的过程其实是比较麻烦的并且容易出错,有没有好办法解决呢?当前有的,Redis提高的哨兵(sentinel)的功能。
哨兵(sentinel)
什么是哨兵
顾名思义,哨兵的作用就是对Redis的系统的运行情况的监控,它是一个独立进程。它的功能有2个:
- 1、 监控主数据库和从数据库是否运行正常;
- 2、 主数据出现故障后自动将从数据库转化为主数据库;
原理
单个哨兵的架构:
多个哨兵的架构:
多个哨兵,不仅同时监控主从数据库,而且哨兵之间互为监控。
配置哨兵
启动哨兵进程首先需要创建哨兵配置文件:
输入内容:
说明:
启动哨兵进程:
由上图可以看到:
- 1、 哨兵已经启动,它的id为9059917216012421e8e89a4aa02f15b75346d2b7
- 2、 为master数据库添加了一个监控
- 3、 发现了2个slave(由此可以看出,哨兵无需配置slave,只需要指定master,哨兵会自动发现slave)
配置多个哨兵
输入内容:
集群
即使有了主从复制,每个数据库都要保存整个集群中的所有数据,容易形成木桶效应。
使用Jedis实现了分片集群,是由客户端控制哪些key数据保存到哪个数据库中,如果在水平扩容时就必须手动进行数据迁移,而且需要将整个集群停止服务,这样做非常不好的。
Redis3.0版本的一大特性就是集群(Cluster),接下来我们一起学习集群。
架构
- (1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
- (2)节点的fail是通过集群中超过半数的节点检测失效时才生效.
- (3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
- (4)redis-cluster把所有的物理节点映射到[0-16383]slot(插槽)上,cluster 负责维护node<->slot<->value
修改配置文件
- 1、 设置不同的端口,6379、6380、6381
- 2、 开启集群,cluster-enabled yes
- 3、 指定集群的配置文件,cluster-config-file “nodes-xxxx.conf”
创建集群
首先,进入redis的安装包路径下:
cd /usr/local/src/redis/redis-3.0.1/src/
执行命令:
–replicas 0:指定了从数据的数量为0
注意:这里不能使用127.0.0.1,否则在Jedis客户端使用时无法连接到!
redis-trib用法:
测试
什么情况??(error) MOVED 7638 127.0.0.1:6380
因为abc的hash槽信息是在6380上,现在使用redis-cli连接的6379,无法完成set操作,需要客户端跟踪重定向。
插槽的分配
通过cluster nodes命令可以查看当前集群的信息:
该信息反映出了集群中的每个节点的id、身份、连接数、插槽数等。
当我们执行set abc 123命令时,redis是如何将数据保存到集群中的呢?执行步骤:
整个Redis提供了16384个插槽,也就是说集群中的每个节点分得的插槽数总和为16384。
./redis-trib.rb 脚本实现了是将16384个插槽平均分配给了N个节点。
注意:如果插槽数有部分是没有指定到节点的,那么这部分插槽所对应的key将不能使用。
插槽和key的关系
计算key的插槽值:
key的有效部分使用CRC16算法计算出哈希值,再将哈希值对16384取余,得到插槽值。
什么是有效部分?
- 1、 如果key中包含了{符号,且在{符号后存在}符号,并且{和}之间至少有一个字符,则有效部分是指{和}之间的部分;
a) key={hello}_tatao的有效部分是hello - 2、 如果不满足上一条情况,整个key都是有效部分;
a) key=hello_taotao的有效部分是全部
新增集群节点
再开启一个实例的端口为6382
执行脚本:
已经添加成功!查看集群信息:
发现没有插槽数。
接下来需要给6382这个服务分配插槽,将6379的一部分(1000个)插槽分配给6382:
查看节点情况:
删除集群节点
想要删除集群节点中的某一个节点,需要严格执行2步:
1、 将这个节点上的所有插槽转移到其他节点上;
2、 使用redis-trib.rb删除节点
故障机制
集群中的主从复制架构
架构:
出现故障:
4.9.3. 创建主从集群
需要启动6个redis实例,分别是:
6379(主) 6479(从)
6380(主) 6480(从)
6381(主) 6481(从)
启动redis实例:
创建集群,指定了从库数量为1,创建顺序为主库(3个)、从库(3个):
创建成功!查看集群信息: