- redis常用配置参数
- 快照配置
- 主从复制相关配置
- 客户端配置
- config命令用于查看当前redis配置、以及不重启redis服务实现动态更改redis配置等
- 注意：不是所有配置都可以动态修改，且此方式无法持久保存
设置连接密码
获取当前配置
更改最大内存
- 可以通过config set命令动态修改参数，并使配置持久化到配置文件中
- 获取慢查询日志，将查询的时间改为1微秒
- 可以看到每个慢查询日志有4个属性组成，分别是慢查询日志的标记id、发生时间戳、命令耗时、执行命令和参数
- 慢查询日志重置
Redis虽然是一个内存级别的缓存程序，也就是redis是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的
目前redis支持两种不同方式的数据持久化保存机制，分别是RDB和AOF
RDB 模式
RDB 模式工作原理
RDB（Redis DataBase）：基于时间的快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可能会丢失从上次快照到当前时间点直接未做快照的数据
RDB bgsave实现快照的具体过程
- Redis从master主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件
- 当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保证每一次做RDB快照保存的数据都是完整的
- 因为直接替换RDB文件的时候，可能会出现突然断电等问题，而导致RDB文件还没保存完整就因为突然关机停止保存，而导致数据丢失的情况。后续可以手动将每次生成的RDB文件进行备份，这样可以最大化保存历史数据
RDB 相关配置
实现RDB方式
- save：同步，会阻塞其他命令，不推荐使用
- bgsave：异步后台执行，不影响其他命令的执行
- 自动：制定规则，自动执行
RDB 模式优点
- RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave或save命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本，很适合备份，并且文件格式也支持有不少第三方工具可以进行后续的数据分析
- 比如：可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。这样的话，即时遇上问题，也可以随时将数据集还原到不同的版本。
- RDB可以最大化Redis性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O工作。
- RDB在大量数据，比如几个G的数据，恢复的速度比AOF的快
RDB 模式缺点
- 不能实时保存数据，可能会丢失自上一次执行RDB备份到当时的内存数据
- 如果需要尽量避免在服务器故障时丢失数据，那么RDB不合适。虽然Redis运行设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此可能会至少5分钟才保存一次RDB文件。在这种情况下，一旦发生故障停机，就可能会丢失好几分钟的数据。
- 当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或者秒，取决于磁盘IO性能
- 在数据集比较庞大时，fork（）可能会非常耗时，造成服务器在一定时间内停止处理客户端：如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失。
- 执行bgsave命令，redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
- 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info status命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
- 父进程fork完成之后，bgsave命令返回“background saving started”信号 并不再阻塞父进程，可以继续响应其他命令。
- 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
- 进程发送信号给父进程表示完成，父进程更新统计信息
AOF 模式
AOF 模式工作原理
- AOF：AppendOnlyFile，按照操作顺序一次将操作追加到指定的日志文件末尾
- AOF和RDB一样使用了写时复制机制，AOF默认为每秒钟fsync一次，即将执行的命令保存到AOF文件中，这样即使redis服务器发送故障的话最多只丢失一秒钟之内的数据，也可以设置不同的sync策略always，即设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响
- 同时启动RDB和AOF，进行恢复时，默认AOF文件优先级高于RDB文件，即会使用AOF文件进行恢复
- 注意：AOF模式默认是关闭的，第一次开启AOF后，并重启服务生效后，会因为AOF的优先级高于RDB，而AOF第一次默认没有文件内容存在，从而导致所有数据丢失，因为启动时会去读数据文件，读AOF文件
AOF rewrite 重写
将一些重复的，可以合并的，过期的数据重新写入一个新的AOF文件，从而节约AOF备份占用的磁盘空间，也能加速恢复过程
可以手动执行bgrewriteaof触发AOF，或定义自动rewrite策略
AOF rewrite 过程
1.执行AOF重写请求
2.父进程执行fork创建子进程，开销等同于bgsave过程。
3.1主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4.子进程根据内存快照，快照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
5.2父进程把AOF重写缓冲区的数据写入到新的AOF文件
5.3使用新AOF文件替换老文件，完成AOF重写。
AOF 相关配置
AOF 模式优点
- 数据安全性相对较高，根据所使用的fsync策略，默认是appendfsync everysec，即每秒执行一次fsync，在这种配置下，redis仍然可以保存良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据
- 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek，即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在redis下一次启动之前，可以通过redis-check-aof工具来解决数据一致性的问题
- redis可以在aof文件体积变大过大时，自动地在后台对aof进行重写，重写后的新aof文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为redis在创建新aof文件的过程中，append模式不断的将修改数据追加到现有的aof文件里面，即使重写过程中发生停机，现有的aof文件也不会丢失。而一旦新aof文件创建完毕，redis就会从旧aof文件切换到新aof文件，并开始对新aof文件进行追加操作。
- aof包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数据的重建。
- aof文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此aof文件的内容非常容易被人读懂，对文件进行分析也很轻松。导出aof文件也非常简单：举个例子，如果你不小心执行了flushall命令，但只要aof文件未被重写，那么只要停止服务，移除aof文件末尾的flushall命令，并重启redis，就可以将数据集恢复到flushall之前的状态。
AOF 模式缺点
- 即使有些操作是重复的也会全部记录，AOF文件大小要大于RDB格式的文件
- AOF在恢复大数据集时的速度比RDB的恢复速度要慢
- 根据fsync策略不同，AOF速度可能会鳗鱼RDB
- bug出现的可能性更多
RDB和AOF的选择
如果主要充当缓存功能，或者可以承受数分钟数据的丢失，通常生产环境一般只需启用RDB即可，此也是默认值
如果数据需要持久保存，一点不能丢失，可以选择同时开启RDB和AOF，一般不建议只开启AOF
到此这篇redis的端口号是多少（redis 6380端口）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/42921.html