一 慢查询
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 动态配置
1 2 3 4 5 6 7 8 9 10 11
|
config set slowlog-log-slower-than 0
|
1.3 三个命令
1 2 3 4 5 6 7 8 9 10 11 12
|
slowlog get [n] ''' 日志由4个属性组成: 1)日志的标识id 2)发生的时间戳 3)命令耗时 4)执行的命令和参数 '''
slowlog len
slowlog reset
|
1.4 经验
1 2 3 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次命令时间
1
|
pipeline期间将“独占”链接,此期间将不能进行非“管道”类型的其他操作,直到pipeline关闭;如果你的pipeline的指令集很庞大,为了不干扰链接中的其他操作,你可以为pipeline操作新建Client链接,让pipeline和其他正常操作分离在2个client中。不过pipeline事实上所能容忍的操作个数,和socket-output缓冲区大小/返回结果的数据尺寸都有很大的关系;同时也意味着每个redis-server同时所能支撑的pipeline链接的个数,也是有限的,这将受限于server的物理内存或网络接口的缓冲能力
|
2.2 客户端实现
1 2 3 4 5 6 7 8 9 10 11 12 13 14
|
import redis pool = redis.ConnectionPool(host='10.211.55.4', port=6379) r = redis.Redis(connection_pool=pool)
|
2.3 与原生操作对比
1
|
通过pipeline提交的多次命令,在服务端执行的时候,可能会被拆成多次执行,而mget等操作,是一次性执行的,所以,pipeline执行的命令并非原子性的
|
2.4 使用建议
1 注意每次pipeline携带的数据量
2 pipeline每次只能作用在一个Redis的节点上
3 M(mset,mget….)操作和pipeline的区别
2.5 原生事务操作
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
|
multi
|
三 发布订阅
3.1 角色
发布者/订阅者/频道
发布者发布了消息,所有的订阅者都可以收到,就是生产者消费者模型(后订阅了,无法获取历史消息)
3.2 模型
3.3 API
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
|
publish channel message publish souhu:tv "hello world"
subscribe [channel] subscribe souhu:tv
unsubscribe [channel] unsubscribe sohu:tv
psubscribe [pattern...] psubscribe c*
unpsubscribe [pattern...]
pubsub channels
pubsub numsub [channel...]
pubsub numpat
|
3.4 发布订阅和消息队列
发布订阅数全收到,消息队列有个抢的过程,只有一个抢到
四 Bitmap位图
4.1 位图是什么
下面是字符串big对应的二进制(b是98)
4.2 相关命令
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
|
set hello big getbit hello 0 getbit hello 1
setbit key offset value setbit hello 7 1
setbit test 50 1
bitcount key [start end]
bitop op destkey key [key...] bitop and after_lqz lqz lqz2
bitpos key targetBit start end bitpos lqz 1 bitpos lqz 0 bitpos lqz 1 1 2
|
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 三个命令
1 2 3 4 5 6 7 8 9 10 11 12 13
|
pfadd key element pfcount key pfmerge destroy sourcekey1 sourcekey2
pfadd uuids "uuid1""uuid2""uuid3""uuid4" pfcount uuids pfadd uuids "uuid1""uuid5" pfcount uuids
pfadd uuids1 "uuid1""uuid2""uuid3""uuid4" pfadd uuids2 "uuid3""uuid4""uuid5""uuid6" pfmerge uuidsall uuids1 uuids2 pfcount uuidsall
|
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 相关命令
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
|
geoadd key longitude latitude member 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
geopos key member geopos cities:locations beijing
geodist key member1 member2 [unit] geodist cities:locations beijing tianjin km
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
每天逼着自己写点东西,终有一天会为自己的变化感动的。这是一个潜移默化的过程,每天坚持编编故事,自己不知不觉就会拥有故事人物的特质的。 Explicit is better than implicit.(清楚优于含糊)