Laoshiren

中文

中文

Appearance

Return to top
On this page

Redis

Redis.conf详情

启动的时候，就通过配置文件来启动！

单位不敏感

在这里插入图片描述

可以包含其他配置文件

在这里插入图片描述

NETWORK

shell
bind 127.0.0.1 # 绑定的IP,只允许本机访问
protected-mode yes # 保护模式
port 6379		# 端口
tcp-backlog 511
timeout 0 		# 客户端永不超时 单位秒
tcp-keepalive 300 # 客户端心跳检测300s 检查一次
1
2
3
4
5
6

GENERAL

shell
daemonize yes 	# 是否以守护进程开启 默认是no
pidfile /var/run/redis_6379.pid # 在此文件中保存进程号
loglevel notice	# 日志级别
logfile ""		# 日志文件默认为空
databases 16 	# 数据库
always-show-logo yes # 显示logo
1
2
3
4
5
6

SNAPSHOT

持久化，在规定的时间欸执行了多少次操作，怎会持久化到文件，.rdb .aof

redis 是内存数据库，如果美欧持久化那么数据断电即失

shell
# 如果 **秒内 有*个KEY进行更改就持久化
save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes # 持久化错误之后是否继续进行工作
rdbcompression yes 	# 是否压缩rdb文件
rdbchecksum	yes		# 保存rdb文件检查校验
dbfilename dump.rdb
dir ./				# 目录 当前文件夹下
1
2
3
4
5
6
7
8
9
10

SECURITY

shell
# requirepass  默认是没有密码的
1

通过命令设置密码

shell
 # 默认没有
config get requirepass
# 设置密码
config set requirepass "123456"

# 尝试去PING
ping 
(error) NOAUTH Authentication required.
# 登录
auth 123456
1
2
3
4
5
6
7
8
9
10

CLIENTS

客户端限制

shell
maxclients 10000 # 最大连接数
1

MEMORY MANAGEMENT

shell
maxmemory <bytes> # 最大内存设置
maxmermory-policy noeviction # 内存到达最大的策略
1
2
  • volatile-lru: 之对设置了过期时间的key进行lru
  • volatile-random: 随机删除过期的key
  • volatile-ttl: 删除过期key
  • allkeys-lru: 删除lru算法的key
  • allkeys-random: 随机删除
  • noeviction: 永不过期返回错误

APPEND ONLY MODE

shell
appendonly no # 默认不开启
appendfilename "appendonly.aof"

# 同步策略
# appendfsync always		# 每次修改都会写入
appendfsync everysec 	# 每秒同步一次
# appendfsync no			# 不同步

no-appendfsync-on-rewrite no # 重写
auto-aof-rewrite-percentage 100
auto-aofrewrite-min-size 64mb
1
2
3
4
5
6
7
8
9
10
11

REDIS 持久化

RDB

在这里插入图片描述

在指定的时间间隔内，将内存中的数据集快照写入磁盘，也就是讲的SNAAPSHOT 快照，它恢复时是从快照文件直接读到内存里。

Redis 会单独创建（fork）一个紫荆城来进行持久化，会先将数据写入到一个临时文件中。待持久化过程结束了，再用这个临时文件替换上次持久化好的文件。这个过程，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的回复，且对于数据恢复的完整性不是非常明干那RDB方式要比AOF方式更加高效。RDB的缺点就是最后一次数据持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！

RDB保存的文件是dump.rdb，上文的配置文件已经说明。

触发机制

  • save的规则满足的情况下
  • 执行flushall 命令
  • 退出redis

就会执行RDB，备份就会生成一个 x.rdb文件

恢复数据

只需要将rdb文件放在redis 启动目录下就可以，redis启动会自动检查 rdb文件恢复其中的数据

查看需要存放的位置config get dir

优点

  • 适合大规模的数据恢复
  • 如果对数据完整性不高

缺点

  • 需要一定的时间间隔，可能存在最后一次的数据丢失
  • fork 进程占用内存空间。

AOF

将我们所有的命令都记录下来，恢复的时候就把这个文件全部执行一边

在这里插入图片描述

以日志的形式记录每一个写操作，将Redis 执行过所有的指令记录下来，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构造数据，换言之Redis 重启的话就更具日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作

AOF 保存的是 appendonly.aof文件，配置文件查看上文 APPEND ONLY MODE

在这里插入图片描述

如果这个AOF文件有错误，这个时候redis 是启动不了的，需要修复这个aof 文件，redis 提供了一个工具redis-check-aof --fix 就会把错误的行删除。当aof 文件正常后，重启恢复数据。

优点

  • 每次修改都同步，文件完整性更加好
  • 默认开启每秒同步。

