瑞士军刀Redis
一 功能介绍：慢查询 pipeline 发布订阅 bitmap HyperLogLog GEO
慢查询：
生命周期两点说明：
（1）慢查询发生在执行命令阶段
（2）客户端超市不一定是慢查询， 但慢查询是客户端超市的一种可能因素
两个配置：
slowlog-max-len
1.先进先出队列
2.固定长度
3.保存在内存中
slowlog-log-slower-than
1.慢查询阈值（单位：微秒）
2.slowlog-log-slower-than=0 记录所有命令
3.slowlog-log-slower-than<0 不记录任何命令
配置方法
1.默认值
config get slowlog-max-len = 128 设置 默认长度
config get slowlog-log-slower-than 设置阈值10000微秒=10毫秒
2.修改配置文件启动
3.动态配置
config get slowlog-max-len 1000 支持动态配置
config get slowlog-log-slower-than 1000 支持动态配置
慢查询命令
1.slowlog get[n] :获取慢查询队列
2.slowlog len:获取慢查询队列长度
3.slowlog reset：清空慢查询队列
慢查询运维经验
1.slow-log-max-len 不要设置过大 默认10ms 通常设置为1ms
2.slow-log-slower-than 不要设置过小 通常设置为 1000左右
3.理解命令生命周期
4.定期持久化慢查询
pipeline :流水线
1.什么是pipeline？
一次时间=一次网络时间+一次命令时间
命令时间 很小 因为redis很快 网络事件很慢 因为网络可能是内网可能是外网 跨机房 跨地区，
所以有了pipeline 来操作
一次pipeline（n条命令）=一次网络时间+n次命令时间
两点注意：
1.Redis的命令时间是微妙级别
2.Redis的每次挑输要控制（网络）。
命令传输时间例子：
光速=3*10的8次方米/秒 = 3000公里/秒
距离=1300公里
光纤传输速度 约等于 光速的2/3
一次传输时间= （1300*2）/（30000*2/3）=13毫秒
2.pipline-Jedis实现？
首先引入maven依赖 然后操作
3.使用建议
1.注意每次pipeline携带数据量
2.pipeline 每次只能作用在一个Redis节点上 （不能作用于集群上，不能作用与多个节点上）
3.M（原生操作）操作与pipeline区别
发布订阅功能： 角色 模型 API 发布订阅与消息队列
发布订阅功能 ：没有消息堆积的功能 ，就是没有获取历史的消息
角色： 发布者（publisher） 订阅者（subscriber） 频道（channel）
API： publish(发布命令) subcribe（订阅） unsbcribe(取消订阅)
public channel(频道) message
subscribe [channel] : 一个或多个
unsubscribe [channel] : 一个或多个
其他API （非常用） psubcribe punsubcribe punsub-channel pubsub-numsub
psubscribe [pattern...] ：订阅模式
punsubscribe [pattern...] ：推定指定的模式
pubsub channels ：列出至少有一个订阅者的频道
pubsub numsub [channel...] :列出给定频道的订阅者数量
发布订阅总结：
消息队列： 发布者发布消息 只有一个消息订阅者可以收到 是一种抢的模式（Redis没有实现消息队列）
1.发布订阅模式中的角色
2.重要的API
bitmap（位图）
相关API： setbit getbit bitcount bittop bitpos
setbit key offset value：给位图指定索引设置值
getbit key offset value：获取位图指定索引的值
bitcount key [start end] :获取位图指定范围（start到end，单位为字节， 如果不指定就是获取全部）
位置为1的个数。
bittop op destkey key [key ...] :做多个Bitmap的and（交集） or（并集） not（非） xor（异或）
操作并将结果保存在destkey中。
bitpos key targetbit [start end ] :计算位图指定范围（start到end，单位为字节，如果不指定就是获取全部）
第一个偏移量对应的值等于targetBit的位置
独立用户统计
1.使用set和Bitmap存储
2. 一亿用户，五千万独立对应需要的全部存储量
set： 全部存储量 = 32位*50000000 约等于 200MB
bitmap： 全部存储量 = 1位 * 100000000 = 12.5MB
如果只有10独立用户呢？
set： 全部存储量 = 32位*100000 约等于4MB
bitmap： 全部存储量 = 1位 * 100000000 约等于 12.5MB
所以总结来说 如果数据量大用bitmap 小的话 用其他的 。
bitmap（位图）使用经验
1.type = string 最大512MB 如果超过512 就可以将bitmap拆分成多个key
2.注意setbit时的偏移量可能有较大耗时 因为redis是单线程
3.bitmap（位图）不是绝对的好用 分场景的！
HyperLogLog
新的数据结构？
1.基于HyperLogLog算法：极小空间完成独立数据统计
2.本质还是字符串（string）
三个命令
1.pfadd key element [element ...] : 向hyperloglog 添加元素
2.pfcount key [key ...] :计算hyperloglog的独立总数
3.pfmerge destkey sourcekey [sourcekey ...] :合并多个hyperloglog
内存消耗（百万独立用户）
内存消耗：一天：15kb 一个月：450kb 一年：15*365约等于 5MB
所以来说相对于Bitmap来说 内存消耗更小
使用经验
1.是否能容忍错误？(错误率：0.81%)
2.是否需要单挑数据？
3.是否想要很少的内存来解决问题？
GEO（地理信息定位）
GEO是什么？
存储经纬度，计算两地距离，范围计算等
应用场景：可以做微信摇一摇 按照距离来算 周围的酒店，餐馆等
相关API： geoadd geopos geodist georadius georadiusbymember
geo key longitude latitude member(标识) [longitude latitude member ...] ：增加地理位置信息
geopos key member [member ...] :获取地理位置信息
geodist key member1 member2 [unit] :获取两个地理位置的距离 unit：m(米) km(千米) mi(英里) ft(尺)
georadius key longitude latitude radiusm ....(以下多个参数) ：获取指定经纬度范围内的地理信息集合
georadiusbymember key member radiusm ....(以下多个参数) :获取指定位置（member）范围内的地理位置信息集合
有以下参数：
withcoord：返回结果中包含经纬度
withdist ：返回结果中包含距离中心节点位置
withhash:返回结果中包含geohash
COOUNT count :指定返回结果的数量
asc|desc： 返回结果按照距离中心节点的距离做升序或者降序
store key： 将返回结果的地理位置信息保存在指定键
storedist key: 将返回结果距离中心节点的距离保存到指定键
相关说明
1. 是redis3.2+版本后提供的功能
2.type geokey = zset zeo是使用zset来实现的
3. zeo 没有删除的API 可以使用 zrem key member 来删除
网友评论