Redis基础篇07 — 配置文件详解(二)
本文最后更新于 338 天前,其中的信息可能已经有所发展或是发生改变。

概述

本篇文档紧接着 《Redis基础篇06 — 配置文件详解(一)》,如前所述,因涉及到的内容较多,因此相关的文档被拆分为 3 份。

TLS/SSL 部分

redis 从 6.0 版本开始支持 TLS/SSL 证书,这是一个可选的特性。关于配置参数,参阅以下:

  • port 0
  • tls-port 6379
  • tls-cert-file redis.crt //签名的 X.509 证书
  • tls-key-file redis.key // 用于验证的私钥
  • tls-key-file-pass secret // 如果证书包含密码短语,写在此处
  • tls-ca-cert-file ca.crt // ca 证书文件
  • tls-ca-cert-dir /usr/local/redis/ssl/ca-certs/ // 存放 CA 证书所在的目录位置
  • tls-auth-clients no //是否对客户端(包括异步复制的服务器)进行有效的证书校验,默认 yes
  • tls-replication no // 在异步复制(主从同步、主从复制)的情况下,从 redis 不会与 主 redis 进行 tls 连接
  • tls-cluster no //默认情况下,集群环境使用普通的 TCP 连接,若要为整个集群的连接启用 TLS ,请将该参数配置设置为 yes
  • tls-protocols "TLSv1.2 TLSv1.3" // 指定 TLS 协议支持的版本,推荐使用 TLSv1.2 和 TLSv1.3,启用 TLS 的旧版本会增加攻击的面
  • tls-session-caching no // 是否启用 tls 的连接会话缓存
  • tls-session-cache-size 5000 // 启用会话缓存后,缓存会话的连接数量
  • tls-session-cache-timeout 60 //缓存会话的超时时间,单位为秒

GENERAL 部分

  • daemonize yes // 是否以守护进程后台的方式启动 redis
  • pidfile /var/run/redis_6379.pid // 进程 pid 的存放路径。当您的 redis 实例启动后,该文件的内容就是进程的 pid,可通过 ps -lef 查看到
  • loglevel notice // 定义日志的级别。所谓日志级别,即记录的详细程度。
    • debug – 记录大量的信息,对 开发/测试 有用
    • verbose – 记录许多不太有用的信息,但不会像 debug 那样混乱
    • notice – 记录适度冗长的信息,适用于生产环境
    • warning – 仅记录 严重/非常严重 的信息
    • nothing – 不记录任何内容
  • logfile /usr/local/redis/logs/redis.log // 日志文件的位置
  • databases 16 // 设置数据库的数量,数据库的编号从 0 开始,即 DB 0、DB 1…
  • always-show-logo no // 是否总是显示 redis 的logo。默认情况下,只在前台启动时才能看到 redis 的logo
  • set-proc-title yes // 是否设置进程标题,以方便在 ps 或 top 命令中查看它
  • proc-title-template "{title} {listen-addr} {server-mode}" // 当设置了进程标题,你要显示哪些内容的模板,{ } 表示的是模板变量。通常而言,不需要更改

SNAPSHOTTING 部分

在 Redis 当中,将某一时刻内存中的数据保存到磁盘的过程,我们称为 「持久化」「快照持久化」。默认情况下,保存的文件名称为 dump.rdp。当 Redis 实例启动后,会自动读取 dump.rdp 中数据进行恢复,将其加载到内存当中。如果要完全禁用RDB 「持久化」功能,可在配置文件这样配置—— save ""

Shell > ls  -l  /usr/local/redis/conf/
总用量 112
-rw-r--r-- 1 root root     88 10月  4 15:24 dump.rdb
-rw-rw-r-- 1 root root 107592 10月  4 21:12 redis.conf

默认配置文件中有这样一行注释行——save 3600 1 300 100 60 10000,等价于三行:

  • save 3600 1 // 1小时轮询检查一次,如果至少有 1 次 key 变更,则将内存中数据保存到磁盘中
  • save 300 100 // 5分钟轮询检查一次,如果至少有 100 次 key 变更,则将内存中数据保存到磁盘中
  • save 60 10000 /// 1分钟轮询检查一次, 如果至少有 10000 次 key 变更,则将内存中数据保存到磁盘中
信息
三个条件只需要满足一个条件即发生「持久化」
  • stop-writes-on-bgsave-error yes //如果 redis 执行 bgsave「持久化」失败(常见如内存不足),是否不再接受 客户端 写入数据。
  • rdbcompression yes // 持久化是否开启对字符串的压缩(使用 LZF 压缩),开启后会占用一部分的 CPU 资源,不开启,则「持久化」的文件大小会较大
  • rdbchecksum yes // 是否开启对 rdb 文件的校验,开启后会使文件更耐损坏,但在保存以及加载时会造成性能损失(约10%)
  • dbfilename dump.rdb // db 的文件名称
  • rdb-del-sync-files no // 在未开启 redis 「持久化」的实例中,是否删除 副本 所使用的 .rdb 文件。默认情况下为 no,但在有些情况下(比如主从复制中),需要尽快删除 主 服务器上提供给 副本 服务器的 .rdb 文件。请注意!此参数仅在禁用 RDB 和 AOF 的 Redis 「持久化」实例中适用,否则该参数会被忽略。
  • dir /usr/local/redis/DB/ // 持久化所在的目录

REPLICATION 部分

