redis.conf

bind 0.0.0.0       # 指定监听地址，支持用空格隔开的多个监听IP

protected-mode yes # redis3.2之后加入的新特性，在没有设置bind IP和密码的时候,redis只允许访问127.0.0.1:6379，可以远程连接，但当访问将提示警告信息并拒绝远程访问,redis-7版本后，只要没有密码就不能远程访问

port 6379          # 监听端口，默认6379/tcp

tcp-back1og 511    # 三次握手的时候server端收到client ack确认号之后的队列值，即全连接队列长度

timeout 0          # 客户端和Redis服务端的连接超时时间，默认是0，表示永不超时

tcp-keepalive 300  # tcp 会话保持时间300s

daemonize no       # 默认no,即直接运行redis-server程序时,不作为守护进程运行，而是以前台方式运行如果想在后台运行需改成yes,当redis作为守护进程运行的时候，它会写一个 pid 到/var/run/redis.pid 文件

supervised no      # 和0S相关参数，可设置通过upstart和systemd管理Redis守护进程，centos7后都使用systemd

pidfile /var/run/redis_6379.pid   # pid文件路径,可以修改为/apps/redis/run/redis_6379.pid

1ogleve1 notice  # 日志级别

1ogfile "/path/redis.log" # 日志路径,示例:1ogfile "/apps/redis/1og/redis_6379.log

databases 16  # 设置数据库数量，默认:0-15，共16个库

always-show-1ogo yes  # 在启动redis 时是否显示或在日志中记录记录redis的1ogo

save 900 1  # 在900秒内有1个key内容发生更改,就执行快照机制

save 300 10 # 在300秒内有10个key内容发生更改,就执行快照机制

save 60 10000 # 60秒内如果有10000个key以上的变化，就自动快照备份

stop-writes-on-bgsave-error yes  # 默认为yes时,可能会因空间满等原因快照无法保存出错时，会禁止redis写入操作，生产建议为no. 此项只针对配置文件中的自动save有效

rdbcompression yes # 持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之

rdbchecksum yes # 是否对备份文件开启RC64校验，默认是开启dbfilename dump.rdb #快照文件名

dir ./ # 快照文件保存路径，示例:dir"/apps/redis/data'

#主从复制相关
# replicaof <masterip><masterport> #指定复制的master主机地址和端口，5.0版之前的指令为slaveof
# masterauth <master-password> #指定复制的master主机的密码

replica-serve-stale-data yes # 当从库同主库失去连接或者复制正在进行，从机库有两种运行方式:
  1、设置为yes(默认设置)，从库会继续响应客户端的读请求，此为建议值
  2、设置为no，除去特定命令外的任何请求都会返回一个错误"SYNC with master in progress"

replica-read-only yes # 是否设置从库只读，建议值为yes,否则主库同步从库时可能会覆盖数据，造成数据丢失

rep1-diskless-sync no # 是否使用socket方式复制数据(无盘同步)，新slave第一次连接master时需要做数据的全量同步，redis server就要从内存dump出新的RDB文件，然后从master传到slave，有两种方式把RDB文件传输给客户端:
  1、基于硬盘(disk-backed):为no时，master创建一个新进程dump生成RDB磁盘文件，RDB完成之后由父进程(即主进程)将RDB文件发送给slaves，此为默认值
  2、基于socket(diskless):master创建一个新进程直接dump RDB至slave的网络socket，不经过主进程和硬盘
# 推荐使用基于硬盘(为no)，是因为RDB文件创建后，可以同时传输给更多的s1ave，但是基于socket(为yes)， 新slave连接到master之后得逐个同步数据。只有当磁盘I/0较慢且网络较快时，可用diskless(yes),否则一般建议使用磁盘(no)

rep1-disk1ess-sync-delay 5 # diskless时复制的服务器等待的延迟时间，设置0为关闭，在延迟时间内到达的客户端，会一起通过disk1ess方式同步数据，但是一旦复制开始，master节点不会再接收新slave的复制请求，直到下一次同步开始才再接收新请求。即无法为延迟时间后到达的新副本提供服务，新副本将排队等待下一次RDB传输，因此服务器会等待一段时间才能让更多副本到达。推荐值:30-60

