redis—》高级用法之慢查询/pipline与事务/发布订阅/bitmap位图/HyperLogLog/GEO地理位置信息/持久化

高级用法之慢查询

# 配置一个时间,如果查询时间超过了我们设置的时间,我们就认为这是一个慢查询
# 配置的慢查询,只在命令执行阶段


# 慢查询演示
	-设置慢查询---》只要超过某个时间的命令---》都会保存起来
    # 设置记录所有命令
    CONFIG SET slowlog-log-slower-than 0
    # 最多记录100条
    config set slowlog-max-len 100
    # 持久化到本地配置文件
    config rewrite
    
# 记录所有命令了


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


# 有什么用,如何聊?
	-公司好多项目用这一个redis实例
    -最近公司发现,redis响应非常慢
    -通过排查它的 慢查询--》排查出一些慢命令
    -找到对应的执行项目---》位置
   	-避免再执行这些命令了

pipline与事务

### python客户端实现pipline
import redis
pool = redis.ConnectionPool(host='10.211.55.4', port=6379)
r = redis.Redis(connection_pool=pool)
# pipe = r.pipeline(transaction=False)
#创建pipeline
pipe = r.pipeline(transaction=True)
#开启事务
pipe.multi()
pipe.set('name', 'lqz')
#其他代码,可能出异常

pipe.set('role', 'nb')
 
pipe.execute()


# 原生redis操作操作事务

# 1 mutil  开启事务,放到管道中一次性执行
multi   # 开启事务
set name lqz
set age 18
exec



# 2 模拟事务  mutil +watch 模拟事务   乐观锁
# 在开启事务之前,先watch
watch age
multi
decr age
exec

# 另一台机器
multi
decr age
exec  # 先执行,上面的执行就会失败(乐观锁,被wathc的事务不会执行成功)


# django+mysql实现乐观锁
# 使用python+redis实现乐观锁
https://www.cnblogs.com/liuqingzheng/p/9997092.html

发布订阅

# 发布者发布了消息,所有的订阅者都可以收到,就是生产者消费者模型(后订阅了,无法获取历史消息)
# 设计模式的:观察者模式



# 发布消息,向lqz频道发送了hellowrold--》不会有人收到---》没有人订阅
publish lqz "hello world"

# 订阅消息客户端1
subscribe lqz

# 订阅消息客户端2
subscribe lqz



# 发布订阅和消息队列的区别
发布订阅,订阅者都能收到,
消息队列有个抢的过程,只有一个抢到

bitmap位图

# 操作 比特位
set hello big  #放入key位hello 值为big的字符串
getbit hello 0 #取位图的第0个位置,返回0
getbit hello 1 #取位图的第1个位置,返回1 如上图


# 设置比特位
etbit hello 7 1 #把hello的第7个位置设为1 这样,big就变成了cig


# 获取指定字节范围内,有几个1
bitcount key 0 3   # 数字指的是字节

# 基于上面,可以做独立用户统计
	-假设有1亿用户,假设5千万活跃---》统计日活
    	-使用集合:大约需要200m
        -使用bitmap位图:大约需要12m内存
    -如果活跃用户量少,不适合用bitmap
 


# 面试题:
redis的key值最大多少 512M
redis的string 类型vaule值最大多少  512M

HyperLogLog

# 基于HyperLogLog算法:极小的空间完成独立数量统计,去重

# 布隆过滤器

# 具体操作
pfadd uuids "uuid1" "uuid2" "uuid3" "uuid4"   # 增加值
pfcount uuids  # 统计个数

# 数据不能删除单个

# 跟集合很像,但是占的内存空间很小
    百万级别独立用户统计,百万条数据只占15k
    错误率 0.81%
    无法取出单条数据,只能统计个数
# 作用:
	-爬虫去重
    -黑白名单
    -垃圾邮件过滤
    -独立用户统计
    	-有个用户登录,就把用户id放到HyperLogLog中
        -最后只需要统计一下 个数  就能统计出今天的活跃人数
   

GEO地理位置信息

GEO(地理信息定位):存储经纬度,计算两地距离,范围等

# 类似于
	-附近的人,餐馆,医院
    -附近5km内的 xx
    -我距离某个好友的距离
    
    
# 经纬度哪里来?
	-前端(app,web),都是可以申请,获得经纬度的--》是前端做
    -前端拿到---》调用我们的一个接口---》把经纬度传入---》存起来--》redis的geo中
    -我要统计我附近5公里以内的好友
    	-需要我的经纬度
        -我所有好友的经纬度,已经在 redis的geo中存好了



# 案例
geoadd cities:locations 116.28 39.55 beijing 
geoadd cities:locations 117.12 39.08 tianjin
geoadd cities:locations 114.29 38.02 shijiazhuang
geoadd cities:locations 118.01 39.38 tangshan
geoadd cities:locations 115.29 38.51 baoding


# 计算两个地理位置的距离
geodist cities:locations beijing tianjin km


# 计算北京方圆 150km内的城市
georadiusbymember cities:locations beijing 90 km


# geo本质时zset类型

持久化

# redis的所有数据保存在内存中,支持把数据持久化到硬盘上

# 数据库(mysql,redis,mongodb,rabbitmq,infludb,clickhose,kafak)---》持久化方法通常是以下两种
    快照:某时某刻数据的一个完成备份,
     -mysql的Dump
     -redis的RDB
    写日志:任何操作记录日志,要恢复数据,只要把日志重新走一遍即可
      -mysql的 Binlog
      -Redis的 AOF
# redis支持 :3中方案
	-rdb方案:在某一刻做完成备份
    -aof方案:每个操作都会有日志,恢复的时候,把日志重放即可
    -混合持久化:rdb+aof方案
    	-aof重写
        -隔一段时候,会把之前的日志做成rdb文件放在日志文件中,后续的继续使用aof方案记录日志
        -达到快速恢复的目的

        
# 

rdb方案

# 触发机制-主要三种方式
# save(同步)--->阻塞--》如果数据量很多---》影响redis的查询操作
save



# bgsave(异步,Backgroud saving started)




# 自动(通过配置)
配置   seconds   changes
save   900        1
save   300        10
save   60         10000

如果60s中改变了1w条数据,自动生成rdb
如果300s中改变了10条数据,自动生成rdb
如果900s中改变了1条数据,自动生成rdb

AOF

# AOF的三种策略
日志不是直接写到硬盘上,而是先放在缓冲区,缓冲区根据一些策略,写到硬盘上
always:redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件
everysec(默认值):redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件
no:redis——》写命令刷新的缓冲区—》操作系统决定,缓冲区fsync到硬盘–》AOF文件



# AOF 重写
本质就是把过期的,无用的,重复的,可以优化的命令,来优化
这样可以减少磁盘占用量,加速恢复速度

# aof配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec 
dir /root/lqz/redis/data

混合持久化

# 必须先开启AOF
aof-use-rdb-preamble yes

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>