在异步复制(主从同步、主从复制)时所使用的一些参数。这个先不涉及,等到说明 异步复制 时再说,先略过。

KEYS TRACKING 部分

只涉及到一个参数 —— tracking-table-max-keys 100000,表示设置跟踪 key 的数量上限。

从 Redis 6.0 开始,客户端如果开启了缓存,则 Redis 会维护一个跟踪表,用于存储用户的 key

关于客户端缓存,参阅官方——https://redis.io/topics/client-side-caching/

SECURITY 部分

有关安全方面的配置, ACL 的相关参数先不说明。

  • requirepass MyPassword // 设置密码
  • rename-command flushall ""
  • rename-command flushdb "" // 禁用一些权限较大的命令,可配置多行

CLIENTS 部分

涉及一个被注释的参数 —— maxclients 10000。表示 Redis 可并发处理的客户端连接数量。若达到了最大连接数,则会拒绝新来的连接并返回异常信息("max number of clients reached")

在 GNU/Linux 发行版中,常常有一句话——「一切皆文件」,那什么是文件描述符?
内核为了高效管理对已被打开的文件创建的索引,用于指向被打开的文件,所有 IO 操作的系统调用都通过文件描述符。文件描述符是一个非负整数,用于标明每一个被进程所打开的文件。在 Windows 系统中,这个东西叫句柄

文件描述符需要和 inode 做区分。Linux 内核会为每一个文件分配一个唯一的 ID 号—— inode ,方便内核找到该文件。但要知道是,GNU/Linux 是多任务多用户的,当多个用户同时打开同一个文件时,如何管理文件的偏移量就成为了一个问题(因为每个用户所执行的操作都不是一样的),所有引入了一个叫做 文件描述符(File descriptor) 的东西来为每一个用户服务。每个用户每次打开一个文件,就产生一个文件描述符,多次打开就产生多个文件描述符,一 一对应。所以文件的 inode 和文件描述符是这样一种关系———一个 inode 可拥有多个文件描述符,多个文件描述符可对应一个 inode。

文件描述符有用户级别和系统级别:

  • 系统级别 – cat /proc/sys/fs/file-max,这里限制的是所有用户打开文件描述符的总和。其值由系统自动计算,通常为内存(以KB单位)的 10% 左右
  • 用户级别 – 通过修改 /etc/security/limits.conf 来限制。默认情况下,所有用户的文件描述符为 1024
# 查看当前登录用户可使用文件描述符的上限。
Shell > ulimit -n
1024

由于用户级别的文件描述符为 1024 ,所有在 redis.conf 中配置 maxclients 10000 是不起作用的。

信息
当你为 maxclients 配置了起作用的值,其实际可处理的客户端连接数需要在其基础上减32(因为有一些文件描述符需要提供给 redis 内部使用);当使用的是 redis cluster 时,每个节点占 2 个连接(一进一出)。

MEMORY MANAGEMENT 部分

主要有这么 4 个参数:

  • maxmemory <byte> // 最大使用的内存。当 Redis 达到这里的内存上限时,会根据策略参数 maxmemory-policy 的值来尝试删除符合条件的 key,如果不能删除 key 或者策略设置为 noeviction,Redis 将对那些使用写操作命令(如SET、LPUSH)回复error,对于只读操作命令(如 GET)没有影响
  • maxmemory-policy noeviction // 当到达了参数 maxmemory 值的上限,使用什么逐出策略(删除策略)。有八种策略选择:
    • volatile-lru -> 使用近似 LRU 的算法进行移除(仅对设置了过期时间的 key 起作用)
    • allkeys-lru -> 对任何 key 都使用近似 LRU 的算法进行移除
    • volatile-lfu -> 使用近似 LFU 的算法进行移除(仅对设置了过期时间的 key 起作用)
    • allkeys-lfu -> 对任何 key 都使用近似 LFU 的算法进行移除
    • volatile-random -> 对设置了过期时间的随机 key 进行移除
    • allkeys-random ->对任意 key 进行随机的移除
    • volatile-ttl -> 移除最接近过期时间的 key
    • noeviction -> 不执行任何操作,只在写操作时返回错误
  • maxmemory-samples 5 // 选择 key 的样本数量,其使用的是 LRU 算法选择样本。设置为 10 ,会非常接近真实的 LRU 算法,但会占用更多的 CPU 资源。
  • maxmemory-eviction-tenacity 10 // 数据逐出的因子,值范围为 [0,100],用于设置每次移除数据的延迟。降低该值可能会降低延迟,但影响数据逐出的有效性;当写入数据的流量特别大时,您需要增加该值,但会造成移除数据的延迟增大。通常而言,您不需要修改该参数的值。
术语说明
LRU – Least Recently Used,最近最少使用。LFU – Least Frequently Used,最少使用。

在 Redis 当中使用的 LRU、LFU、minimal TTL 算法都采用了近似算法,这样做的目的是节省内存

在 MySQL 您也见到 LRU 算法,那什么是 LRU 算法?
这种算法认为最近使用的数据是热门数据,下一次很大概率将会再次被使用。而最近很少被使用的数据,很大概率下一次不再用到。当缓存容量满时候,优先淘汰最近很少使用的数据。该算法采用一种特殊的数据结构,被称为哈希链表。好理解的示意图:

LRU算法

用一杯咖啡支持我们,我们的每一篇[文档]都经过实际操作和精心打磨,而不是简单地从网上复制粘贴。期间投入了大量心血,只为能够真正帮助到您。
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