rep1-ping-replica-period 10 # slave根据master指定的时间进行周期性的PING master,用于监测master状态,默认10s

rep1-timeout 60 # 复制连接的超时时间，需要大于rep1-ping-slave-period，否则会经常报超时

rep1-disable-tcp-nodelay no # 是否在s1ave套接字发送SYNC之后禁用 TCP_NODELAY，如果选择"yes"，Redis将合并多个报文为一个大的报文，从而使用更少数量的包向s1aves发送数据，但是将使数据传输到s1ave上有延迟，Linux内核的默认配置会达到40毫秒，如果"no”，数据传输到slave的延迟将会减少，但要使用更多的带宽

rep1-back1og-size 512mb # 复制缓冲区内存大小，当s1ave断开连接一段时间后，该缓冲区会累积复制副本数据，因此当slave 重新连接时，通常不需要完全重新同步，只需传递在副本中的断开连接后没有同步的部分数据即可。只有在至少有一个s1ave连接之后才分配此内存空间,建议建立主从时此值要调大一些或在低峰期配置，否则会导致同步到slave失败

rep1-back1og-tt1 3600 # 多长时间内master没有slave连接，就清空back1og缓冲区

replica-priority 100 #当master不可用，哨兵sentine]会根据slave的优先级选举一个master，此值最低的s1ave会优先当选master，而配置成0，永远不会被选举，一般多个s1ave都设为一样的值，让其自动选择
#min-replicas-to-write 3 #至少有3个可连接的slave，mater才接受写操作
#min-replicas-max-lag 10 #和上面至少3个slave的ping延迟不能超过10秒，否则master也将停止写操作

requirepass foobared # 设置redis连接密码，之后需要AUTH pass,如果有特殊符号，用”"引起来,生产建议设置

rename-command # 重命名一些高危命令，示例:rename-command FLUSHALL"”禁用命令#示例:rename-command delwang

maxclients 10000 # Redis最大连接客户端

maxmemory <bytes>   # redis使用的最大内存，单位为bytes字节，0为不限制，建议设为物理内存一半，8G内存的计算方式8(G)*1024(MB)1024(KB)*1024(Kbyte)，需要注意的是缓冲区是不计算在maxmemory内,生产中如果不设置此项,可能会导致0OM

maxmemory-policy
# MAXMEMORY POLICY:当达到最大内存时，Redis 将如何选择要删除的内容。您可以从以下行为中选择种:
# volatile-lru -> Evict 使用近似 LRU，只有设置了过期时间的键。
# a11keys-lru -> 使用近似 LRU 驱逐任何键。
# volatile-1fu -> 使用近似 LFU 驱逐，只有设置了过期时间的键。
# a11keys-1fu -> 使用近似 LFU 驱逐任何键。
# volatile-random -> 删除设置了过期时间的随机密钥。
# a11keys-random -> 删除一个随机密钥，任何密钥。
#volatile-tt1 -> 删除过期时间最近的key(次TTL)
# noeviction ->不要驱逐任何东西，只是在写操作时返回一个错误。此为默认值
#
#LRU 表示最近最少使用
#LFU 表示最不常用
#
# LRU、LFU 和 volatile-ttl 都是使用近似随机算法实现的。
#
#注意:使用上述任何一种策略，当没有合适的键用于驱逐时，Redis 将在需要更多内存的写操作时返回错误。这些通常是创建新密钥、添加数据或修改现有密钥的命令。一些示例是:SET、INCR、HSET、LPUSH、SUNIONSTORE、SORT(由于 STORE 参数)和 EXEC(如果事务包括任何需要内存的命令)。

appendonly no   # 是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能

appendfilename "appendonly.aof"  # 文本文件AOF的文件名，存放在dir指令指定的目录中

appendfsync everysec  # aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#a1ways表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
#同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制

