三千字介绍Redis主从+哨兵+集群
共 7405字,需浏览 15分钟
·
2021-10-09 17:33
一、Redis持久化策略
1.RDB
每隔几分钟或者一段时间会将redis内存中的数据全量的写入到一个文件中去。
优点:
因为他是每隔一段时间的全量备份,代表了每个时间段的数据。所以适合做冷备份。
RDB对redis的读写影响非常小,因为redis主进程只需要fork一个子进程进行磁盘IO操作就行了。
相对于AOF来说,恢复较快,因为一个RDB就是数据文件,而AOF存的是指令日志。
缺点:
因为是一段时间才备份,所以容易丢数据。
如果一次写入的文件大,会导致读写服务暂停几毫秒,甚至几秒。
2.AOF
会将每条写入指令都写入到linux os缓存中去,然后每秒钟会将linux os中的指令作为日志追加到AOF的文件里面。
当redis内存大小达到一定的量,会通过LRU(最近最少使用)淘汰机制淘汰掉数据,然后再重写一个新的AOF文件出来。这样也保证了AOF文件不会无限制的增大。
优点:
不易丢数据
AOF日志文件是以append-only的模式写入,没有磁盘寻址的开销,写入性能高,文件也不易破损
AOF文件过大的时候,后台重写操作,也不会影响客户端。再rewrite的时候,会对指令压缩,创建出一份需要恢复的最小日志出来,再创建新日志文件时,老的文件照常写入,当新文件准备好了,再交换新老日志文件就行了
日志文件的命令是可读的,可以作为误删的紧急恢复。停了服务,再把那条删除指令删除,再恢复就行了。
缺点:
AOF日志文件占用的磁盘空间比较大
开启AOF后,写操作的QPS会下降
以前出过bug,恢复的数据和原来不一样,健壮性没有RDB高
恢复数据慢,且不适合做冷备(需要手动写脚本)
3.混合持久化(Redis 4.0)
开启混合持久化
aof-use-rdb-preamble yes
综合来说:
我们可以采用两种都用的的方案,RDB做冷备,为了保证数据不丢失,AOF做数据恢复的第一选择。
如何配置持久化?
找到/usr/local/package/redis-4.0.9/redis.conf
RDB的配置
//每隔60秒,如果有10000个key发生改变就持久化一次
save 60 10000
AOF的配置
# redis默认关闭AOF机制,可以将no改成yes实现AOF持久化
appendonly no
# AOF文件
appendfilename "appendonly.aof"
# AOF持久化同步频率,always表示每个Redis写命令都要同步fsync写入到磁盘中,但是这种方式会严重降低redis的速度;everysec表示每秒执行一次同步fsync,显示的将多个写命令同步到磁盘中;no表示让操作系统来决定应该何时进行同步fsync,Linux系统往往可能30秒才会执行一次
# appendfsync always
appendfsync everysec
# appendfsync no
# 在日志进行BGREWRITEAOF时,如果设置为yes表示新写操作不进行同步fsync,只是暂存在缓冲区里,避免造成磁盘IO操作冲突,等重写完成后在写入。redis中默认为no
no-appendfsync-on-rewrite no
# 当前AOF文件大小是上次日志重写时的AOF文件大小两倍时,发生BGREWRITEAOF操作。
auto-aof-rewrite-percentage 100
#当前AOF文件执行BGREWRITEAOF命令的最小值,避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF。
auto-aof-rewrite-min-size 64mb
# Redis再恢复时,忽略最后一条可能存在问题的指令(因为最后一条指令可能存在问题,比如写一半时突然断电了)
aof-load-truncated yes
#Redis4.0新增RDB-AOF混合持久化格式,在开启了这个功能之后,AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容,其中RDB格式的内容用于记录已有的数据,而AOF格式的内存则用于记录最近发生了变化的数据,这样Redis就可以同时兼有RDB持久化和AOF持久化的优点(既能够快速地生成重写文件,也能够在出现问题时,快速地载入数据)。
aof-use-rdb-preamble no
AOF rewrite过程
redis fork一个子进程
子进程基于当前内存中的数据开始写入一个新的aof的文件
这时新的命令进来,会存在内存中,也会存在旧的aof文件中
当新的aof文件写好了,这个过程中的新的命令也会追加到aof里来
然后用新日志文件替换掉旧的日志文件
注意:当使用shutdown命令关闭redis服务时,会自动备份一个快照
。
当RDB生成快照时,AOF不会rewrite。反之亦然。
redis如果遇到断电或机器故障问题时怎么办?
答:一般使用持久化加服务器文件(将文件备份到阿里云)备份的方案
二、Redis淘汰策略
LRU:(least recently used)最近最少使用
标准的LRU算法:
使用HashMap+双向链表
核心步骤:
save操作时,在hashmap中找对应的key值,如果存在,更新他并移到队头,如果不存在,则构建新节点,并移到队头,如果队列满了,则移除队尾的节点,并在hashmap中移除该key
get操作时,在hashmap中找到对应的节点,将他移到队头
redis里面没有使用双向链表的实现方式,而是使用了一个pool池.
Redis的LRU实现
常用策略:allkeys-lru
Redis使用的是近似LRU算法
给每个 key 增加一个额外 24bit 长度的小字段, 存储该 key 的最后一次访问时间戳
当空间满时, 随机采样取出 5 个 key (数量可配置), 按时间戳淘汰掉最旧的 key
循环第二步, 直到内存低于 maxmemory 值
随机采样的范围取决于配置的策略是 volatile 还是 allkeys
Redis 3.0 开始, 增加了淘汰池进一步提升了近似 LRU 的效果:
上一次随机采样后未淘汰的 key, 会放入 淘汰池 留待下一次循环,
下一次随机采样的key会先和淘汰池中的key合并后, 再计算淘汰最旧的key
三、Redis主从架构
1.主从特性
采用异步的方式复制到slave节点,不过redis2.8之后,每个slave节点会周期性的确认自己每次复制的数据量
一个master可以配置多个slave
slave node也可以连接其他的slave node
slave复制时不影响master的工作
slave复制时也不会影响slave的查询操作,他会用旧的数据提供服务。但是当复制完成,需要删除旧数据,加载新数据集时,会暂停服务。
slave主要用来做横向扩容,做读写分离
2.主从复制步骤
当slave第一次连接时,master会生成一个全量RDB文件给他做恢复,并将这个过程中新的写入命令缓存在内存中,等slave把RDB文件读入之后发给他
当slave断开一段时间后重连,master会将缺失的数据发给他
平时情况下,master收到一个指令,都会马上复制给slave
3.断点续传
从redis2.8开始,就支持主从复制的断点续传
master中存了backlog,master和slave都会保存一个replica offset,还有一个master id。如果中途网络断了,slave会让master从上次的replica offset开始继续复制。
4.过期key处理
slave不会过期key,只会等master过期key之后或者根据,模LRU淘汰了key之后拟一个del命令发给slave
5.配置主从服务器
安装redis
cp utils/redis_init_script /etc/init.d/redis_6379
redis自启动 chkconfig redis_6379 on
mkdir /etc/redis
mkdir -p /var/redis/6379
cp redis.conf /etc/redis/6379.conf
修改配置文件6379.conf
daemonize yes //让redis以daemon进程运行
dir /var/redis/6379
slaveof CentOS01 6379
slave 服务器的配置文件上配 masterauth 123456
master服务器的配置文件上配
requirepass 123456每个6379.conf里都要将bind 127.0.0.1改成bind 自己本机的ip
让redis跟随系统启动自动启动
在redis_6379脚本中,最上面,加入两行注释
#chkconfig: 2345 90 10
#description: Redis is a persistent key-value database
然后执行
chkconfig redis_6379 on
8. 压测性能 ./redis-benchmark -c 50 -n 10000
复制原理图:
注意:主从架构建议必须开启master节点的持久化。
四、哨兵模式
1.概念介绍
介绍:
集群监控,监控master和slave是否正常
消息通知,如果某个redis实例故障了,负责发消息给管理员
故障转移,如果master节点挂掉了,会自动转移到slave上
配置中心,如果故障转移发生了,通知client新的master地址
2.故障转移
哨兵至少要3个实例
如图:
如果只有2个哨兵会如何呢?
master宕机,s1和s2中只要有1个哨兵认为master宕机就可以进行切换,同时s1和s2中会选举出一个哨兵来执行故障转移
同时这个时候,需要majority,也就是大多数哨兵都是运行的,2个哨兵的majority就是2(2的majority=2,3的majority=2,5的majority=3,4的majority=2),2个哨兵都运行着,就可以允许执行故障转移
但是如果整个M1和S1运行的机器宕机了,那么哨兵只有1个了,此时就没有majority来允许执行故障转移,虽然另外一台机器还有一个R1,但是故障转移不会执行
3.解决异步复制和脑裂导致的数据丢失
min-slaves-to-write 1
min-slaves-max-lag 10
要求至少有1个slave,数据复制和同步的延迟不能超过10秒
4.sdown和odown转换机制
sdown:主观宕机,即一个哨兵觉得master宕机了
odown:客观宕机,即quorum数量的哨兵觉得master宕机了
5.哨兵集群的自动发现机制
哨兵互相之间的发现,是通过redis的pub/sub系统实现的,每个哨兵都会往__sentinel__:hello这个channel里发送一个消息,这时候所有其他哨兵都可以消费到这个消息,并感知到其他的哨兵的存在
每隔两秒钟,每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息,内容是自己的host、ip和runid还有对这个master的监控配置
每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在
每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步
6.选举算法
如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,此时首先要选举一个slave来
会考虑slave的一些信息
(1)跟master断开连接的时长
(2)slave优先级
(3)复制offset
(4)run id
7.部署哨兵
复制配置文件
mkdir -p /var/sentinel/5000
mkdir /etc/sentinel
mkdir -p /var/log/sentinal/5000
mv /usr/local/package/redis-4.0.9/sentinel.conf /etc/sentinel/5000.conf
修改配置文件
port 5000
bind 192.168.1.14
sentinel monitor mymaster 192.168.1.12 6379 2
dir /var/sentinel/5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 60000
sentinel down-after-milliseconds mymaster 30000
sentinel auth-pass mymaster 123456
daemonize yes
logfile /var/log/sentinal/5000/sentinel.log
注意:sentinel monitor mymaster 192.168.1.12 6379 2 这行要放在使用mymaster的那些其他配置之前
启动哨兵
./redis-sentinel /etc/sentinel/5000.conf
五、redis集群
1.概念介绍
自动对数据进行分片,每个master上存放一部分数据
提供内置的高可用支持,部分master不可用了,还是可以继续工作的
2.部署选型
redis cluster VS replication + sentinel
当数据量少,主要承载的是高并发时,单机就足够了。一个master多个slave,在搭建一个sentinel集群来保证高可用性
redis cluster主要还是用来做海量数据的缓存。
3.分布式Hash算法
当需要把数据分到不同的几个机器存储时,就需要一个算法了。
方法一:取模
对数据的hash值取模,比如有3台集器,那么就用hash%3,得到的就是0-2的三个数字,就可以确定将数据存在哪一台上面了
缺点:如果有一台机器挂掉了,那么数据会对2取模,那么得到的机器号就错乱了,导致大量数据不能从正确的机器上去取
方法二:一致性hash算法(圆环算法)
将3台机器放在一个圆环上,然后要缓存的数据经过计算也落在圆环的某一个点,然后顺时针去环上找离他最近的那个机器。
优点:当一台机器挂掉,不影响其他的机器上存的数据
缺点:具有热点问题,可能某一个机器会有大量数据,这就需要将每个机器都多设置几个虚拟节点,均匀分布在圆环上。
方法三:redis cluster的hash slot算法
redis cluster有固定的16384个slot,对每个key计算CRC16值,然后对16384取模,获取对应的slot,每个master都有部分的slot。这样的话如果增加一个master,就将其他master上的slot分点给她就行了。
4.部署redis集群
创建目录
mkdir -p /etc/redis-cluster
mkdir -p /var/log/redis
mkdir /var/redis/7001
mkdir /var/redis/7002
修改配置文件 7001.conf
port 7001
cluster-enabled yes
cluster-config-file /etc/redis-cluster/node-7001.conf
cluster-node-timeout 15000
pidfile "/var/run/redis_7001.pid"
dir "/var/redis/7001"
logfile "/var/log/redis/7001.log"
修改配置文件
vi /usr/local/share/gems/gems/redis-3.2.1/lib/redis/client.rb
password=123456
执行
echo never > /sys/kernel/mm/transparent_hugepage/enabled
启动脚本
cd /etc/init.d/
cp redis_6379 redis_7001
修改redis_7001配置
REDISPORT=7001
安装ruby
yum install -y ruby
下载一个redis-3.2.1.gem,然后执行
gem install redis
cp /usr/local/package/redis-4.0.9/src/redis-trib.rb /usr/local/bin
/usr/local/bin/redis-trib.rb create --replicas 1 192.168.1.12:7001 192.168.1.12:7002 192.168.1.13:7003 192.168.1.13:7004 192.168.1.14:7005 192.168.1.14:7006
检查节点状态
./redis-trib.rb check 192.168.1.12 7001
作者 | 女友在高考
来源 | cnblogs.com/javammc/p/15358177.html