Redis配置文件详解以及持久化和订阅发布 |
您所在的位置：网站首页 › redis持久化应用 › Redis配置文件详解以及持久化和订阅发布 |
Redis配置文件详解以及持久化和订阅发布
|
系列文章目录
（一）Redis(windows+Linux)安装及入门教程 - 掘金 (juejin.cn) （二）Redis中的五大数据类型 - 掘金 (juejin.cn) （三）Redis中的三种特殊类型 - 掘金 (juejin.cn) （四）Redis实现乐观锁 - 掘金 (juejin.cn) （五）SpringBoot整合Redis详细教程 - 掘金 (juejin.cn) （六）Redis配置文件详解以及持久化和订阅发布 - 掘金 (juejin.cn) （七）Redis集群详解 - 掘金 (juejin.cn) 前言本文详细讲述了Redis的配置文件，持久化，订阅发布的内容，该文是Redis进阶知识的第一篇，过后会讲解集群环境搭建，主从复制，哨兵模式详解等，如果本文对你有帮助，麻烦 点赞+收藏+关注( •̀ ω •́ )✧ 一、Redis配置文件详解🥗 单位unit单位对大小写不敏感 包含'includes'部分用于引入其他配置文件。这种方式可以让Redis的配置更加模块化和易于管理。例如，你可以将一些常见的配置选项放在一个单独的配置文件中，然后在主配置文件中通过'include'指令来引入这些配置。被包含的配置文件通常包含一些通用的设置，如服务器运行的端口，启动和关闭服务器的选项，以及一些全局的ACL和环境设置等。 可以类比import和include 模块这是Redis从5.0版本开始引入的一种扩展机制。Redis Modules允许开发者在Redis核心中添加新的命令和数据类型，从而极大地扩展了Redis的功能。模块可以提供新的键空间，新的命令，或者新的数据类型，甚至是修改现有的数据类型。
'network'相关的配置通常涉及服务器网络连接的参数。 'general'部分的配置选项主要用于指定Redis服务器的全局通用设置。 其中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）设置。 涉及安全的配置选项主要集中在"security"部分。这部分的配置用于保障Redis服务器的安全性和数据的完整性。 CLIENTS部分通常不包含具体的配置选项，而是用于限制和指定服务器接收的最大客户端连接数。 maxclients：用于指定最大客户端的连接数 内存管理'MEMORY MANAGEMENT'部分主要涉及内存管理方面的配置选项，用于优化Redis的内存使用和性能。 当APPEND_ONLY_MODE设置为'yes'时，Redis将进入追加只写模式。在这种模式下，Redis的所有写操作（包括SET、LPUSH、RPUSH、HSET等）都将被记录到一个追加日志文件中（appendonly.aof）。这个日志文件被称为追加只写日志（Append-Only File），它是一个记录所有写操作的文件，用于在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 时， 这个消息就会被发送给订阅它的三个客户端： 相关命令 序号命令及描述1PSUBSCRIBE pattern [pattern ...] 订阅一个或多个符合给定模式的频道。2PUBSUB subcommand [argument [argument ...]] 查看订阅与发布系统状态。3PUBLISH channel message 将信息发送到指定的频道。4PUNSUBSCRIBE [pattern [pattern ...]] 退订所有给定模式的频道。5SUBSCRIBE channel [channel ...] 订阅给定的一个或多个频道的信息。6UNSUBSCRIBE [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) |
【本文地址】
今日新闻 |
推荐新闻 |