Redis 集群

三高架构:并发,性能,可用

 

主从复制

主从复制:将 master 中的数据即时、有效的复制到 slave 中

特征:一个 master 可以拥有多个 slave,一个 slave 只对应一个 master

master 职责:写数据,执行写操作时,将出现变化的数据自动同步到 slave

slave 职责:读数据

主从复制的作用

  • 读写分离:master 写、slave 读,提高服务器的读写
  • 负载能力负载均衡:基于主从结构,配合读写分离,由 slave 分担 master 负载,并根据需求的变化,改变 slave 的数量,通过多个从节点分担数据读取负载,大大提高 Redis服务器并发量 与数据吞吐量
  • 故障恢复:当 master 出现问题时,由 slave 提供服务,实现快速的故障恢复
  • 数据冗余:实现数据热备份,是持久化之外的一种数据冗余方式
  • 高可用基石:基于主从复制,构建哨兵模式与集群,实现 Redis 的高可用方案

 

主从复制工作流程

一、建立连接阶段(即准备阶段)

# 关闭守护进程选项
# slave 连接 master

# 方式一:客户端发送命令
slaveof <masterip> <masterport>
# 方式二:启动服务器参数
redis-server --slaveof <masterip> <masterport>
# 方式三:服务器配置
slaveof <masterip> <masterport>

# slave 系统信息
info
master_link_down_since_seconds
masterhost
masterport

# master 系统信息
info
slave_listening_port(多个)

# 端口连接,客户端发送命令
slaveof no one

建立 slave 到 naster 的连接,使 master 能够识别 slave,并保存 slave 的端口号

  1. 设置 master 的地址和端口,保存 master 信息
  2. 建立 socket 连接
  3. 发送 ping 命令(定时器任务)
  4. 身份验证
  5. 发送 slave 端口信息到此,主从连接成功!

最后状态:slave 保存了 master 的地址与端口。master 保存了 slave 的端口。主从之间创建了连接的 socket。

授权访问设置

# master 配置文件设置密码
requirepass <password>
# master 客户端发送命令设置密码
config set requirepass <password>
config get requirepass

# slave 客户端发送命令设置密码
auth <password>
# slave 配置文件设置密码
masterauth <password>
# 启动客户端设置密码
redis-cli -a <password>

二、数据同步阶段

在 slave 初次连接 master 后,复制 master 中的所有数据到 slave,将 slave 的数据库状态更新成 master 当前的数据库状态

  1. 请求同步数据
  2. 创建 RDB 同步数据
  3. 恢复 RDB 同步数据
  4. 请求部分同步数据
  5. 恢复部分同步数据,至此,数据同步工作完成!

最后状态:slave 具有了 master 端全部数据,包含 RDB 过程接收的数据。master 保存了 slave 当前数据同步的位置。主从之间完成了数据克隆。

数据同步阶段 master 说明

  • 如果 master 数据量巨大,数据同步阶段应避开流量高峰期,避免造成 master 阻塞,影响业务正常执行
  • 复制缓冲区大小设定不合理,会导致数据溢出。如进行全量复制周期太长,进行部分复制时发现数据已经存在丢失的情况,必须进行第二次全量复制,致使 slave 陷入死循环状态。
  • 复制缓冲区大小配置:repl-backlog-size 1mb
  • master 单机内存占用主机内存的比例不应过大,建议使用 50%-70% 的内存,留下 30%-50% 的内存用于执行 bgsave 命令和创建复制缓冲区

数据同步阶段 slave 说明

  • 为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步,建议关闭此期间的对外服务
  • 开启只读服务:slave-read-only yes
  • 当主服务器挂掉时是否提供过期数据:slave-serve-stale-data yes I no
  • 数据同步阶段,master 发送给 slave 信息可以理解 master 是 slave 的一个客户端,主动向 slave 发送命令
  • 多个 slave 同时对 master 请求数据同步,master 发送的 RDB 文件增多,会对带宽造成巨大冲击,如果 master 带宽不足,因此数据同步需要根据业务需求,适量错峰
  • slave 过多时,建议调整拓扑结构,由一主多从结构变为树状结构,中间的节点既是 master,也是 slave。注意使用树状结构时,由于层级深度,导致深度越高的 slave 与最顶层 master 间数据同步延迟较大,数据一致性变差,应谨慎选择

