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 总结

3.2以后版本才有

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

缓存或存储：根据特性，使用不通策略

时时监控硬盘，内存，负载网络等

有足够内存