redis高级用法
1 redis高级用法之慢查询
慢查询是一个先进先出的队列
# 通过配置文件，两个参数配置慢查询
slowlog-max-len
慢查询是一个先进先出的队列
固定长度
保存在内存中
slowlog-max-len
慢查询阈值（单位：微秒）
slowlog-log-slower-than=0，记录所有命令
slowlog-log-slower-than <0,不记录任何命令
# 只要时间超过配置的时候，命令就会放在队列中
slowlog-max-len 1000
slowlog-log-slower-than 1000
# 后期从查看队列中有哪些慢命令，避免这些慢命令的执行
slowlog get [n] #获取慢查询队列
'''
日志由4个属性组成：
1）日志的标识id
2）发生的时间戳
3）命令耗时
4）执行的命令和参数
'''
slowlog len #获取慢查询队列长度
slowlog reset #清空慢查询队列
# slowlog-max-len 不要设置过大，默认10ms，通常设置1ms
# slowlog-log-slower-than不要设置过小，通常设置1000左右
2 pipline事务
# 事务四个特性 事务隔离级别
# redis其实不支持事务，但是可以通过pipline来实现事务
# 本质：将一批命令，批量打包，在redis服务端批量计算(执行)，然后把结果批量返回，
# execute才真正执行
# pipeline每次只能作用在一个Redis的节点上 (单台redis实例做，集群，没有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() # 这句话命令才真执行
3 发布订阅
发布订阅：观察者模式 ，只要订阅了你，你变化，我就能收到
# 发布消息
publish 频道名 "hello world"
publish souhu:tv "hello world" #在souhu:tv频道发布一条hello world 返回订阅者个数
# 订阅消息
subscribe souhu:tv #订阅sohu:tv频道
# 取消订阅
unsubscribe [channel] #取消订阅一个或多个频道
4 位图
# 本质就是字符串，直接操作比特位
setbit
getbit
bitcount 统计1的个数，按字节 一个字节8个比特位
# 独立用户统计：
int8 int16 int64
2的七次方-1 2的16次方-1 2的63次方-1
4个byte
# 总结
1 位图类型是string类型，最大512M
2 使用setbit时偏移量如果过大，会有较大消耗
3 位图不是绝对好用，需要合理使用，数量上千万级别可以使用
redis key值有没有大小限制
我们没有超过最大限制，但是他应该是有
5 HyperLogLog
# 超小内存去重，极小的空间完成独立数量统计
pfadd uuids "uuid1" "uuid2" "uuid3" "uuid4" #向uuids中添加4个uuid
pfcount uuids #返回4
# 只能统计个数，不能取出原来的值，只能能做统计和去重
# 优点：占内存很小
# 相对应的：布隆过滤器，去重 （超小内存去重） 白名单黑名单用到布隆过滤器
通过哈希函数开设一个数组，所有数据全部置为0，一个元素过来时，通过哈希函数得到不同的哈希值，找到对应的数组下表 并变为1，
查找时 通盈通过哈希函数求值，再去寻找对应下标，如果都是1 那么你就在，如果有一个不是1那么你就不在
但是，人无完人，他也有缺陷，有错误率，错误率大小取决于数组的位数和哈希函数的个数
https://www.cnblogs.com/xiaoyuanqujing/protected/articles/11969224.html
https://www.cnblogs.com/xiaoyuanqujing/protected/articles/11969232.html
示例一 不知道长度
#ScalableBloomFilter 可以自动扩容
from pybloom_live import ScalableBloomFilter
#指定错误率
bloom = ScalableBloomFilter(initial_capacity=100, error_rate=0.001, mode=ScalableBloomFilter.LARGE_SET_GROWTH)
url = "www.cnblogs.com"
url2 = "www.liuqingzheng.top"
bloom.add(url)
print(url in bloom)
print(url2 in bloom)
示例一 知道长度
#BloomFilter 是定长的
from pybloom_live import BloomFilter
#指定长度
bf = BloomFilter(capacity=1000)
url='www.baidu.com'
bf.add(url)
print(url in bf)
print("www.liuqingzheng.top" in bf)
# 动态链接库
dll文件
so文件
c---》exe
# python之间调用动态链接库
6 GEO
#地理信息定位
geoadd cities:locations 116.28 39.55 beijing #把北京地理信息添加到cities:locations中
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
# geopos cities:locations beijing #获取北京地理信息
# geodist cities:locations beijing tianjin km #北京到天津的距离，89公里
# georadiusbymember cities:locations beijing 150 km
# geo本质时zset类型
# 可以使用zset的删除，删除指定member：zrem cities:locations beijing
7 两种持久化方案
# 啥是持久化
redis的所有数据保存在内存中，对数据的更新将异步的保存到硬盘上
# 两种持久化方案
快照：某时某刻数据的一个完成备份，
-mysql的Dump
-redis的RDB
写日志：任何操作记录日志，要恢复数据，只要把日志重新走一遍即可
-mysql的 Binlog
-Redis的 AOF
# 三种：混合持久化（rdb+aof）
# RDB方案 耗时耗性能，不可控，可能会丢失数据
-方式一：客户端敲：save 同步操作，阻塞其他命令的执行
-方式二:客户端敲：bgsave 异步操作
-方式三：配置文件，一旦触发这个条件，执行bgsave
save 900 1
save 300 10
save 60 10000
如果60s中改变了1w条数据，自动生成rdb
如果300s中改变了10条数据，自动生成rdb
如果900s中改变了1条数据，自动生成rdb
# rdb最佳配置方案
#最佳配置
save 900 1
save 300 10
save 60 10000
dbfilename dump-6379.rdb #以端口号作为文件名，可能一台机器上很多reids，不会乱
dir /bigdiskpath #保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes #出现错误停止
rdbcompression yes #压缩
rdbchecksum yes #校验
# ### AOF方案
#客户端每写入一条命令，都记录一条日志，放到日志文件中，如果出现宕机，可以将数据完全恢复
# AOF的三种策略 本质就是三个参数 优缺点看下面图片
always：redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件
everysec（默认值）：redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件
no:redis——》写命令刷新的缓冲区—》操作系统决定，缓冲区fsync到硬盘–》AOF文件
# AOF重写
本质就是把过期的，无用的，重复的，可以优化的命令，来优化
这样可以减少磁盘占用量，加速恢复速度
## 如果从客户端链接：只需要在客户端敲：bgrewriteaof 命令，触发aof重写
## 最佳配置，都在配置文件中写
appendonly yes #将该选项设置为yes，打开
appendfilename "appendonly.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
no-appendfsync-on-rewrite yes #在aof重写的时候，是否要做aof的append操作，因为aof重写消耗性能，磁盘消耗，正常aof写磁盘有一定的冲突，这段期间的数据，允许丢失
auto-aof-rewrite-min-size 100 #文件尺寸
auto-aof-rewrite-percentage 10 #文件增长率
#
8 主从搭建
# 一旦搭建好主从，从库不能再写入数据
# 原理
1. 副本库通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的
# 主库是否要开启持久化
-如果不开有可能，主库重启操作，造成所有主从数据丢失！
# 方式一 ：从库敲命令
从库敲：slaveof 127.0.0.1 6379
主库或者从库敲 info 查看主从信息
slaveof no one
#方式二：配置文件
# 在从库上配置
slaveof 127.0.0.1 6379
slave-read-only yes