三、命令传播阶段

命令传播阶段出现了断网现象

  • 网络闪断闪连:忽略
  • 短时间网络中断:部分复制
  • 长时间网络中断:全量复制

部分复制的三个核心要素

  • 服务器的运行 id(run id)
    • 概念:服务器运行 ID 是每一台服务器每次运行的身份识别码,一台服务器多次运行可以生成多个运行 id
    • 组成:运行 id 由 40 位字符组成,是一个随机的十六进制字符例如:fdc9ff13b9dfgab28db42lo35sde52bb5e3fcdce
    • 作用:运行 id 被用于在服务 器间进行传输,识别身份如果想两次操作均对同一台服务器进行,必须每次操作携带对应的运行 id,用于对方识别
    • 实现方式:运行 id 在每台服务器启动时自动生成的,master 在首次连接 slave 时,会将自己的运行 ID 发送给 slave,slave 保存此 ID,通过 info server 命令,可以查看节点的 runid
  • 主服务器的复制积压缓冲区
    • 概念:复制缓冲区,又名复制积压缓冲区,是一个先进先出(FIFO)的队列,用于存储服务器执行过的命令,每次传播命令,master 都会将传播的命令记录下来,并存储在复制缓冲区。复制缓冲区默认数据存储空间大小是1M,由于存储空间大小是固定的,当入队元素的数量大于队列长度时,最先入队的元素会被弹出,而新元素会被放入队列
    • 由来:每台服务器启动时,如果开启有 AOF 或被连接成为 master 节点,即创建复制缓冲区
    • 作用:用于保存 master 收到的所有指令(仅影响数据变更的指令,例如 set,select)
    • 数据来源:当 master 接收到主客户端的指令时,除了将指令执行,会将该指令存储到缓冲区中
  • 主从服务器的复制偏移量(offset)
    • 概念:一个数字,描述复制缓冲区中的指令字节位置
    • 分类:
      • master 复制偏移量:记录发送给所有 slave 的指令字节对应的位置(多个)
      • slave 复制偏移量:记录 slave 接收 master 发送过来的指令字节对应的位置(一个)
    • 数据来源:
      • master 端:发送一次记录一次
      • slave 端:接收一次记录一次
    • 作用:同步信息,比对 master 与 slave 的差异,当 slave 断线后,恢复数据使用

心跳机制

进入命令传播阶段候,master 与 slave 间需要进行信息交换,使用心跳机制进行维护,实现双方连接保持在线

master 心跳:

  • 指令:PING
  • 周期:由 repl-ping-slave-period 决定,默认 10 秒
  • 作用:判断 slave 是否在线
  • 查询:INFO replication 获取 slave 最后一次连接时间间隔,lag 项维持在 0 或 1 视为正常

slave 心跳任务

  • 指令:REPLCONF ACK{offset}
  • 周期:1 秒
  • 作用 1:汇报 slave 自己的复制偏移量,获取最新的数据变更指令
  • 作用 2:判断 master 是否在线

心跳阶段注意事项

  • 当 slave 多数掉线,或延迟过高时,master 为保障数据稳定性,将拒绝所有信息同步操作
    • min-slaves-to-write 2
    • min-slaves-max-lag 8
    • slave 数量少于 2 个,或者所有 slave 的延迟都大于等于 10 秒时,强制关闭 master 写功能,停止数据同步
  • slave 数量由 slave 发送 REPLCONF ACK 命令做确认
  • slave 延迟由 slave 发送 REPLCONF ACK 命令做确认

综上主从复制完整工作流程

 

主从复制常见问题

频繁的全量复制

伴随着系统的运行,master 的数据量会越来越大,一旦 master 重启,runid 将发生变化,会导致全部 slave 的全量复制操作。内部优化调整方案:

  1. master 内部创建 master_replid 变量,使用 runid 相同的策略生成,长度 41 位,并发送给所有 slave
  2. 在 master 关闭时执行命令 shutdowm save,进行 RDB 持久化将 runid 与 offset 保存到 RDB 文件中。repl-id、repl-offset 可以通过 redis-check-rdb 命令查看该信息
  3. master 重启后加载 RDB 文件,恢复数据。重启后,将 RDB 文件中保存的 repl-id 与 repl-offset 加载到内存中。master_repl_id = repl、master_repl_offset = repl-offset 可以通过 info 命令查看该信息

