高可用Redis(五):瑞士军刀之慢查询,Pipeline和发布订阅

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 1.慢查询1.1 慢查询的生命周期步骤一:client通过网络向Redis发送一条命令步骤二:由于Redis是单线程应用,可以把Redis想像成一个队列,client执行的所有命令都在排队等着server端执行步骤三:Redis服务端按顺序执行命令步骤四:server端把命令结果通过网络返...

1.慢查询

1.1 慢查询的生命周期

步骤一:client通过网络向Redis发送一条命令
步骤二:由于Redis是单线程应用,可以把Redis想像成一个队列,client执行的所有命令都在排队等着server端执行
步骤三:Redis服务端按顺序执行命令
步骤四:server端把命令结果通过网络返回给client

说明:

慢查询发生在命令执行过程中,不包含网络延迟时间及排除等待执行的时间
客户端超时不一定慢查询,但慢查询是客户端超时的一个可能因素

1.2 慢查询的配置项

slowlog-max-len             慢查询队列的长度
slowlog-log-slower-than     慢查询阈值(单位:微秒),执行时间超过阀值的命令会被加入慢查询命令
    如果设置为0,则会记录所有命令,通常在需要记录每条命令的执行时间时使用
    如果设置为小于0,则不记录任何命令
slowlog list                慢查询记录

说明:

慢查询是一个先进先出的队列,如果一条命令在执行过程中被列入慢查询范围内,就会被放入一个队列,这个队列是基于Redis的列表来实现
,而且这个队列是固定长度的,当队列的长度达到固定长度时,最先被放入队列就会被pop出去
慢查询队列保存在内存之中,不会做持久化,当Redis重启之后就会消失

1.3 慢查询配置方法

1.3.1 修改配置文件重启

修改/etc/redis.conf配置文件,配置慢查询
修改配置方式应该在第一次配置Redis中时配置完成,生产后不建议修改配置文件

1.3.2 动态配置

127.0.0.1:6379> config get slowlog-max-len
1) "slowlog-max-len"
2) "128"
127.0.0.1:6379> config get slowlog-log-slower-than
1) "slowlog-log-slower-than"
2) "10000"
127.0.0.1:6379> config set slowlog-max-len 1000
OK
127.0.0.1:6379> config get slowlog-max-len
1) "slowlog-max-len"
2) "1000"
127.0.0.1:6379> config set slowlog-log-slower-than 1000
OK
127.0.0.1:6379> config get slowlog-log-slower-than
1) "slowlog-log-slower-than"
2) "1000"

1.4 慢查询命令

slowlog get [n]         获取慢查询队列
slowlog len             获取慢查询队列长度
slowlog reset           清空慢查询队列

1.5 Redis慢查询运维经验

slowlog-max-len不要设置过小,通常设置1000左右
slowlog-log-slower-than不要设置过大,默认10ms,通常设置1ms
理解命令生命周期
可以通过slowlog get等命令定期将慢查询命令持久化到其他数据源,这样就可以查到很多历史的慢查询操作命令
在生产环境中,不管slowlog-max-len设置多大,当慢查询命令逐步增多时,最开始的慢查询命令会被丢掉
当需要查询历史数据时,这些慢查询命令都是非常关键的
可以使用开源软件来实现这些功能,对于分析解决Redis问题是非常有帮助的

2.Pipeline

2.1 Pipeline的概念

一次网络命令通信模型:

client通过网络传输命令到server端
server端通过计算得到命令执行结果
server端把命令执行结果给client
    

此时:

一次网络命令通信时间=1次网络时间 + 1次命令时间

此时如果有多条命令呢,那就只能一条一条的输入命令执行了

n次时间 = n次网络时间 + n次命令时间

Redis执行命令的时间很快,但是网络传输却可能有很大延迟,

pipeline就是把一批命令进行打包,然后传输给server端进行批量计算,然后按顺序将执行结果返回给client端

使用Pipeline模型进行n次网络通信需要的时间

1次pipeline(n条命令) = 1次网络时间 + n次命令时间

2.2 例子

import redis
import time

client = redis.StrictRedis(host='192.168.81.100',port=6379)
start_time = time.time()

for i in range(10000):
    client.hset('hashkey','field%d' % i,'value%d' % i)

ctime = time.time()
print(client.hlen('hashkey'))
print(ctime - start_time)

程序执行结果:

10000
2.0011684894561768

在上面的例子里,直接向Redis中写入10000条hash记录,需要的时间为2.00秒

使用pipeline的方式向Redis中写入1万条hash记录

import redis
import time

client = redis.StrictRedis(host='192.168.81.100',port=6379)
start_time = time.time()

for i in range(100):
    pipeline = client.pipeline()
    j = i * 100
    while j < (i+ 1) * 100:
        pipeline.hset('hashkey1','field%d' % j * 100,'value%d' % i)
        j += 1
    pipeline.execute()

ctime = time.time()
print(client.hlen('hashkey1'))
print(ctime - start_time)

程序执行结果:

10000
0.3175079822540283

可以看到使用Pipeline方式每次向Redis服务端发送100条命令,发送100次所需要的时间仅为0.31秒,可以看到使用Pipeline可以节省网络传输时间

2.3 Pipeline使用建议

