系列文章目录
(一)2023Redis(windows+Linux)安装及入门教程
(二)Redis中的五大数据类型
(三)Redis中的三种特殊类型
(四)Redis实现乐观锁
(五)SpringBoot整合Redis详细教程
(六)Redis配置文件详解以及持久化和订阅发布
(七)Redis集群详解
(八)Redis缓存穿透以及击穿和雪崩
文章目录
前言
本文详细讲述了Redis的配置文件,持久化,订阅发布的内容,该文是Redis进阶知识的第一篇,过后会讲解集群环境搭建,主从复制,哨兵模式详解等,如果本文对你有帮助,麻烦 点赞+收藏+关注( •̀ ω •́ )✧
一、Redis配置文件详解🥗
单位
unit单位对大小写不敏感
包含
'includes’部分用于引入其他配置文件。这种方式可以让Redis的配置更加模块化和易于管理。例如,你可以将一些常见的配置选项放在一个单独的配置文件中,然后在主配置文件中通过’include’指令来引入这些配置。被包含的配置文件通常包含一些通用的设置,如服务器运行的端口,启动和关闭服务器的选项,以及一些全局的ACL和环境设置等。
可以类比import和include
模块
这是Redis从5.0版本开始引入的一种扩展机制。Redis Modules允许开发者在Redis核心中添加新的命令和数据类型,从而极大地扩展了Redis的功能。模块可以提供新的键空间,新的命令,或者新的数据类型,甚至是修改现有的数据类型。
网络
'network’相关的配置通常涉及服务器网络连接的参数。
bind 127.0.0.1 #绑定的ip
protected-mode yes #保护模式
port 6379 #端口设置
- bind:该选项用于指定Redis服务器监听的网络接口。你可以指定一个或多个地址,用空格分隔。例如,'bind 127.0.0.1 192.168.1.100’表示在本地和指定的网络接口上监听连接。
- protected-mode:此选项是一个安全选项,用于控制Redis服务器是否处于受保护的模式。受保护的模式可以防止未经授权的客户端连接到Redis服务器并执行命令。
- port:这个选项用于指定Redis服务器监听的端口号。例如,'port 6379’表示Redis服务器将在端口6379上监听连接。
- tcp-backlog:此选项用于指定TCP协议的连接队列长度。当服务器收到超过backlog指定的连接请求时,操作系统可能会拒绝新的连接。
- timeout:此选项用于设置客户端未响应时关闭连接时间
- tcp-keepalive:此选项用于设置TCP协议的keepalive参数。它指定了服务器在空闲连接上发送keepalive报文的频率。
- max-clients:此选项用于限制服务器同时接受的最大连接数。当达到此数量时,服务器将不再接受新的连接,直到有连接断开。
通用
'general’部分的配置选项主要用于指定Redis服务器的全局通用设置。
- daemonize:此选项用于指定Redis服务器是否以后台进程运行。如果设置为’yes’(默认为NO),服务器将在后台启动并关闭stdout和stderr,将日志输出到指定的日志文件。
- pidfile:这个选项用于指定Redis服务器保存进程ID的路径。服务器在启动时将向该文件写入PID。
- loglevel:此选项用于设置Redis的日志级别。它决定了哪些日志消息应该被记录,其有以下5种级别
- debug (a lot of information, useful for development/testing)
- verbose (many rarely useful info, but not a mess like the debug level)
- notice (moderately verbose, what you want in production probably)
- warning (only very important / critical messages are logged)
- nothing (nothing is logged)
- logfile:这个选项用于指定Redis服务器的日志文件路径。服务器将日志输出到该文件。
- syslog-enabled:此选项用于启用或禁用Redis的syslog日志记录。如果设置为’yes’,服务器将通过syslog记录日志。
- syslog-ident:此选项用于设置Redis发送syslog日志时的标识。
- databases:默认数据库的数量,默认是16个
- always-show-logo:默认不显示Logo
其中loglevel和logfile配置一起决定了Redis的日志策略。你可以根据需要设置不同的日志级别和输出路径。
快照(RDB配置)
有关SNAPSHOTTING的配置选项通常与Redis的持久化机制有关。Redis支持将数据持久化到磁盘上,以便在服务器崩溃或其他意外停机情况下,可以恢复数据并防止数据丢失。SNAPSHOTTING是Redis用于持久化的一个重要机制。
-
save:这个选项用于设置Redis的持久化触发条件。当满足指定的条件时,Redis将执行SNAPSHOTTING操作。例如,'save 900 1’表示如果在900秒内至少有1个修改操作,则执行SNAPSHOTTING。
save 900 1 #表示如果在900秒内至少有1个修改操作,则执行持久化操作 save 300 10 #如果300秒内至少有10个key进行了修改,则执行持久化操作
-
stop-writes-on-bgsave-error:如果持久化出错了,是否继续工作
-
snapshot-filename:这个选项用于指定SNAPSHOTTING后生成的快照文件的名称。可以自定义文件名,以便根据需要进行区分。
-
snapshot-dir:这个选项用于指定快照文件的存储目录。Redis将会在这个目录下创建快照文件。
-
snapshot-count:这个选项用于限制在同一个快照文件中保存的数据量。如果达到指定的数量,Redis将创建一个新的快照文件,以保证快照文件的可管理性和可用性。
-
rdbcompression:是否压缩rdb文件,需要消耗cpu资源。
-
rdbchecksum:保存rdb文件时,是否开启校验
-
dir ./:rdb文件的保存目录
主从复制
REPLICATION选项用于配置Redis的主从复制(Master-Slave Replication)设置。
- masterhost:指定主服务器的主机名或IP地址。
- masterport:指定主服务器的端口号。
- masterauth:如果主服务器设置了密码,可以在这里指定密码。
- repl-ping-slave-period:指定主服务器向从服务器发送ping命令的间隔时间。主服务器会定期向从服务器发送ping命令,以保持连接和同步。
- repl-timeout:指定主从复制的超时时间。如果在指定的时间内,主服务器没有收到从服务器的回复,将认为连接断开。
- repl-disable-tcp-nodelay:如果设置为yes,将禁用TCP_NODELAY选项。TCP_NODELAY选项可以禁用Nagle算法,从而提高网络性能。但是,如果网络条件较差,可能会导致数据传输延迟。
- repl-slave-read-only:如果从服务器只用于读取操作,可以将其配置为只读模式,以避免不必要的写操作。
- repl-master-reconnection-timeout:指定主服务器在断开连接后重新连接的超时时间。
安全
涉及安全的配置选项主要集中在"security"部分。这部分的配置用于保障Redis服务器的安全性和数据的完整性。
- requirepass:这个选项用于设置Redis服务器的访问密码。当客户端连接到Redis服务器时,必须提供正确的密码才能执行命令。
- pubkeyauth:这个选项与requirepass配合使用,它允许Redis服务器通过公钥身份验证来授权客户端连接。客户端需要持有正确的私钥才能通过身份验证。
- ssl-cert和ssl-ca-cert:这两个选项用于配置Redis服务器的SSL/TLS证书。它们可以用来实现加密的客户端和服务器之间的连接,以确保数据传输的安全性。
- maxclients:这个选项用于限制同时连接到Redis服务器的最大客户端数量。这个限制可以帮助防止服务器资源被恶意消耗。
- protect-keys:这个选项用于保护Redis服务器中的特定键不被客户端随意修改。如果这个选项被设置为"yes",那么只有在具有特定权限的客户端才能对特定的键执行写操作。
客户端限制
CLIENTS部分通常不包含具体的配置选项,而是用于限制和指定服务器接收的最大客户端连接数。
maxclients:用于指定最大客户端的连接数
内存管理
'MEMORY MANAGEMENT’部分主要涉及内存管理方面的配置选项,用于优化Redis的内存使用和性能。
- maxmemory:这个选项用于限制Redis服务器使用的最大内存量。它告诉Redis在达到这个限制之前,不要尝试使用操作系统提供的内存。当达到此限制时,Redis将根据其配置来决定如何管理内存。
- maxmemory-policy:这个选项用于指定当达到最大内存限制时,Redis应如何管理内存。有几种策略可供选择,包括:
- noeviction:这是默认策略,它不会淘汰任何键值对,直到内存不足以容纳新的写入操作。
- allkeys-lru:这个策略会根据最近最少使用(LRU)算法淘汰键。最近最少使用的键会被优先淘汰。
- volatile-lru:这个策略会根据最近最少使用(LRU)算法淘汰volatile键(即设置了expire的键)。最近最少使用的volatile键会被优先淘汰。
- allkeys-random:这个策略会随机选择键来淘汰,以尽可能均匀地分布淘汰操作。
- volatile-random:这个策略会随机选择volatile键来淘汰,以尽可能均匀地分布淘汰操作。
- volatile-ttl:删除即将要过期的key
- maxmemory-samples:这个选项用于指定在选择键来淘汰时,应考虑的样本数量。它与maxmemory-policy选项一起使用,以确定哪些键应被淘汰。当使用allkeys-lru、volatile-lru或allkeys-random策略时,Redis将选择一些键来检查它们的实际使用情况,以决定哪些键应被淘汰。该选项的默认值是16。
- hash-max-zipmap-entries和hash-max-zipmap-value:这两个选项用于控制Redis哈希表使用的内存大小。它们分别用于限制哈希表中的最大条目数和最大值大小。这些选项可以帮助控制Redis的内存占用,特别是在存储大量小值时非常有用。
- list-max-ziplist-entries和list-max-ziplist-value:这两个选项用于控制Redis列表使用的内存大小。它们分别用于限制列表中的最大条目数和最大值大小。当列表中的元素数量或值的大小超过这些限制时,Redis将使用更多的内存来存储数据。
- set-max-intset-entries:这个选项用于限制Redis集合使用的内存大小。它用于指定集合中最大元素数的限制。如果集合中的元素数量超过此限制,Redis将使用更多的内存来存储数据。
- zset-max-ziplist-entries和zset-max-ziplist-value:这两个选项用于控制Redis有序集合使用的内存大小。它们分别用于限制有序集合中的最大元素数和最大值大小。当有序集合中的元素数量或值的大小超过这些限制时,Redis将使用更多的内存来存储数据。
APPEND_ONLY_MODE(AOF配置)
当APPEND_ONLY_MODE设置为’yes’时,Redis将进入追加只写模式。在这种模式下,Redis的所有写操作(包括SET、LPUSH、RPUSH、HSET等)都将被记录到一个追加日志文件中(appendonly.aof)。这个日志文件被称为追加只写日志(Append-Only File),它是一个记录所有写操作的文件,用于在Redis服务器重启时恢复数据。
appendonly no #默认不开启aof模式,默认使用rdb模式进行持久化,大部分情况下rdb完全够用
appendfilename #'appendonly.aof' 持久化文件名
appeendfsync always #每一次修改都会进行同步
appendfsync everysec #每一秒都执行一次sync,可能会丢失1s的数据
appendfsync no #不执行sync,操作系统自己同步数据,速度最快
二、Redis持久化🍱
Redis 的一个显著特点是其内存存储,这意味着它的读写速度非常快。然而,内存存储的一个主要缺点是数据在服务器重启或崩溃时会丢失。为了解决这个问题,Redis 提供了持久化功能,可以将数据保存到硬盘上,以便在服务器重新启动时可以重新加载数据。
持久化之RDB(Redis DataBase)
RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照(Snapshot)。这是默认的持久化方式。当 Redis 需要持久化时,它会 fork 出一个子进程,子进程会将数据写入一个临时文件,当持久化过程完成后,再用这个临时文件替换旧的 RDB 文件。因为是在子进程中完成的,所以主进程不进行任何的IO操作,可以继续处理客户端的请求。
什么是RDB
rdb保存的文件是dump.rdb(生产环境下,会备份该文件)
测试
删除原有的rdb文件,然后设置5个值
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
重新生成了dump.rdb文件,在重新启动redis服务和客户端后,之前设置的值依然存在
触发机制
- 配置文件中save的规则满足的情况下,会自动触发rdb规则
- 执行flushall命令,也会触发rdb规则
- 退出(shutdown)redis,也会产生rdb文件
优缺点(来自官方文档)
优点:
- RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
- RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3(可能加密),非常适用于灾难恢复。
- RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能。
- 与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些.
缺点:
- 如果你希望在redis意外停止工作(例如电源中断)的情况下丢失的数据最少的话,那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据。
- RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.
持久化之AOF(Append Only File)
AOF 持久化以日志的形式记录服务器接收到的所有写操作命令,并在服务器启动时,通过重新执行这些命令来重建数据集。Redis 可以配置为每次接收到写命令就立即记录,或者每秒记录一次,或者在累积一定数量的写命令后记录。默认情况下,Redis 没有开启 AOF(append only file)方式的持久化,可以通过配置开启。
什么是AOF
如何开启
AOF默认是不开启的,需要将其修改为yes开启
开启后,会有一个appendonlydir目录(这个是Redis7版本,老版本的会直接有一个AOF文件),AOF文件就在里面
测试
写入数据前,打开aof文件中什么都没有,写入数据后,再打开aof文件,其中已经记录了刚才输入的key-value
如果aof文件有错误(比如上图内容,使用vim打开并修改其中的内容,再重启redis),redis是无法启动的,redis提供了redis-check-aof修复工具
redis-check-aof --fix
重写规则
如果aof文件大于64mb,redis会fork一个新的进程来将文件进行重写。
优缺点(来自官方文档)
优点:
- 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略:无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障,你最多丢失1秒的数据。
- AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满,写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。
- Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单: 举个例子, 如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写, 那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重启 Redis , 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
缺点:
- 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB 。 在一般情况下, 每秒 fsync 的性能依然非常高, 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快, 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)。
如何选择哪种持久化方式
一般来说, 如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。
如果你非常关心你的数据, 但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化, 但我们并不推荐这种方式: 因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快, 除此之外, 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。
只做缓存的时候,不需要任何持久化
三、Redis订阅发布🥙
Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息
Redis客户端可以订阅任意数量的频道。
订阅/消息发布图
下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:
当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端:
相关命令
序号 | 命令及描述 |
---|---|
1 | PSUBSCRIBE pattern [pattern …] 订阅一个或多个符合给定模式的频道。 |
2 | PUBSUB subcommand [argument [argument …]] 查看订阅与发布系统状态。 |
3 | PUBLISH channel message 将信息发送到指定的频道。 |
4 | PUNSUBSCRIBE [pattern [pattern …]] 退订所有给定模式的频道。 |
5 | SUBSCRIBE channel [channel …] 订阅给定的一个或多个频道的信息。 |
6 | UNSUBSCRIBE [channel [channel …]] 指退订给定的频道。 |
测试
接收端,使用SUBSCRIBE订阅
127.0.0.1:6379> SUBSCRIBE keye
1) "subscribe"
2) "keye"
发送端,使用PUBLISH发布消息
127.0.0.1:6379> PUBLISH keye 1234
(integer) 1
接收端,接收到消息
127.0.0.1:6379> SUBSCRIBE keye
1) "subscribe"
2) "keye"
3) (integer) 1
#等待推送的信息
1) "message" #消息
2) "keye" #频道
3) "1234" #消息内容
使用场景:
- 实时的消息系统
- 实时聊天(将频道当作聊天室,将消息回显给所有人)
- 订阅,关注系统
复杂的场景使用消息中间件MQ。
参考资料
狂神说JavaRedis最新超详细版教程通俗易懂_哔哩哔哩_bilibili
Redis 发布订阅 | 菜鸟教程 (runoob.com)