作用:本机保存上次 runid,重启后恢复该值,使所有 slave 认为还是之前的 master

频繁的全量复制

问题现象:网络环境不佳,出现网络中断,slave不提供服务

问题原因:复制缓冲区过小,断网后 slave 的 offset 越界,触发全量复制

最终结果:slave 反复进行全量复制

解决方案:修改复制缓冲区大小。repl--backlog-size 建议设置如下:

  1. 测算从 master 到 slave 重连平均时长 second
  2. 获取 master 平均每秒产生写命令数据总量 write_size_per_second
  3. 最优复制缓冲区空间 = 2 * second * write_size_per_second

频繁的网络中断

问题现象:master 的 CPU 占用过高或 slave 频繁断开连接

问题原因:

  • slave 每 1 秒发送 REPLCONE ACK 命令到 master
  • 当 slave 接到了慢查询时(keys *,hgetall 等),会大量占用 CPU 性能
  • master 每1秒调用复制定时函数 replicationCron(),比对 slave 发现长时间没有进行响应

最终结果:master 各种资源(输出缓冲区、带宽连接等)被严重占用

解决方案:通过设置合理的超时时间,确认是否释放 slave,repl-timeout 参数定义了超时时间的阈值(默认60秒),超过该值,释放 slave

频繁的网络中断

问题现象:slave 与 master 连接断开

问题原因:

  • master 发送 ping 指令频度较低
  • master 设定超时时间较短
  • ping 指令在网络中存在丢包

解决方案:提高 ping 指令发送的频度,设置 repl-ping-slave-period。超时时间 repl-time 至少是 ping 指令频度的 5 到 10 倍,否则 slave 很容易判定超时

数据不一致

问题现象:多个 slave 获取相同数据不同步

问题原因:网络信息不同步,数据发送有延迟

解决方案:

  • 优化主从间的网络环境,通常放置在同-一个机房部署,如使用阿里云等云服务器时要注意此现象
  • 监控主从节点延迟(通过 offset)判断,如果 slave 延迟过大,暂时屏蔽程序对该 slave 的数据访问。slave-serve-stale-data yes | no,开启后仅响应 info、slaveof 等少数命令(慎用,除非对数据一致性要求很高)

 

哨兵

哨兵(sentinel)是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的 master 并将所有 slave 连接到新的 master。

哨兵作用

监控:不断的检查 master 和 slave 是否正常运行。master 存活检测、master 与 slave 运行情况检测

通知(提醒):当被监控的服务器出现问题时,向其它(哨兵间,客户端)发送通知。

自动故障转移:断开 master 与 slave 连接,选取一个 slave 作为 master,将其它 slave 连接到新的 master,并告知客户端新的服务器地址。

注意:哨兵也是一台 redis 服务器,只是不提供数据服务,通常哨兵配置数量为单数(尽量避免投票持平的情况)。

哨兵搭建

cat sentinel.conf | grep -v '#' | grep -v '^$'
sed 's/要被取代的字串/新的字串/g' sentinel-6379.conf > sentinel-6380.conf

# 配置
port 26379
dir /opt/redis
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster1
sentinel failover-timeout mymaster 180000

# 启动
redis-sentinel sentinel-端口号.conf

 

哨兵工作流程

一、监控阶段

用于同步各个节点的状态信息

  • 获取各个 sentinel 的状态(是否在线)
  • 获取 master 的状态:master 属性(runid、role:master)、各个 slave 的详细信息
  • 获取所有 slave 的状态(根据 master 中的 slave 信息):slave 属性(runid、role:slave、master_host、master_port、offset...)

二、通知阶段

维护长期的信息对等

三、故障转移阶段

1、发现和确认节点已宕机

2、sentinel 集群会投票选举出一个 sentinel 去清除已宕机节点

3、被选出的 sentinel 去处理宕机情况

  1. 服务器列表中挑选备选 master:在线的、响应快的、与原 master 断开时间久的、优先原则(优先级、offset、runid)
  2. 发送指令(sentinel):向新的 master 发送 slaveof no one,其它 slave 发送 slaveof 新 master IP 端口

 