no-appendfsync-on-rewrite no # 在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘I0开支和请求阻塞时间。
#默认为no,表示"不暂缓”,新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞(因为没有竞争磁盘)，但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢?Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间

auto-aof-rewrite-percentage 100 #当Aof 1og增长超过指定百分比例时，重写A0F文件，设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据

auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小

aof-load-truncated yes #是否加载由于某些原因导致的末尾异常的A0F文件(主进程被ki11/断电等)建议yes

aof-use-rdb-preamble no #redis4.0新增RDB-A0F混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内容则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点(既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据),默认为no,即不启用此功能

lua-time-limit 5000 #1ua脚本的最大执行时间，单位为毫秒

cluster-enabled yes #是否开启集群模式，默认不开启,即单机模式

cluster-config-file nodes-6379.conf #由node节点自动生成的集群配置文件名称

cluster-node-timeout 15000 #集群中node节点连接超时时间，单位ms,超过此时间，会踢出集群

c1uster-replica-validity-factor 10 #单位为次,在执行故障转移的时候可能有些节点和master断开一段时间导致数据比较旧，这些节点就不适用于选举为master，超过这个时间的就不会被进行故障转移,不能当选master，计算公式:(node-timeout *replica-validity-factor)+ repl-ping-replica-period

cluster-migration-barrier 1#集群迁移屏障，一个主节点至少拥有1个正常工作的从节点，即如果主节点的slave节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。

c1uster-require-fu11-coverage yes #集群请求槽位全部覆盖，如果一个主库宕机且没有备库就会出现集群槽位不全，那么yes时redis集群槽位验证不全,就不再对外提供服务(对key赋值时,会出现CLUSTERDOWN The cluster is down的提示,cluster_state:fai1,但ping 仍PONG)，而no则可以继续使用,但是会出现查询数据査不到的情况(因为有数据丢失)。生产建议为no

c1uster-replica-no-failover no #如果为yes,此选项阻止在主服务器发生故障时尝试对其主服务器进行故障转移。 但是，主服务器仍然可以执行手动强制故障转移，一般为no
#s1ow 10g 是 Redis 用来记录超过指定执行时间的日志系统，执行时间不包括与客户端交谈，发送回复等I/0操作，而是实际执行命令所需的时间(在该阶段线程被阻塞并且不能同时为其它请求提供服务),由于s1ow 10g 保存在内存里面，读写速度非常快，因此可放心地使用，不必担心因为开启 slow 1og 而影响Redis 的速度

s1ow1og-1og-s1ower-than 10000 #以微秒为单位的慢日志记录，为负数会禁用慢日志，为0会记录每个命令操作。默认值为10ms,一般一条命令执行都在微秒级,生产建议设为1ms-10ms之间

slow1og-max-1en 128 #最多记录多少条慢日志的保存队列长度，达到此长度后，记录新命令会将最旧的命令从命令队列中删除，以此滚动删除,即,先进先出,队列固定长度,默认128,值偏小,生产建议设为1000以上

缓存穿透

缓存穿透是指请求绕过缓存直接到达数据库的情况，通常是由于请求的参数不合法或请求的资源在缓存和数据库中都不存在。

1. 参数校验
确保请求参数的合法性。在应用层面进行严格的参数校验，过滤掉无效请求。

2. 使用布隆过滤器
布隆过滤器是一种空间效率高的概率性数据结构，可以用来判断一个元素是否在集合中。如果布隆过滤器判断某个元素不在集合中，直接返回，不查询数据库。

3. 缓存空值
对于查询结果为空的请求，可以在缓存中存储一个空值（如null）。设置过期时间，避免频繁查询数据库。

4. 限流和熔断
对热点请求进行限流，避免暴风式请求导致数据库负载过高，同时在请求出现异常时进行熔断保护。

缓存击穿

缓存击穿是指某个热点数据在缓存中失效后，很多请求同时涌向数据库，这会导致数据库瞬间承受大量压力，可能导致服务崩溃。

1. 加锁机制
使用分布式锁来控制并发请求。只有获取到锁的请求才能查询数据库并更新缓存，其它请求则等待。

