Redis高级用法
第一章 redis初识
1.1 Redis是什么
介绍
开源:早起版本2w3千行
基于键值对的存储系统:字典形式
多种数据结构:字符串,hash,列表,集合,有序集合
高性能,功能丰富
github,twitter,stackoverflow,阿里,百度,微博,美团,搜狐
1.2 Redis特性(8个)
速度快:10w ops(每秒10w读写),数据存在内存中,c语言实现,单线程模型
持久化:rdb和aof
多种数据结构:
5大数据结构
BitMaps位图:布隆过滤器 本质是 字符串
HyperLogLog:超小内存唯一值计数,12kb HyperLogLog 本质是 字符串
GEO:地理信息定位 本质是有序集合
支持多种编程语言:基于tcp通信协议,各大编程语言都支持
功能丰富:发布订阅(消息) Lua脚本,事务(pipeline)
简单:源代码几万行,不依赖外部库
主从复制:主服务器和从服务器,主服务器可以同步到从服务器中
高可用和分布式:
2.8版本以后使用redis-sentinel支持高可用
3.0版本以后支持分布式
###1.3 Redis单机安装 ####1.3.1下载安装 #下载 wget http://download.redis.io/releases/redis-5.0.7.tar.gz #解压 tar -xzf redis-5.0.7.tar.gz #建立软连接 ln -s redis-5.0.7 redis cd redis make&&make install #在src目录下可以看到 #redis-server--->redis服务器 #redis-cli---》redis命令行客户端 #redis-benchmark---》redis性能测试工具 #redis-check-aof--->aof文件修复工具 #redis-check-dump---》rdb文件检查工具 #redis-sentinel---》sentinel服务器,哨兵 #redis作者对windows维护不好,window自己有安装包
1.3.2三种启动方式
1.3.2.1 最简启动
#最简启动 redis-server ps -ef|grep redis #查看进程 netstat -antpl|grep redis #查看端口 redis-cli -h ip -p port ping #命令查看
1.3.2.2 动态参数启动
#动态参数启动 redis-serve --port 6380 #启动,监听6380端口
1.3.2.2 配置文件启动
#配置文件启动(6379对应手机按键MERZ,意大利女歌手Alessia Merz的名字) #####通过redis-cli连接,输入config get * 可以获得默认配置 #在redis目录下创建config目录,copy一个redis.conf文件 #daemonize--》是否是守护进程启动(no|yes) #port---》端口号 #logfile--》redis系统日志 #dir--》redis工作目录
配置文件
#查看一下默认注释,把#和空格去掉 cat redis.conf|grep -v "#" |grep -v "^$" #重定向到另一个文件 cat redis.conf|grep -v "#" |grep -v "^$" >redis-6382.conf ''' daemonize no #是否以守护进程启动 pidfile /var/run/redis.pid #进程号的位置,删除 port 6379 #端口号 dir "opt/soft/redis/data" #工作目录 logfile “6379.log” #日志位置 #其他全删掉 ''' #在redis目录下新建data目录,用来存放书籍 #启动redis redis-server config/redis.conf #查看进程 ps -ef |grep redis-server |grep 6379 #查看日志 cd data cat 6379.log
1.3.3 客户端连接
###客户端连接### redis-cli -h 127.0.0.1 -p 6379 ping #返回PONG
1.3.4 redis返回值
####redis返回值 状态回复:ping---》PONG 错误回复:hget hello field ---》(error)WRONGTYPE Operation against 整数回复:incr hello---》(integer) 1 字符串回复:get hello---》"world" 多行字符串回复:mget hello foo---》"world" "bar"
1.4 Redis典型使用场景
缓存系统:
计数器:网站访问量,转发量,评论数
消息队列:发布订阅,阻塞队列实现
排行榜:有序集合
社交网络:很多特性跟社交网络匹配,粉丝数,关注数
实时系统:垃圾邮件处理系统,布隆过滤器
redis高级
1.1 生命周期
我们配置一个时间,如果查询时间超过了我们设置的时间,我们就认为这是一个慢查询.
慢查询发生在第三阶段
客户端超时不一定慢查询,但慢查询是客户端超时的一个可能因素
1.2 两个配置
1.2.1 slowlog-max-len
慢查询是一个先进先出的队列
固定长度
保存在内存中
1.2.2 slowlog-max-len
慢查询阈值(单位:微秒)
slowlog-log-slower-than=0,记录所有命令
slowlog-log-slower-than <0,不记录任何命令
1.2.3 配置方法
1 默认配置
config get slowlog-max-len=128
Config get slowly-log-slower-than=10000
2 修改配置文件重启
3 动态配置
# 设置记录所有命令 config set slowlog-log-slower-than 0 # 最多记录100条 config set slowlog-max-len 100 # 持久化到本地配置文件 config rewrite ''' config set slowlog-max-len 1000 config set slowlog-log-slower-than 1000 '''
1.3 三个命令
slowlog get [n] #获取慢查询队列 ''' 日志由4个属性组成: 1)日志的标识id 2)发生的时间戳 3)命令耗时 4)执行的命令和参数 ''' slowlog len #获取慢查询队列长度 slowlog reset #清空慢查询队列
1.4 经验
1 slowlog-max-len 不要设置过大,默认10ms,通常设置1ms
2 slowlog-log-slower-than不要设置过小,通常设置1000左右
3 理解命令生命周期
4 定期持久化慢查询
二 pipeline
2.1 什么是pipeline(管道)
Redis的pipeline(管道)功能在命令行中没有,但redis是支持pipeline的,而且在各个语言版的client中都有相应的实现
将一批命令,批量打包,在redis服务端批量计算(执行),然后把结果批量返回
1次pipeline(n条命令)=1次网络时间+n次命令时间
pipeline期间将“独占”链接,此期间将不能进行非“管道”类型的其他操作,直到pipeline关闭;如果你的pipeline的指令集很庞大,为了不干扰链接中的其他操作,你可以为pipeline操作新建Client链接,让pipeline和其他正常操作分离在2个client中。不过pipeline事实上所能容忍的操作个数,和socket-output缓冲区大小/返回结果的数据尺寸都有很大的关系;同时也意味着每个redis-server同时所能支撑的pipeline链接的个数,也是有限的,这将受限于server的物理内存或网络接口的缓冲能力
2.2 客户端实现
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()
2.3 与原生操作对比
通过pipeline提交的多次命令,在服务端执行的时候,可能会被拆成多次执行,而mget等操作,是一次性执行的,所以,pipeline执行的命令并非原子性的
2.4 使用建议
1 注意每次pipeline携带的数据量
2 pipeline每次只能作用在一个Redis的节点上
3 M(mset,mget....)操作和pipeline的区别
三 发布订阅
3.1 角色
发布者/订阅者/频道
发布者发布了消息,所有的订阅者都可以收到,就是生产者消费者模型(后订阅了,无法获取历史消息)
3.2 模型
3.3 API
publish channel message #发布命令 publish souhu:tv "hello world" #在souhu:tv频道发布一条hello world 返回订阅者个数 subscribe [channel] #订阅命令,可以订阅一个或多个 subscribe sohu:tv #订阅sohu:tv频道 unsubscribe [channel] #取消订阅一个或多个频道 unsubscribe sohu:tv #取消订阅sohu:tv频道 psubscribe [pattern...] #订阅模式匹配 psubscribe c* #订阅以c开头的频道 unpsubscribe [pattern...] #按模式退订指定频道 pubsub channels #列出至少有一个订阅者的频道,列出活跃的频道 pubsub numsub [channel...] #列出给定频道的订阅者数量 pubsub numpat #列出被订阅模式的数量
3.4 发布订阅和消息队列
发布订阅数全收到,消息队列有个抢的过程,只有一个抢到
四 Bitmap位图
4.1 位图是什么
下面是字符串big对应的二进制(b是98)
4.2 相关命令
set hello big #放入key位hello 值为big的字符串 getbit hello 0 #取位图的第0个位置,返回0 getbit hello 1 #取位图的第1个位置,返回1 如上图 ##我们可以直接操纵位 setbit key offset value #给位图指定索引设置值 setbit hello 7 1 #把hello的第7个位置设为1 这样,big就变成了cig setbit test 50 1 #test不存在,在key为test的value的第50位设为1,那其他位都以0补 bitcount key [start end] #获取位图指定范围(start到end,单位为字节,注意按字节一个字节8个bit为,如果不指定就是获取全部)位值为1的个数 bitop op destkey key [key...] #做多个Bitmap的and(交集)/or(并集)/not(非)/xor(异或),操作并将结果保存在destkey中 bitop and after_lqz lqz lqz2 #把lqz和lqz2按位与操作,放到after_lqz中 bitpos key targetBit start end #计算位图指定范围(start到end,单位为字节,如果不指定是获取全部)第一个偏移量对应的值等于targetBit的位置 bitpos lqz 1 #big 对应位图中第一个1的位置,在第二个位置上,由于从0开始返回1 bitpos lqz 0 #big 对应位图中第一个0的位置,在第一个位置上,由于从0开始返回0 bitpos lqz 1 1 2 #返回9:返回从第一个字节到第二个字节之间 第一个1的位置,看上图,为9
4.3 独立用户统计
1 使用set和Bitmap对比
2 1亿用户,5千万独立(1亿用户量,约5千万人访问,统计活跃用户数量)
数据类型 | 每个userid占用空间 | 需要存储用户量 | 全部内存量 |
---|---|---|---|
set | 32位(假设userid是整形,占32位) | 5千万 | 32位*5千万=200MB |
bitmap | 1位 | 1亿 | 1位*1亿=12.5MB |
假设有10万独立用户,使用位图还是占用12.5mb,使用set需要32位*1万=4MB
4.5 总结
1 位图类型是string类型,最大512M
2 使用setbit时偏移量如果过大,会有较大消耗
3 位图不是绝对好用,需要合理使用
五 HyperLogLog
5.1 介绍
基于HyperLogLog算法:绩效的空间完成独立数量统计
本质还是字符串
5.2 三个命令
pfadd key element #向hyperloglog添加元素,可以同时添加多个 pfcount key #计算hyperloglog的独立总数 pfmerge destroy sourcekey1 sourcekey2#合并多个hyperloglog,把sourcekey1和sourcekey2合并为destroy pfadd uuids "uuid1" "uuid2" "uuid3" "uuid4" #向uuids中添加4个uuid pfcount uuids #返回4 pfadd uuids "uuid1" "uuid5"#有一个之前存在了,其实只把uuid5添加了 pfcount uuids #返回5 pfadd uuids1 "uuid1" "uuid2" "uuid3" "uuid4" pfadd uuids2 "uuid3" "uuid4" "uuid5" "uuid6" pfmerge uuidsall uuids1 uuids2 #合并 pfcount uuidsall #统计个数 返回6
5.3 内存消耗&总结
百万级别独立用户统计,百万条数据只占15k
错误率 0.81%
无法取出单条数据,只能统计个数
六 GEO
6.1 介绍
GEO(地理信息定位):存储经纬度,计算两地距离,范围等
北京:116.28,39.55
天津:117.12,39.08
可以计算天津到北京的距离,天津周围50km的城市,外卖等
6.2 5个城市纬度
城市 | 经度 | 纬度 | 简称 |
---|---|---|---|
北京 | 116.28 | 39.55 | beijing |
天津 | 117.12 | 39.08 | tianjin |
石家庄 | 114.29 | 38.02 | shijiazhuang |
唐山 | 118.01 | 39.38 | tangshan |
保定 | 115.29 | 38.51 | baoding |
6.3 相关命令
geoadd key longitude latitude member #增加地理位置信息 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 key member #获取地理位置信息 geopos cities:locations beijing #获取北京地理信息 geodist key member1 member2 [unit]#获取两个地理位置的距离 unit:m(米) km(千米) mi(英里) ft(尺) geodist cities:locations beijing tianjin km #北京到天津的距离,89公里 georadius key logitude latitude radiusm|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key][storedist key] georadiusbymember key member radiusm|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key][storedist key] #获取指定位置范围内的地理位置信息集合 ''' withcoord:返回结果中包含经纬度 withdist:返回结果中包含距离中心节点位置 withhash:返回解雇中包含geohash COUNT count:指定返回结果的数量 asc|desc:返回结果按照距离中心店的距离做升序/降序排列 store key:将返回结果的地理位置信息保存到指定键 storedist key:将返回结果距离中心点的距离保存到指定键 ''' georadiusbymember cities:locations beijing 150 km ''' 1) "beijing" 2) "tianjin" 3) "tangshan" 4) "baoding" '''
6.4 总结
geo本质时zset类型
可以使用zset的删除,删除指定member:zrem
geoadd key longitude latitude member #增加地理位置信息 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 key member #获取地理位置信息 geopos cities:locations beijing #获取北京地理信息 geodist key member1 member2 [unit]#获取两个地理位置的距离 unit:m(米) km(千米) mi(英里) ft(尺) geodist cities:locations beijing tianjin km #北京到天津的距离,89公里 georadius key logitude latitude radiusm|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key][storedist key] georadiusbymember key member radiusm|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key][storedist key] #获取指定位置范围内的地理位置信息集合 ''' withcoord:返回结果中包含经纬度 withdist:返回结果中包含距离中心节点位置 withhash:返回解雇中包含geohash COUNT count:指定返回结果的数量 asc|desc:返回结果按照距离中心店的距离做升序/降序排列 store key:将返回结果的地理位置信息保存到指定键 storedist key:将返回结果距离中心点的距离保存到指定键 ''' georadiusbymember cities:locations beijing 150 km ''' 1) "beijing" 2) "tianjin" 3) "tangshan" 4) "baoding" '''
6.4 总结
3.2以后版本才有
geo本质时zset类型
可以使用zset的删除,删除指定member:zrem cities:locations beijing
geoadd key longitude latitude member #增加地理位置信息 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 key member #获取地理位置信息 geopos cities:locations beijing #获取北京地理信息 geodist key member1 member2 [unit]#获取两个地理位置的距离 unit:m(米) km(千米) mi(英里) ft(尺) geodist cities:locations beijing tianjin km #北京到天津的距离,89公里 georadius key logitude latitude radiusm|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key][storedist key] georadiusbymember key member radiusm|km|ft|mi [withcoord] [withdist] [withhash] [COUNT count] [asc|desc] [store key][storedist key] #获取指定位置范围内的地理位置信息集合 ''' withcoord:返回结果中包含经纬度 withdist:返回结果中包含距离中心节点位置 withhash:返回解雇中包含geohash COUNT count:指定返回结果的数量 asc|desc:返回结果按照距离中心店的距离做升序/降序排列 store key:将返回结果的地理位置信息保存到指定键 storedist key:将返回结果距离中心点的距离保存到指定键 ''' georadiusbymember cities:locations beijing 150 km ''' 1) "beijing" 2) "tianjin" 3) "tangshan" 4) "baoding" '''
redis持久化
1.1 什么是持久化
redis的所有数据保存在内存中,对数据的更新将异步的保存到硬盘上
1.2 持久化的实现方式
快照:某时某刻数据的一个完成备份,
-mysql的Dump
-redis的RDB
写日志:任何操作记录日志,要恢复数据,只要把日志重新走一遍即可
-mysql的 Binlog
-Hhase的 HLog
-Redis的 AOF
二 RDB
2.1 什么是RDB
2.2 触发机制-主要三种方式
''' save(同步) 1 客户端执行save命令----》redis服务端----》同步创建RDB二进制文件 2 会造成redis的阻塞(数据量非常大的时候) 3 文件策略:如果老的RDB存在,会替换老的 4 复杂度 o(n) ''' ''' bgsave(异步,Backgroud saving started) 1 客户端执行save命令----》redis服务端----》异步创建RDB二进制文件(fork函数生成一个子进程(fork会阻塞reids),执行createRDB,执行成功,返回给reids消息) 2 此时访问redis,会正常响应客户端 3 文件策略:跟save相同,如果老的RDB存在,会替换老的 4 复杂度 o(n) ''' ''' 自动(通过配置) 配置 seconds changes save 900 1 save 300 10 save 60 10000 如果60s中改变了1w条数据,自动生成rdb 如果300s中改变了10条数据,自动生成rdb 如果900s中改变了1条数据,自动生成rdb 以上三条符合任意一条,就自动生成rdb,内部使用bgsave ''' #配置: save 900 1 #配置一条 save 300 10 #配置一条 save 60 10000 #配置一条 dbfilename dump.rdb #rdb文件的名字,默认为dump.rdb dir ./ #rdb文件存在当前目录 stop-writes-on-bgsave-error yes #如果bgsave出现错误,是否停止写入,默认为yes rdbcompression yes #采用压缩格式 rdbchecksum yes #是否对rdb文件进行校验和检验 #最佳配置 save 900 1 save 300 10 save 60 10000 dbfilename dump-${port}.rdb #以端口号作为文件名,可能一台机器上很多reids,不会乱 dir /bigdiskpath #保存路径放到一个大硬盘位置目录 stop-writes-on-bgsave-error yes #出现错误停止 rdbcompression yes #压缩 rdbchecksum yes #校验
2.3 触发机制-不容忽略的方式
1 全量复制 #没有执行save和bgsave没有添加rdb策略,还会生成rdb文件,如果开启主从复制,主会自动生成rdb
2 debug reload #debug级别的重启,不会将内存中的数据清空
3 shutdown save#关闭会出发rdb的生成
2.4 试验
三 AOF
3.1 RDB问题
耗时,耗性能:
不可控,可能会丢失数据
3.2 AOF介绍
客户端每写入一条命令,都记录一条日志,放到日志文件中,如果出现宕机,可以将数据完全恢复
3.3 AOF的三种策略
日志不是直接写到硬盘上,而是先放在缓冲区,缓冲区根据一些策略,写到硬盘上
always:redis--》写命令刷新的缓冲区---》每条命令fsync到硬盘---》AOF文件
everysec(默认值):redis——》写命令刷新的缓冲区---》每秒把缓冲区fsync到硬盘--》AOF文件
no:redis——》写命令刷新的缓冲区---》操作系统决定,缓冲区fsync到硬盘--》AOF文件
命令 | always | everysec | no |
---|---|---|---|
优点 | 不丢失数据 | 每秒一次fsync,丢失1秒数据 | 不用管 |
缺点 | IO开销大,一般的sata盘只有几百TPS | 丢1秒数据 | 不可控 |
3.4 AOF 重写
随着命令的逐步写入,并发量的变大, AOF文件会越来越大,通过AOF重写来解决该问题
原生AOF | AOF重写 |
---|---|
set hello world set hello java set hello hehe incr counter incr counter rpush mylist a rpush mylist b rpush mylist c 过期数据 |
set hello hehe set counter 2 rpush mylist a b c |
本质就是把过期的,无用的,重复的,可以优化的命令,来优化
这样可以减少磁盘占用量,加速恢复速度
实现方式
bgrewriteaof:
客户端向服务端发送bgrewriteaof命令,服务端会起一个fork进程,完成AOF重写
AOF重写配置:
配置名 | 含义 |
---|---|
auto-aof-rewrite-min-size | AOF文件重写需要尺寸 |
auto-aof-rewrite-percentage | AOF文件增长率 |
统计名 | 含义 |
---|---|
aof_current_size | AOF当前尺寸(单位:字节) |
aof_base_size | AOF上次启动和重写的尺寸(单位:字节) |
自动触发时机(两个条件同时满足):
aof_current_size>auto-aof-rewrite-min-size:当前尺寸大于重写需要尺寸
(aof_current_size-aof_base_size)/aof_base_size>auto-aof-rewrite-percentage:(增长率)当前尺寸减去上次重写的尺寸,除以上次重写的尺寸如果大于配置中的增长率
重写流程
配置
appendonly yes #将该选项设置为yes,打开 appendfilename "appendonly-${port}.aof" #文件保存的名字 appendfsync everysec #采用第二种策略 dir /bigdiskpath #存放的路径 no-appendfsync-on-rewrite yes #在aof重写的时候,是否要做aof的append操作,因为aof重写消耗性能,磁盘消耗,正常aof写磁盘有一定的冲突,这段期间的数据,允许丢失
3.5 AOF 重写演示
四 RDB和AOF的选择
4.1 rdb和aof的比较
命令 | rdb | aof |
---|---|---|
启动优先级 | 低 | 高(挂掉重启,会加载aof的数据) |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
轻重 | 重 | 轻 |
4.2 rdb最佳策略
rdb关掉,主从操作时
集中管理:按天,按小时备份数据
主从配置,从节点打开
4.3 aof最佳策略
开:缓存和存储,大部分情况都打开,
aof重写集中管理
everysec:通过每秒刷新的策略
4.4 最佳策略
小分片:每个redis的最大内存为4g
缓存或存储:根据特性,使用不通策略
时时监控硬盘,内存,负载网络等
有足够内存
本文来自博客园,作者:游走De提莫,转载请注明原文链接:https://www.cnblogs.com/Gaimo/p/12120254.html