集群

将多个主从连接在一起,分散单台服务器的访问压力,实现负载均衡。分散单台服务器的存储压力,实现可扩展性。降低单台服务器宕机带来的业务灾难。

存储设计

Redis 集群的分片特征在于通过算法(CRC16 再 %16384)设计,计算出 key 应该保存的位置。将所有的存储空间拆分为 16384 个槽位,某一个节点负责其中一些槽位。将 key 按照计算出的结果放到对应的槽位。

每个节点都知道其它节点槽的范围,当增加节点时,现有的节点会转移一部分槽到新节点上,对应的槽中的数据也会过去。所以增减节点只是改变槽的位置。

当要查找 key 不在当前节点时,会告诉客户端(重定向)去连接正确的节点查询 key,而不是充当中转的角色。即最多两次就能命中要查找的数据。

集群搭建

每台节点的配置都是一样的,然后启动 Redis 即可

port 6379
daemonize no
dir /opt/redis
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 10 2
appendonly yes
appendfsync always
appendfilename appendonly-6379.aof
bind 127.0.0.1
databases 16

# 集群节点配置
# 设置加入cluster,成为其中的节点
cluster-enabled yes
# 配置文件名,该文件属于自动生成,仅用于快速查找文件并查询文件内容
cluster-config-file nodes-6379.conf
# 节点服务响应超时时间,用于判定该节点是否下线或切换为从节点
cluster-node-timeout 10000
# master 连接的 slave 最小数量
# cluster-migration-barrier <count>

所有 Redis 启动好后,再配置集群

# 把所有节点的 IP 和 PORT 都写上,注意节点之间是否能连通
# --cluster-replicas 1:表示希望为集群中的每个主节点创建一个从节点(一主一从)
# --cluster-replicas 2:表示希望为集群中的每个主节点创建两个从节点(一主二从)
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

# 期间会询问是否使用上述配置,输入 yes 即可
# 最后会看到所有的 slot 成功分配

# 连接集群
redis-cli -c -p 7000

# 查看集群节点信息
cluster nodes
# 进入一个从节点 redis,切换其主节点
cluster replicate <master-id>
# 发现一个新节点,新增主节点
cluster meet ip:port
# 忽略一个没有 solt 的节点
cluster forget <id>
# 手动故障转移
cluster failover

主从下线与切换

从节点下线后对集群不影响,只是标记一下从节点不能用了,当从节点恢复后就再修改一下标记为可用。

主节点下线后,从节点会按照配置文件的超时时间去连接主节点(一秒一次),超过时间还连接不上主节点,就把自己升级为主节点。

当掉线的主节点重新连接后会变为从节点。

对于其它主从节点来说只是维护一下节点信息,但是对于掉线的主从节点还会进行数据同步操作。

 

解决方案

缓存预热

现象:服务器启动后迅速宕机

问题排查:请求数量较高。主从之间数据吞吐量较大,数据同步操作频度较高

解决方案:日常例行统计数据访问记录,统计访问频度较高的热点数据。利用 LRU 数据删除策略,构建数据留存队列,例如:storm 与 kafka 配合。将统计结果中的数据分类,根据级别,Redis 优先加载级别较高的热点数据。利用份布式多服务器同时进行数据读取,提速数据加载过程。使用脚本程序固定触发数据预热过程。如果条件允许,使用 CDN(内容分发网络),效果会更好

缓存预热就是系统启动前,提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题!

让用户直接查询事先被预热的缓存数据!

缓存雪崩

数据库服务器崩溃:系统平稳运行过程中,忽然数据库连接量激增。应用服务器无法及时处理请求。大量 408,500 错误页面出现。客户反复刷新页面获取数据。数据库崩溃。应用服务器崩溃。重启应用服务器无效。Redis 服务器崩溃。Redis 集群崩溃。重启数据库后再次被瞬间流量放倒

问题排查:在一个较短的时间内,缓存中较多的 key 集中过期。此周期内请求访问过期的数据,Redis 未命中,Redis 向数据库获取数据。数据库同时接收到大量的请求无法及时处理。Redis 大量请求被积压,开始出现超时现象。数据库流量激增,数据库崩溃。重启后仍然面对缓存中无数据可用。Redis 服务 器资源被严重占用,Redis 服务器崩溃。Redis 集群呈现崩塌,集群瓦解。应用服务器无法及时得到数据响应请求,来自客户端的请求数量越来越多,应用服务器崩溃。应用服务器、Redis、数据库全部重启,效果不理想