2. 设置合理的缓存过期时间
给热点数据设置适中的过期时间，避免频繁失效，平衡性能和一直获得最新数据的需求。

3. 预热缓存
在系统启动或进行大规模数据更新时，提前加载热点数据到缓存，减小数据库的压力。

4. 使用慢查询日志
监控慢查询，发现热点数据，提前为它们设置缓存策略。

缓存雪崩

缓存雪崩是指因大量缓存同时过期，导致大量请求直接涌向数据库，造成数据库瞬间负载过高或崩溃的现象。

1. 随机过期时间
为不同的缓存设置随机的过期时间，避免同一时间大量缓存失效。

2. 预先加载热点数据
在系统启动时或定时任务中预先加载热点数据到缓存，降低缓存失效对数据库的影响。

3. 设置合理的缓存失效策略
对缓存进行合理的失效管理，减少同时失效的情况。对于热点数据，可以设置较长的过期时间。

4. 使用二级缓存
在应用层引入一个二级缓存，比如使用内存（如 Guava Cache 等），存储近期访问的数据，减少对 Redis 的依赖。

5. 限流保护
在高并发情况下，对请求进行限流和熔断，从而保护数据库。

redis 适用场景

1. 缓存
Redis 常用于缓存热门数据，减轻数据库压力，提高访问速度。特别适合需要快速读取的数据。

2. 会话存储
可以使用 Redis 存储用户会话信息（如登录状态），支持快速读取和更新。

3. 实时数据处理
Redis 支持 Pub/Sub 消息队列机制，适合实时消息处理和推送。

4. 排行榜和计数器
Redis 的有序集合（Sorted Set）非常适合实现排行榜功能，以及统计访问次数、点赞数等实时指标。

5. 分布式锁
可以利用 Redis 实现分布式锁，确保在分布式系统中的数据一致性。

6. 异步任务队列
利用 Redis 的列表（List）结构，可以实现任务队列功能，支持生产者-消费者模型。

7. 按需数据分析
Redis 可用于实时日志分析、流量监控等，通过较大的数据处理能力支持低延迟分析。

8. 地理位置服务
可以使用 Redis 的 GEO 命令处理地理位置信息，支持位置查询和用户定位服务。

redis 监控

1. Redis 自带监控命令
INFO：使用 INFO 命令可以获取 Redis 的运行状态，包括内存使用情况、线程信息、连接数等。
  redis-cli INFO

MONITOR：可以实时监控正在执行的命令，但会对性能有一定影响。
  redis-cli MONITOR

2. 使用监控工具
Redis Sentinel：提供高可用性管理，还可以监控 Redis 服务器的状态并在故障发生时发出警报。

Prometheus + Grafana：使用 Exporter（如 redis_exporter）收集 Redis 指标，使用 Grafana 进行可视化。


3. 设置警报
根据关键指标设置阈值并配置警报：

内存使用率：监控内存使用，防止达到最大限制。
连接数：监控当前连接数，防止连接过多导致服务不可用。
命令延迟：监控响应时间， Any unusually high response time can indicate performance issues.

4. 日志监控
定期查看 Redis 日志，关注错误和警告信息，有助于快速识别和解决问题。

5. 健康检查
定期进行健康检查，可以通过简单的 Ping/Pong 检查 Redis 服务是否正常。

redis 持久化

RDB (Redis Database Backup)

RDB 原理

RDB 通过定期将内存中的数据写入到磁盘上，生成一个二进制的快照文件（.rdb）。
适用于数据的周期性备份，启动时可以快速恢复数据。

RDB 备份过程

1. 触发条件：通过配置中的 save 指令设置在特定时间和修改次数下自动生成快照。
2. 生成快照：
        当触发条件满足时，Redis 会创建一个子进程。
        fork 出子进程，将内存中数据写入到 .rdb 文件。
        子进程完成后退出，主进程继续运行。

RDB 备份配置

# 指定触发快照的条件
save 900 1    # 900秒内至少1次修改
save 300 10   # 300秒内至少10次修改
dbfilename dump.rdb  # RDB文件名
dir /var/lib/redis   # 文件存储目录