首先要注意每次pipeline携带数据量不能太大
pipeline可以提高Redis批量处理的并发的能力,但是并不能无节制的使用
如果批量执行的命令数量过大,则很容易对网络及客户端造成很大影响,此时可以把命令分割,每次发送少量的命令到服务端执行
pipeline每次只能作用在一个Redis节点上

3.发布订阅

3.1 发布订阅中的角色

发布者(publisher)
订阅者(subscriber)
频道(channel)

3.2 发布订阅的模型

Redis server就相当于频道
发布者是一个redis-cli,通过redis server发布消息
订阅者也是于一个redis-cli,如果订阅了这个频道,就可以通过redis server获取消息

说明:

发布订阅就是一个生产者消费者模型
每个订阅者可以订阅多个频道
发布者发布消息后,订阅者就可以收到不同频道的消息
订阅者不可以接收未订阅频道的消息
订阅者订阅某个频道后,Redis无法做消息的堆积,不能接收频道被订阅之前发布的消息

3.3 发布订阅的命令

publish channel message         发布消息
subscribe [channel]             订阅频道
unsubscribe [channel]           取消订阅
psubscribe [pattern...]         订阅指定模式的频道
punsubscribe [pattern...]       退订指定模式的频道
pubsub channels                 列出至少有一个订阅者的频道
pubsub numsub [channel...]      列表给定频道的订阅者数量
pubsub numpat                   列表被订阅模式的数量 

例子:

打开一个终端1

127.0.0.1:6379> subscribe sohu_tv               # 订阅sohu_tv频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "sohu_tv"
3) (integer) 1

再次打开一个终端2

127.0.0.1:6379> publish sohu_tv 'hello python'      # sohu_tv频道发布消息
(integer) 1
127.0.0.1:6379> publish sohu_tv 'hello world'       # sohu_tv频道发布消息
(integer) 3

可以看到终端1中已经接收到sohu_tv发布的消息

127.0.0.1:6379> subscribe sohu_tv
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "sohu_tv"
3) (integer) 1
1) "message"
2) "sohu_tv"
3) "hello python"
1) "message"
2) "sohu_tv"
3) "hello world"

打开终端3,取消订阅sohu_tc频道

127.0.0.1:6379> unsubscribe sohu_tv
1) "unsubscribe"
2) "sohu_tv"
3) (integer) 0

3.4 发布订阅与消息队列

redis server维护一个队列
消息发布者,相当于一个redis-cli,通过redis server发布消息
消息订阅者就相当于一个redis-cli,所有的消息订阅者通过redis server抢消息发布者发布的消息
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
28天前
|
NoSQL Redis
Redis 发布订阅
10月更文挑战第18天
28 1
Redis 发布订阅
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
112 2
基于Redis的高可用分布式锁——RedLock
|
4月前
|
监控 NoSQL Redis
Redis 哨兵模式高可用
Redis 哨兵模式高可用
85 4
|
10天前
|
NoSQL 网络协议 Java
【赵渝强老师】Redis的管道Pipeline
Redis采用客户端-服务器模型和请求/响应协议,通常一个请求包括客户端发送查询请求并等待服务端响应。为了提高性能,Redis引入了管道PipeLine技术,可以一次性发送多条命令并一次性返回结果,减少客户端与服务器间的通信次数,从而降低往返延迟。示例代码展示了普通命令和管道命令在插入1万条数据时的性能差异,后者执行时间显著缩短。视频讲解提供了更详细的解释。
|
1月前
|
存储 NoSQL 大数据
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
33 3
|
1月前
|
存储 Prometheus NoSQL
大数据-44 Redis 慢查询日志 监视器 慢查询测试学习
大数据-44 Redis 慢查询日志 监视器 慢查询测试学习
25 3
|
2月前
|
消息中间件 存储 NoSQL
18)Redis 的发布订阅模型
18)Redis 的发布订阅模型
33 0
|
3月前
|
存储 监控 NoSQL
揭秘Redis慢查询:这个工具将彻底改变你的性能优化策略!
【8月更文挑战第8天】在互联网应用中,数据库性能常成瓶颈。Redis作为高速内存数据库亦可能遭遇慢查询问题。本文探讨慢查询成因与解决方法。首先定义慢查询及其影响因素,随后介绍Redis内置的慢查询日志功能,通过配置`slowlog-log-slower-than`与`slowlog-max-len`来监控执行时间过长的命令。利用`SLOWLOG get`命令分析日志,定位性能瓶颈所在。以`LRANGE`命令为例,提出数据结构调整、使用流水线、限制返回元素数量、异步执行及优化内存使用等策略。最终实现Redis性能提升,确保应用流畅运行。性能优化需持续监控、分析与调整。
98 1
|
3月前
|
监控 NoSQL Go
Go语言中高效使用Redis的Pipeline
Redis 是构建高性能应用时常用的内存数据库,通过其 Pipeline 和 Watch 机制可批量执行命令并确保数据安全性。Pipeline 类似于超市购物一次性结账,减少网络交互时间,提升效率。Go 语言示例展示了如何使用 Pipeline 和 Pipelined 方法简化代码,并通过 TxPipeline 保证操作原子性。Watch 机制则通过监控键变化实现乐观锁,防止并发问题导致的数据不一致。这些机制简化了开发流程,提高了应用程序的性能和可靠性。
65 0
|
4月前
|
负载均衡 NoSQL 应用服务中间件
搭建高可用及负载均衡的Redis
【7月更文挑战第10天】
140 1