Redis数据库
通过学习:熟悉并掌握主流非关系型数据库Redis的使用及集群的基本搭建维护。
文章目录
- Redis数据库
- Redis
- 一、Redis是什么?
- 二、Redis的持久化
- 1.RDB模式
- RDB相关配置
- 手动实现RDB数据快照
- 2.AOF模式
- 3.RDB和AOF的优缺点
- RDB 模式优缺点
- AOF模式优缺点
- 三、Redis的master和slave同步过程
- 1.Redis主从复制架构
- 2.Redis主从复制的实现
- 四、Redis的sentinel的实现机制和搭建
- 1.Redis的sentinel简介
- 2.Redis sentinel的实现机制
- 3.sentinel集群搭建
- 五、redis cluster集群创建和使用
- 1.集群的特点
- 2.Redis集群架构
- 3.Redis集群的搭建
- 总结
Redis
随着互联网业务的快速发展,传统的关系型数据库在并发性能方面越来越显不足,以此衍生出非关系型的数据库以支撑业务的高并发量。本文就介绍了Redis的基础内容。
一、Redis是什么?
Redis是一个开源的、遵循BSD协议的、基于内存的而且目前比较流行的键值数据库(key-value database),是一个非关系型数据库,Redis 提供将内存通过网络远程共享的一种服务,提供类似功能的还有memcached,但相比memcached,redis还提供了易扩展、高性能、具备数据持久性等功能。
二、Redis的持久化
1.RDB模式
基于时间的快照,其默认只保留当前最新的一次快照,特点是执行速度比较快,缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据
RDB相关配置
#RDB相关配置
save 900 1
save 300 10
save 60 10000 #此为RDB的默认保存策略
dbfilename dump.rdb
dir ./ #编泽编译安装,默认RDB文件存放在启动redis的工作目录,建议明确指定存入目录
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
手动实现RDB数据快照
#该命令同步执行会阻塞其他命令的执行 会影响线上业务 不推荐使用
127.0.0.1:6379>save
#该命令异步执行 非阻塞型 推荐使用
127.0.0.1:6379>bgsave
2.AOF模式
AOF:AppendOnylFile,按照操作顺序依次将操作追加到指定的日志文件末尾。会记录每次执行的操作类似MySQL的二进制文件。使用了写时复制机制,AOF默认为每秒钟 fsync一次。同时启用RDB和AOF,进行恢复时,默认AOF文件优先级高于RDB文件,即会使用AOF文件进行恢复。
3.RDB和AOF的优缺点
RDB 模式优缺点
优点:
- RDB 模式可以通过脚本执行bgsave命令实现定期的备份。并可以保留多个时间段的备份版本,后续可以通过第三方工具对数据进行数据分析。
- RDB在备份大量数据时速度快于AOF适合在服务器迁移过程中使用。
缺点:
- 不能实时保存数据,存在丢失上一次执行备份到当前时间的部分数据。
- 当数据量非常大的时候,从父进程fork子进程进行保存至RDB文件时需要一点时间,可能是毫秒或者秒,取决于磁盘IO性能
AOF模式优缺点
优点:
- 数据安全性高,可根据fsync策略及时同步数据到文件中,及时断电停机也不会导致数据大量丢失,最多会丢失一秒数据(按照默认的fsync策略)。
- 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中不需要seek, 即使出现宕机现象,也不会破坏日志文件中已经存在的内容。在Redis下一次启动之前,可以通过 redis-check-aof 工具来解决数据一致性的问题
- Redis可以在 AOF文件体积变得过大时,自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。
- AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。可以通过修改文件重建之前丢失的数据。如误操作FLUSHALL等。
缺点:
- 即使有些操作是重复的也会全部记录,AOF 的文件大小要大于 RDB 格式的文件。
- AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
- 根据fsync策略不同,AOF速度可能会慢于RDB
生产中建议同时开启两种模式,或者仅开启AOF模式,根据业务的的实际情况确定。同时在先开启RDB模式的情况下通过修改配置文件开启AOF重启后会导致rdb文件被清空。正确操作方式为在命令行中用config命令开启AOF模式然后在修改配置文件实现永久有效。
三、Redis的master和slave同步过程
1.Redis主从复制架构
在Redis主从复制中,仅由master节点实现对数据的写操作,slave节点只允许读取不允许写入。master节点和slave节点中间通过TCP连接实现数据单向的传输。
2.Redis主从复制的实现
#实验一两台centos8主机为例ip分别为master:10.0.0.8 salve:10.0.0.18
#yum安装Redis
yum install -y redis
#修改配置文件 主从复制强烈建议启用持久化功能 并需要设置相同密码 后期可结合sentinel 实现宕机自动迁移
#从节点配置文件修改一下内容设置
sed -i.bak -e "s/bind 127.0.0.1/bind 0.0.0.0/" -e "s/daemonize no/daemonize yes/" -e "s/appendonly no/appendonly yes/" -e "s/# requirepass foobared/requirepass logn/" -e "s/# masterauth <master-password>/masterauth logn/" -e "s/# replicaof <masterip> <masterport>/replicaof 10.0.0.8 6379/" /etc/redis.conf
#主节点修改一下内容
sed -i.bak-e "s/bind 127.0.0.1/bind 0.0.0.0/" -e "s/daemonize no/daemonize yes/" -e "s/appendonly no/appendonly yes/" -e "s/# requirepass foobared/requirepass logn/" -e "s/# masterauth <master-password>/masterauth logn/" /etc/redis.conf
#分别启动redis
systemctl enable --now redis
#查看主从复制情况
redis-cli -a logn info replication
#可以看到从节点和主节点信息
主节点信息
从节点信息
四、Redis的sentinel的实现机制和搭建
1.Redis的sentinel简介
在主从复制集群中主节点和在单个从节点的情况下都存在单点故障一旦某个机器宕机都会导致服务不可用。Redis的sentinel就是为解决这个问题。在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossip protocols)来接收关于Master主服务器是否下线的信息,并使用投票协议(Agreement
Protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。从而实现高可用。
2.Redis sentinel的实现机制
sentinel建构在主从复制集群只上,建议至少集群中有三台机器实现。Sentinel实际上是一个特殊的redis服务器,有些redis指令支持,但很多指令并不支持.默认监听在26379/tcp端口.一般需要部署3,5,7奇数个节点避免出现脑裂问题。
3.sentinel集群搭建
#准备配置文件
sed -i -e 's/# bind 127.0.0.1 192.168.1.1/bind 0.0.0.0/' -e 's/daemonize no/daemonize yes/' -e 's/sentinel monitor mymaster 127.0.0.1 6379 2/sentinel monitor mymaster 10.0.0.8 6379 2/' -e 's/sentinel down-after-milliseconds mymaster 30000/sentinel down-after-milliseconds mymaster 3000/' -e 's/# sentinel auth-pass <master-name> <password>/sentinel auth-pass mymaster logn/' -e 's/logfile "sentinel.log"/#logfile ""/' /etc/redis-sentinel.conf
#启动sentinel
systemctl enable --now redis-sentinel.service
#查看端口
ss -tnl
查看sentinel状态
模拟集群故障
#在master节点上
killall redis-server
可以看到master节点发生重新选举
在现存master节点上查看
在重新修复节点后自动添加进集群中
五、redis cluster集群创建和使用
在哨兵sentinel机制中,可以解决redis高可用问题,即当master故障后可以自动将slave提升为master,从而可以保证redis服务的正常使用,但是无法解决redis单机写入的瓶颈问题,即单机redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素。因此官方就此推出了集群模式。可以大大的横向拓展集群,解决性能瓶颈。
1.集群的特点
- 所有Redis节点使用(PING机制)互联
- 集群中某个节点的是否失效,是由整个集群中超过半数的节点监测都失效,才能算真正的失效
- 客户端不需要proxy即可直接连接redis,应用程序中需要配置有全部的redis服务器IP
- redis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上,读写需要到指定的redisnode上进行操作,因此有多少个redis node相当于redis 并发扩展了多少倍,每个redis node 承担16384/N个槽位
- Redis cluster预先分配16384个(slot)槽位,当需要在redis集群中写入一个key -value的时候,会使用CRC16(key) mod 16384之后的值,决定将key写入值哪一个槽位从而决定写入哪一个Redis节点上,从而有效解决单机瓶颈。
2.Redis集群架构
主节点之间通过ping互相通信监督对方,主节点与对应的从节点之间可宕机自动迁移。确保每一组集群的高可用性。前端提供程序调用接口随机的将数据分配到个slot中。slot通过事先定义好的规则分布在个master节点上。
3.Redis集群的搭建
- 准备6台centos 8的机器
- 在所以机器上修改配置文件
#修改配置文件
sed -i -e 's/# cluster-enabled no/cluster-enabled yes/' -e 's/# cluster-config-file nodes-6379.conf/cluster-config-file nodes-6379.conf/' -e 's/# cluster-replica-no-failover no/cluster-replica-no-failover no/' /etc/redis.conf
- 启动Redis集群模式
#启动Redis集群模式
systemctl start redis.service
- 选任意节点与其他节点meet建立通信连接
#建立连接
redis-cli -a logn --cluster create 10.0.0.8:6379 10.0.0.18:6379 10.0.0.28:6379 10.0.0.38:6379 10.0.0.48:6379 10.0.0.58:6379 --cluster-replicas 1
- 查看节点情况
redis-cli -a logn cluster nodes
redis-cli -a logn cluster info
- 验证数据写入
#使用-c选项可以move到相应节点写入key
redis-cli -a logn -c set name key
节点自动实现move
查看数据
- 模拟节点宕机实现master自动迁移
在这里插入代码片
在master节点宕机的情况下自动迁移到相对应的slave节点之上。
恢复后自动变成slave节点自动加入集群中
总结
以上对本文的内容做个总结。本文简单介绍了Redis非关系型数据库的在互联网业务中的使用场景。简要介绍了Redis数据库可持久化RDB和AOF的有缺点,以及Redis的为解决数据读写瓶颈的主从复制及基于主从复制实现的sentinel宕机自动迁移。同时着重介绍可Redis的集群模式,可以大大缓解业务在互联网中的流量压力,可以确保后端数据库的安全,为用户提供更好的服务能力。