RDB 备份命令

redis-cli -a 123456  save&

RDB 优缺点

优点：
  启动速度快，适合快速恢复。
  节省存储空间。

缺点：
  如果 Redis 崩溃，可能会丢失最近的修改数据。
  只能恢复到快照生成时的数据，不能逐条恢复。

AOF（Append-Only File）

AOF 原理

AOF 记录每个写操作，将其追加到日志文件中，实现持续的持久化。

AOF 备份过程

1. 写入日志：每次执行写操作时，操作命令追加到 AOF 文件中。

2. 同步策略：
    每次写入后（最高安全性，性能较低）。
    每秒（平衡性能和安全性）。
    不同步（最高性能，风险较高）。

3. 重写过程：定期对 AOF 文件进行重写，以降低文件体积。

AOF 配置

appendonly yes         # 启用 AOF
appendfilename "appendonly.aof"  # AOF 文件名
appendfsync everysec    # 每秒同步

AOF 备份命令

使用 BGREWRITEAOF 命令手动触发 AOF 文件的重写： BGREWRITEAOF

BGREWRITEAOF
  时间复杂度： O(N)。其中 N 是要追加到 AOF 文件中的数据数量。重写操作会创建一个当前 AOF 文件的体积优化版本。
  即使 BGREWRITEAOF 执行失败，旧的 AOF 文件在重写成功之前不会被修改，因此不会有任何数据丢失。
  重写操作只在没有其他持久化任务（如快照）在后台执行时进行。如果正在进行快照保存，BGREWRITEAOF 会被预定（scheduled），直到保存操作完成后再执行。此时，BGREWRITEAOF 返回值仍为 OK，并附加信息说明待执行。
  在 Redis 2.6 及以上版本，可以使用 INFO 命令查看 BGREWRITEAOF 是否被预定。
  如果已有其他 AOF 重写正在执行，新的 BGREWRITEAOF 请求将失败并不会被预定到下次执行。
  从 Redis 2.4 开始，AOF 重写可以由 Redis 自行触发，而 BGREWRITEAOF 主要用于手动触发重写操作。

AOF 优缺点

优点：
  数据恢复更完整，支持逐条恢复。
  灵活的同步策略。

缺点：
  文件体积较大，写入频率高时性能受影响。
  启动时恢复速度慢于 RDB。

AOF 数据一致性

1. 数据一致性原理
    AOF 文件按顺序记录每个写操作的命令，确保在系统重启时能完全重建数据集。
    Redis 支持多种同步策略，以平衡数据持久性和性能。

2. 同步策略
    AOF 的同步策略影响数据的一致性和性能：
        appendfsync always：每次写操作后立即同步到磁盘，最高的数据一致性，最低的性能。
        appendfsync everysec：每秒将数据同步一次，提供较好的性能与相对较高的一致性。
        appendfsync no：完全依赖操作系统管理，性能最佳，但数据丢失风险最大（尤其是在崩溃时）。

3. 恢复场景
    在 Redis 意外崩溃后，重启时会读取 AOF 文件并依次执行命令恢复数据。
    AOF 中的最后状态是最近的写操作结果，用户可以在配置中设置 no-appendfsync-on-rewrite，在重写期间减少写入时的阻塞。

4. 数据一致性挑战
    网络分区：在分布式环境中，网络分区可能导致 AOF 数据和其他数据库节点之间的状态不一致。
    事务处理：考虑使用 Redis 事务（MULTI/EXEC）来确保一组操作的原子性。

5. 检查与维护
    使用 redis-check-aof 工具来检查和修复 AOF 文件的完整性和一致性。
    定期执行 AOF 重写以优化文件大小，确保正常操作。

AOF Rewrite

Rewrite 是 Redis 中用于优化 AOF 文件的一种机制。将一些重复的,可以合并的,过期的数据重新写入一个新的AOF文件,从而节约AOF备份占用的硬盘空间,也
能加速恢复过程,并提高性能。

AOF Rewrite 过程