解决方案:

  1. 更多的页面静态化处理
  2. 构建多级缓存架构:Nginx 缓存 + Redis 缓存 + Ehcache 缓存
  3. 检测Mysq|严重耗时业务进行优化:对数据库的瓶颈排查(例如超时查询、耗时较高事务等)
  4. 灾难预警机制:监控 Redis 服务器性能指标(CPU占用、CPU使用率、内存容量、查询平均响应时间、线程数)
  5. 限流、降级:短时间范围内牺牲一些客户体验,限制一部分请求访问,降低应用服务器压力,待业务 低速运转后再逐步放开访问
  6. LRU 与 LFU 切换
  7. 数据有效期策略调整:
    • 根据业务数据有效期进行分类错峰,A 类 90 分钟、B 类 80 分钟、C 类 70 分钟
    • 过期时间使用固定时间 + 随机值的形式,稀释集中到期的 key 的数量
  8. 超热数据使用永久 key
  9. 定期维护(自动 + 人工):对即将过期数据做访问量分析,确认是否延时,配合访问量统计,做热点数据的延时
  10. 加锁,慎用!

缓存雪崩就是瞬间过期数据量太大,导致对数据库服务器造成压力。如能够有效避免过期时间集中,可以有效解决雪崩现象的出现(约40%),配合其他策略一起使用,并监控服务器的运行数据,根据运行记录做快速调整。

缓存击穿

数据库服务器崩溃:系统平稳运行过程中。数据库连接量瞬间激增。Redis 服务 器无大量 key 过期。Redis 内存平稳,无波动。Redis 服务器 CPU 正常。数据库崩溃

问题排查:Redis 中某个 key 过期,该 key 访问巨大。多个数据请求从服务器直接压到 Redis 后,均未命中。Redis 在短时间内发起了大量对数据库中同一数据的访问

问题分析:单个 key 高热数据。key 过期

解决方案:

  1. 预先设定:以电商为例,每个商家根据店铺等级,指定若干款主打商品,在购物节期间,加大此类信息 key 的过期时长。注意:购物节不仅仅指当天,以及后续若干天,访问峰值呈现逐渐降低的趋势
  2. 现场调整:监控访问量,对自然流量激增的数据延长过期时间或设为久性 key
  3. 后台刷新数据:启动定时任务,高峰期来临之前,刷新数据有效期,确保不丢失
  4. 二级缓存:设置不同的失效时间,保障不会被同时淘汰就行
  5. 加锁:分布式锁,防止被击穿,但是要注意也是性能瓶颈,慎重!

缓存击穿就是单个高热数据过期的瞬间,数据访问量较大,未命中 Redis 后,发起了大量对同一数据的数据库访问,导致对数据库服务器造成压力。应对策略应该在业务数据分析与预防方面进行,配合运行监控测试与即时调整策略,毕竟单个 key 的过期监控难度较高,配合雪崩处理策略即可。

缓存穿透

数据库服务器崩溃:系统平稳运行过程中。应用服务器流量随时间增量较大。Redis 服务器命中率随时间逐步降低。Redis 内存平稳,内存无压力。Redis 服务器 CPU 占用激增。数据库服务器压力激增。数据库崩溃

问题排查:Redis 中大面积出现未命中。出现非正常 URL 访问

问题分析:获取的数据在数据库中也不存在,数据库查询未得到对应数据。Redis 获取到 null 数据未进行持久化,直接返回。下次此类数据到达重复上述过程。出现黑客攻击服务器

