概述
本篇文档紧接着 《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 是不起作用的。
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 -> 不执行任何操作，只在写操作时返回错误
在 Redis 当中使用的 LRU、LFU、minimal TTL 算法都采用了近似算法，这样做的目的是节省内存。
在 MySQL 您也见到 LRU 算法，那什么是 LRU 算法？
这种算法认为最近使用的数据是热门数据，下一次很大概率将会再次被使用。而最近很少被使用的数据，很大概率下一次不再用到。当缓存容量满时候，优先淘汰最近很少使用的数据。该算法采用一种特殊的数据结构，被称为哈希链表。好理解的示意图：