触发条件：
    AOF 文件的大小超过一定阈值时（依据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 设置）。
    手动调用 BGREWRITEAOF 命令以进行重写。

重写过程：
    Redis 会 fork 一个子进程，用于生成新的 AOF 文件，确保主进程继续服务客户端请求。
    子进程读取当前内存中的数据，并生成新的 AOF 文件。
    在子进程成功完成后，新的 AOF 文件会替换掉旧的文件。

AOF Rewrite 配置

# 设置最小 AOF 文件大小以触发自动重写
auto-aof-rewrite-min-size 64mb
# 设置文件大小增加的百分比，以触发重写
auto-aof-rewrite-percentage 100

aof-1oad-truncated yes #是否加载由于某些原因导致的末尾异常的A0F文件(主进程被ki11/断电等),建议yes

no-appendfsync-on-rewrite no #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘I0开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞(因为没有竞争磁盘)，但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢?Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐

AOF Rewrite 优缺点

优点：
    文件大小减少：去除多余的老命令，减小 AOF 文件的大小。
    性能提升：新 AOF 文件只包含当前有效的数据，快速恢复。

缺点：
    内存开销：重写过程中需要 fork 子进程，可能短时间内消耗更多内存。
    延迟风险：在高负载情况下，重写可能影响性能。

redis 常用命令

1. 字符串操作
SET key value：设置一个字符串值。
GET key：获取存储的字符串值。
DEL key：删除指定的键。
EXISTS key：检查键是否存在。
INCR key：将键的整数值加一。

2. 哈希操作
HSET key field value：在哈希表中设置一个字段的值。
HGET key field：获取哈希表中指定字段的值。
HGETALL key：获取哈希表中所有字段及其值。
HDEL key field：删除哈希表中的指定字段。

3. 列表操作
LPUSH key value：在列表头部插入一个值。
RPUSH key value：在列表尾部插入一个值。
LRANGE key start stop：获取列表中指定范围的元素。
LPOP key：移除并返回列表的第一个元素。

4. 集合操作
SADD key value：向集合添加一个或多个成员。
SREM key value：移除集合中的一个或多个成员。
SMEMBERS key：获取集合中的所有成员。
SISMEMBER key value：判断元素是否是集合的成员。

5. 有序集合操作
ZADD key score member：向有序集合添加一个成员，带分值。
ZRANGE key start stop：获取指定范围的成员。
ZREM key member：移除有序集合中的成员。
ZScore key member：获取成员的分值。

6. 事务和管道
MULTI：标记事务的开始。
EXEC：执行事务中的所有命令。
DISCARD：放弃事务。
WATCH key：监视一个键的变化。

7. 服务器管理
INFO：获取服务器信息和统计数据。
FLUSHALL：删除所有数据库中的所有键。
FLUSHDB：删除当前数据库中的所有键。
SAVE：手动保存数据集到磁盘。

8. 持久化
BGSAVE：在后台异步保存数据集到磁盘。
BGREWRITEAOF：在后台重新写入 AOF 文件。

9. 查找和模式匹配
KEYS pattern：查找所有符合给定模式的键。
SCAN cursor：增量迭代从某个游标开始的所有键（推荐用于替代 KEYS）。
DBSIZE: 查询当前数据库中键的数量

10. 数据库切换
SELECT index: 切换到指定的数据库。

redis pipline

Pipeline 是 Redis 提供的一种机制，用于批量发送多个命令到 Redis 服务器，而不需要等待每个命令的回复，这样可以显著减少网络延迟，提高性能。

pipline 优势

减少网络往返：可以一次性发送多个命令，减少客户端与服务器之间的交互次数。
提高吞吐量：在高并发场景下，能有效提高请求处理速度。

pipline 执行过程

1.建立连接：
使用 Redis 客户端库连接到 Redis 服务器。

2.开始 Pipeline：
开启 Pipeline 模式，开始批量发送命令。

3.发送命令：
向 Redis 发送多个命令。

4.获取结果：
一次性读取所有命令的返回结果。

参考文档

https://redis.io/docs/latest/operate/oss_and_stack/management/