解决方案:

  1. 缓存 null:对查询结果为 null 的数据进行缓存(长期使用,定期清理),设定短时限,例如30-60秒,最高 5 分钟
  2. 白名单策略:
    • 提前预热各种分类数据 id 对应的 bitmaps,id 作为 bitmaps 的 offset,相当于设置了数据白名单。当加载正常数据时,放行,加载异常数据时直接拦截(效率偏低)
    • 使用布隆过滤器(有关布隆过滤器的命中问题对当前状况可以忽略)
  3. 实施监控:实时监控 Redis 命中率(业务正常范围时,通常会有一个波动值)与 null 数据的占比。
    • 非活动时段波动:通常检测 3-5 倍,超过 5 倍纳入重点排查对象。
    • 活动时段波动:通常检测 10-50 倍,超过 50 倍纳入重点排查对象。
    • 根据倍数不同,启动不同的排查流程。然后使用名单进行防控(运营)
  4. key 加密:问题出现后,临时启动防灾业务 key,对 key 进行业务层传输加密服务,设定校验程序,过来的 key 校验。例如每天随机分配 60 个加密串,挑选 2-3 个,混淆到页面数据 id 中,发现访问 key 不满足规则,驳回数据访问

缓存击穿访问了不存在的数据,跳过了合法数据的 Redis 数据缓存阶段,每次访问数据库,导致对数据库服务器造成压力。通常此类数据的出现量是一个较低的值,当出现此类情况以毒攻毒,并及时报警。应对策略应该在临时预案防范方面多做文章。

无论是黑名单还是白名单,都是对整体系统的压力,警报解除后尽快移除。

性能监控

性能指标:Performance

  • latency:Redis 响应一个请求的时间
  • instantaneous_ops_per_sec:平均每秒处理请求总数
  • hit rate(calculated):缓存命中率(计算出来的)

内存指标:Memory

  • used_memory:已使用内存
  • mem_fragmentation_ratio:内存碎片率
  • evicted_keys:由于最大内存限制被移除的 key 的数量
  • blocked_clients:由于 BLPOP、BRPOP、or BRPOPLPUSH 而被阻塞的客户端

基本活动指标:Basic Activity

  • connected_clients:客户端连接数
  • connected slaves:Slave 数量
  • master_last_io_seconds_ago:最近一次主从交互之后的秒数
  • keyspace:数据库中的 key 值总数

持久性指标:Persistence

  • rdb_last_save_time:最后一次持久化保存到磁盘的时间戳
  • rdb_changes_since_last_save:自最后一次持久化以来数据库的更改数

错误指标:Error

  • rejected_connections:由于达到 maxclient 限制而被拒绝的连接数
  • keyspace_misses:Key 值查找失败(没有命中)次数
  • master_link_down_since_seconds:主从断开的持续时间(以秒为单位)

监控方式

  • 工具:Cloud Insight Redis、Prometheus、Redis-stat、Redis-faina、RedisLive、zabbix
  • 命令:benchmark、redis cli、monitor、showlog

命令和配置

# benchmark,注意不是 Redis 命令
# -h 指定服务器主机名,默认值 127.0.0.1
# -p 指定服务器端口,默认值 6379
# -S 指定服务器 socket
# -C 指定并发连接数,默认值 50
# -n 指定请求数,默认值 10000
# -d 以字节的形式指定 SET/GET 值的数据大小,默认值 2
# -k 1=keepalive,0 = reconnect,默认值 1
# -r SET/GET/INCR 使用随机 key,SADD 使用随机值
# -P 通过管道传输 <numreq> 请求,默认值 1
# -q 强制退出 redis,仅显示 query/sec 值
# --CSV 以 CSV 格式输出
# -l 生成循环,永久执行测试
# -t 仅运行以逗号分隔的测试命令列表
# -i Idle模式。仅打开 N 个 Idle 连接并等待
# redis-benchmark [-h] [-P] [-c] [-n <requests]> [-k]

# 50 个连接,10000 次请求对应的性能
redis-benchmark
# 100 个连接,5000 次请求对应的性能
redis-benchmark -c 100 -n 5000

# 打印服务器调试信息,Redis 命令
monitor

# get:获取慢查询日志,len:获取慢查询日志条目数,reset:重置慢查询日志
s1ow1og [operator]

# Redis 相关配置
# 设置慢查询的时间下线,单位:微妙
slowlog-log-slower-than 1000
# 设置慢查询命令对应的日志显示长度,单位:命令数
slowlog-max-len 100

 


https://redis.io/topics/replication

https://redis.io/topics/sentinel

https://redis.io/topics/cluster-tutorial

https://redis.io/topics/cluster-spec

posted @ 2021-03-25 14:50  江湖小小白  阅读(169)  评论(0编辑  收藏  举报