缺点

  • 数据文件来说，AOF远远大于RDB，修复速度比RDB慢。
  • AOF运行效率比RDB慢，默认的配置就是RDB的持久化。

REDIS 主从复制

概念

主从复制，只是将一台Redis 服务器的数据，复制到其他Redis 服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)。数据的复制是单向的，只能从主节点到从节点。Master 以写为主。Slave 以读为主。

默认情况下，每台Redis 服务器都是主节点，且一个主节点可以有多个从节点(或没有从节点)，但是一个从节点只能有一个主节点。

在这里插入图片描述

作用

包括：

  1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的数据冗余。
  2. 故障恢复：当主节点出现问题，可以由从阶段提供服务，实现快速的故障恢复。
  3. LB：在主从复制的基础之上配合读写分离，可以由主节点提供服务，有从节点提供读服务（即写Redis 使用主节点，读Redis 使用从节点），分摊服务负载；尤其在写少读多的场景下，通过多个从阶段分摊读负担，可以大大提高Redis 服务器的并发量。
  4. 高可用基石：除了上述作用外，主从赋值还是烧饼和集群能够实施的基础，因此说主从是Redis 高可用的基石。

环境搭建

shell
info replication # 查看信息

# Replication
role:master				# 角色 默认主机
connected_slaves:0		# 从机个数
master_replid:cc087c50b1b69f791b1f0ab61ccb473453e098a9
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
1
2
3
4
5
6
7
8
9
10
11
12
13

在从机上确认主机

shell
SLAVEOF 127.0.0.1 6379
OK

info replication # 查看信息 
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:56
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:8f6073b6513dcb11071a51daae971c3020ca245c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

查看主机配置

shell
info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=238,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=238,lag=0
master_replid:8f6073b6513dcb11071a51daae971c3020ca245c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:238
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:238
1
2
3
4
5
6
7
8
9
10
11
12
13
14

如果主机断开了连接可以使用SLAVEOF no one 让自己成为主机

REPLICATION

==真实的主从应该从配置文件配置主从，命令指示暂时的，如果是命令配置的主从，从机重启后就会变回主机==

shell
slaveof 12730.0.1 6379 # 主节点信息
masterauth 123456		# 主节点密码 可能没有
1
2

复制原理

Slave 启动成功链接到Master 后，会发送一个sync 同步命令

Master 接到命令，启动后台的存盘进程，同时收集所有接收到用于修改数据命令，在后台进程执行完毕之后，Master 将传送整个数据文件到 Slave 并完成一次完全同步。

全量复制：而slave 服务在接收到数据库文件数据后，将其存盘并且加载到内存中。

增量复制：Master 继续将新的所有收集到的修改命令一次传给Slave ，完成同步。

但是只要是重新连接Master 一次全量复制将被自动执行。

哨兵模式

SENTINEL

概念

主从切换技术的方法是：当服务器宕机后需要收到把一台服务器切换为主服务器，这就需要人工干预，还会造成一段时间的服务不可用。Redis 从2.8开始正式提供了Sentinel 架构来解决这个问题。

他能够后台监控主机是否故障，如果故障根据投票自动将从库转换为主库。

Sentinel 是一种特殊的模式，首先Redis 提供了哨兵命令，哨兵是一个独立进程。原理是哨兵通过发送命令，等待Redis 服务响应从而监控多个Redis 实例。

在这里插入图片描述

通过发送命令，让Redis 服务器返回，监控其运行状态，包括主从服务器。当哨兵检测到Master 宕机，会自动将Slave 切换为Master ，然后通过发布订阅模式通知到其他从服务器，修改配置文件，让他们切换主机。

然而一个哨兵可能也会出现问题，为此，可以使用多哨兵进行监控，各个哨兵还会彼此监控。

在这里插入图片描述

假设主服务器宕机，哨兵1检测到这个结果，系统不会马上failover (故障转移切换主节点)，仅仅是哨兵1认为这个主服务器不可用（主观下线），当其他哨兵也检测到主服务器不可用，并且数量到达一定值时。哨兵之间会进行一次投票，投票由一个哨兵发起，进行failover 。切换成功后就通过发布订阅模式，让哥哥哨兵把自己监控的从服务器实现切换主机（客观下线）

配置

配置 sentinel.conf

shell
# sentinel monitor 主机名称 ip port 1 表示主机挂了，投票让slave接替主机  
sentinel monitor redis_master 127.0.0.1 6379 1
1
2

启动哨兵redis-sentinel redis-config/sentinel.conf

优点

  • 哨兵基于主从复制模式
  • 主从可以切换，故障转移，系统可用性会更好

缺点

  • Redis 不好扩容
  • Sentinel 配置繁琐

Released under the MIT License.

Copyright © 2018-present Laoshiren