Redis-瑞士军刀

Redis的最新优势

  • 慢查询

  • Bitmap

  • pipeline

  • HyperLoglog

  • 发布订阅

  • GEO

慢查询

生命周期

在命令执行之前都是在排队的

  • 慢查询发生在第三阶段
  • 客户端超时不一定慢查询,但是慢查询是客户端超时的一个可能因素

slowlog-max-len

  • 先进先出队列

  • 固定长度

  • 保存在内存中

slowlog-log-slower-than

  • 慢查询阈值(单位:微秒)

  • slowlog-log-slower-than=0,记录所有命令

  • slowlog-log-slower-than<0,不记录任何命令

配置方法

  • 1.默认值
config get slowlog-max-len=128
config get slowlog-log-slower-than=10000
  • 2.修改配置文件重启

  • 3.动态配置

config set slowlog-max-len 1000
config set slowlog-log-slower-than 1000

慢查询的相关命令

  • 1.slowlog get [n]:获取慢查询队列

  • 2.slowlog len:获得慢查询队列长度

  • 3.slowlog reset:清空慢查询队列

调优化相关

  • 1. slowlog-max-len不要设置过大,默认10ms
有的时候超过1ms也对我们的有影响kvs,具体根据详细的的pvps来调整。
  • 2.slowlog-log-slower-than不要设置过小,通常设置在1000左右
在我们漫长的使用过程中,最初的漫查询会随着时间,被新的慢查询替代,不便于分析。所以需要设置大一些
  • 3.理解命令的生命周期
充分的理解命令的存活时间,对慢查询的依赖可以减轻
  • 4.定期持久化慢查询
定期的持久化到其他的数据源中,有便于对其他的数据结合分析

pipeline

  • 什么是流水线

  • 与原生操作对比

  • 使用相关项

什么是流水线?

命令 N个命令 一次pipline(n个时间)
时间 n次网络+n次命令 1次网络+n次命令
数据量 1条命令 n条命令
  • Redis命令时间为微妙级别
  • pipeline每次条数他要控制网络时间

pipeline能够实现什么效果?

对于我们大量的数据访问处理,在没有pipeline的情况下会暂用大量的队列,阻塞网络队列,造成网络忙,无法处理消息。pipeline的出现将多个单一的命令,整合在一起,一次性的打包发送多个命令到服务端。有效的减少了队列等待的时间处理网络阻塞的问题。

与原生操作对比

使用相关

  • 主要每次pipeline携带的数量

  • pipline每次只能作用在一个redis节点上

  • M操作与pipeline操作的区别

发布订阅

  • 角色

  • 模型

  • API

  • 发布订阅与消息队列

角色

  • 发布者(publisher)

  • 订阅者(subscriber)

  • 频道(channel)

publish(发布命令)

API

pubilsh channel message

演示

subcribe(订阅)

API

subscribe [channel] #一个或多个

演示

unsubcribe(取消订阅)

API

unsubscribe [channel]   #一个或多个

演示

其他API

psubscibe [pattern...]      #订阅模式
punsubcribe [pattern...]        #退订指定的模式
pubsub channels     #列出至少一个订阅者的频道
pubsub numsub [channel...]      #列出给定频道的订阅者数量

消息队列

Bitmap(位图)

setbit

setbit key value    #设置一个值

getbit

getbit key offset   #获取位图指定的索引的值

bitcount

bitcount key [start end]
#获取位图指定范围(start到end,单位为字节),如果不指定就是获取全部位值为1的个数

bitop

bitop op destkey key [key....]  #做多个Bitman的and(交集)、or(并集)、not(非)、xor(异或)操作并将结果保存在destkey中

bitpos

bitpos key targetBit [start] [end]
#计算位图指定的范围(start到end,单位为字节,如果不指定就是获取全部),第一个偏移量对应的值等与TargetBit的位置

相关使用

  • type=string,最大512MB

  • 注意setbit时的偏移量,可能有较大的耗时间

  • 侧重实际生产中的使用

HyperLoglog

  • 新的数据结构

  • 三个命令

  • 内存的消耗

  • 相关使用

新的数据结构

  • 基于HyperLoglog算法:极小的空间完成独立数量的统计

  • 本质上还是字符串

提供3个API

  • pfadd key element [element…]:向hyperloglog添加元素

  • pfcount key [key…]:计算hyperloglog的独立总数

  • pfmerge destkey sourcekey [sourcekey…]:合并多个Hyperloglog

模拟百万独立用户

相关使用

  • 既然HyperLoglog这么好,那它的容错率呢?(允许0.81%的错误概率)

  • 是否需要单条的数据

GEO

用于计算地理位置信息定位的功能(存储经纬度、计算两地的距离、范围计算)

geoadd

api

geokey longitude latitude member [longitude latitude member ...]        #增加地址位置信息

例子

geopos

API

geopos key member [member...]       #获取地址位置

例子

geodist

API

geodist key member1 member2 [unit]      获取两个地理位置的距离

例子

georadius

相关说明

  • since 3.2+版本以上实现的GEO功能

  • type geokey=zset

  • 没有删除API:zrem key member

Redis-瑞士军刀》有4个想法

  1. naturally like your website however you have to test the spelling on several of your posts. Many of them are rife with spelling problems and I to find it very bothersome to inform the truth on the other hand I will surely come again again.

  2. Good ¡V I should definitely pronounce, impressed with your website. I had no trouble navigating through all the tabs as well as related info ended up being truly simple to do to access. I recently found what I hoped for before you know it at all. Quite unusual. Is likely to appreciate it for those who add forums or something, website theme . a tones way for your client to communicate. Nice task..

发表评论

电子邮件地址不会被公开。 必填项已用*标注