学习目标

１.能够独立安装redis

2.能够通过查询文档使用redis常见命令,比如set,get..

3.能够说出RDB和AOF的优缺点，从占用存储空间＼存储速度＼恢复速度＼数据安全性＼资源消耗＼启动优先级。进行对比

概念

概念：Redis (REmote DIctionary Server) 是用 C 语言开发的一个开源的高性能键值对（key-value）数据库。

特征：

数据间没有必然的关联关系
内部采用单线程机制进行工作
高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
多数据类型支持

字符串类型 string

列表类型 list

散列类型 hash

集合类型 set

有序集合类型 zset/sorted_set
支持持久化，可以进行数据灾难恢复

应用场景

为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等

即时信息查询，如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等

时效性信息控制，如验证码控制、投票控制等

分布式数据共享，如分布式集群架构中的 session 分离

消息队列

安装

在linux上安装软件前先安装下面三大件，大部分软件都依赖下列三大件

1
2
3

yum install gcc-c++
yum install -y pcre pcre-devel
yum install -y zlib zlib-devel

安装redis

# 下载安装包，如不能下载修改DNS：223.5.5.5 使用阿里的DNS服务器
wget http://download.redis.io/releases/redis-5.0.0.tar.gz 
# 解压
tar –xvf redis-5.0.0.tar.gz
# 进入解压目录，然后编译
make
# 安装
make install

启动和配置

启动服务端

格式 redis-server [–port 端口号]

1	./redis-server --port 6379

指定配置文件

1	./redis-server redis.conf # redis.conf和redis-server这里在同一个目录

启动客户端

格式redis-cli [-h host] [-p port]

1	redis-cli –h 61.129.65.248 –p 6384

服务端配置

prot 6379
# 数据存放目录
dir /redis/data

# 最大客户端连接数
# maxclents 6
# 客户端超时时间
# timeout 4000

# 日志级别
# loglevel debug|verbose|notice|warning
# 日志名
logfile "log-6379.log"

入门操作

redis支持的数据类型

字符串类型 string

列表类型 list

散列类型 hash

集合类型 set

有序集合类型 zset/sorted_set

string

基本操作

1 2	SET name value //存 GET name //取

添加/修改

1	set key value

获取

get key

删除

del key

判断性添加

1	setnx key value

添加修改多个数据

1	mset key1 value1 key2 value2 …

添加获取多个数据

1	mget key1 key2…

获取数据字符个数

1	strlen key

追加信息到原始信息后部（如果原始信息存在就追加，否则新建

1	append key value

扩展操作

设置数值数据增加指定范围的值

incr操作的数据不存在会从1开始，如果

1
2
3

incr key
incrby key increment
incrbyfloat key increment

设置数值数据减少指定范围的值

1 2	decr key decrby key increment

设置数据具有指定的生命周期

1 2	setex key seconds value psetex key milliseconds value

扩展操作注意事项

数据操作不成功的反馈与数据正常操作之间的差异

表示运行结果是否成功

(integer) 0 → false 失败

(integer) 1 → true 成功

表示运行结果值

(integer) 3 → 3 3个

(integer) 1 → 1 1个

数据未获取到时，对应的数据为（nil），等同于null
数据最大存储量：512MB
string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算
按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错

9223372036854775807（java中Long型数据最大值，Long.MAX_VALUE）

redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响

key的命名规范

格式: 表名:主键名:主键值:字段名

比如 user:uid:1:name

在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可

eg:	user:id:3506728370:fans	→	12210947
eg:	user:id:3506728370:blogs	→	6164
eg:	user:id:3506728370:focuses	→	83

hash

基本操作

添加/修改

1	hset key field value

获取

1 2	hget key field hgetall key

删除

1	hdel key field1 [field2]

设置filed，如果field已经存在则不做任何操作

1	hsetnx key field value

添加修改多个数据

1	hmset key field1 value1 field2 value2 …

获取多个数据

1	hmget key field1 field2 …

获取哈希表中字段数量

hlen key

获取哈希表中是否存在指定的字段

1	hexists key field

扩展操作

获取哈希表中所有的字段名或字段值

1 2	hkeys key hvals key

设置指定字段的数值数据增加指定范围的值

1 2	hincrby key field increment hincrbyfloat key field increment

注意事项

hash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）
每个 hash 可以存储 232 - 1 个键值对
hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用
hgetall 操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈

应用场景

需求描述

双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000 张

解决方案

以商家id作为key

将参与抢购的商品id作为field

将参与抢购的商品数量作为对应的value

抢购时使用降值的方式控制产品数量

list

数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分

需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序

list类型：保存多个数据，底层使用双向链表存储结构实现

基本操作

添加修改

1 2	lpush key value1 [value2] …… rpush key value1 [value2] ……

获取

1
2
3

lrange key start stop //start从0开始，如果全部获取start=0,stop=-1
lindex key index
llen key

获取后并删除

1 2	lpop key rpop key

扩展操作

移出指定数据

1	lrem key count value

规定时间内获取并移出数据

1
2
3

blpop key1 [key2] timeout
brpop key1 [key2] timeout
brpoplpush source destination timeout //把source中的弹到destination

注意事项

list中保存的数据都是string类型的，数据总容量是有限的，最多232 - 1 个元素(4294967295)。
list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
获取全部数据操作结束索引设置为-1
list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载

应用场景

需求描述

企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？

问题解决

依赖list的数据具有顺序的特征对信息进行管理

使用队列模型解决多路信息汇总合并的问题

使用栈模型解决最新消息的问题

set

新的存储需求：存储大量的数据，在查询方面提供更高的效率

需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询

set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的

基本操作

添加

1	sadd key member1 [member2]

获取

1	smembers key

删除

1	srem key member1 [member2]

获取集合数据总量

scard key

判断集合中是否包含指定数据

1	sismember key member

随机获取集合中指定数量的数据

1	srandmember key [count]

随机获取集合中的某个数据并将数据移出集合

1	spop key [count]

###　扩展操作

求连个集合的交集＼并集＼差集

1
2
3

sinter key1 [key2 …]
sunion key1 [key2 …]
sdiff key1 [key2 …]

求两个集合的交、并、差集并存储到指定集合中

1
2
3

sinterstore destination key1 [key2 …]
sunionstore destination key1 [key2 …]
sdiffstore destination key1 [key2 …]

将指定数据从原始集合中移动到目标集合中

1	smove source destination member

注意事项

set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份

set 虽然与hash的存储结构相同，但是无法启用hash中存储值的空间

应用场景

场景描述

黑名单

资讯类信息类网站追求高访问量，但是由于其信息的价值，往往容易被不法分子利用，通过爬虫技术，快速获取信息，个别特种行业网站信息通过爬虫获取分析后，可以转换成商业机密进行出售。例如第三方火车票、机票、酒店刷票代购软件，电商刷评论、刷好评。

同时爬虫带来的伪流量也会给经营者带来错觉，产生错误的决策，有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后，需要将此类用户进行有效的屏蔽，这就是黑名单的典型应用。

ps:不是说爬虫一定做摧毁性的工作，有些小型网站需要爬虫为其带来一些流量。

白名单

对于安全性更高的应用访问，仅仅靠黑名单是不能解决安全问题的，此时需要设定可访问的用户群体，依赖白名单做更为苛刻的访问验证。

解决方案

基于经营战略设定问题用户发现、鉴别规则

周期性更新满足规则的用户黑名单，加入set集合

用户行为信息达到后与黑名单进行比对，确认行为去向

黑名单过滤IP地址：应用于开放游客访问权限的信息源

黑名单过滤设备信息：应用于限定访问设备的信息源

黑名单过滤用户：应用于基于访问权限的信息源

实践案例

描述

使用微信的过程中，当微信接收消息后，会默认将最近接收的消息置顶，当多个好友及关注的订阅号同时发送消息时，该排序会不停的进行交替。同时还可以将重要的会话设置为置顶。一旦用户离线后，再次打开微信时，消息该按照什么样的顺序显示？

解决方案

依赖list的数据具有顺序的特征对消息进行管理，将list结构作为栈使用

对置顶与普通会话分别创建独立的list分别管理

当某个list中接收到用户消息后，将消息发送方的id从list的一侧加入list（此处设定左侧）

多个相同id发出的消息反复入栈会出现问题，在入栈之前无论是否具有当前id对应的消息，先删除对应id

推送消息时先推送置顶会话list，再推送普通会话list，推送完成的list清除所有数据

消息的数量，也就是微信用户对话数量采用计数器的思想另行记录，伴随list操作同步更新

##　通用操作

key的通用操作

key是一个字符串，通过key获取redis中保存的数据,我们可以通过一些命令对key状态＼有效性＼快速查询　进行控制。

对于key自身状态的相关操作，例如：删除，判定存在，获取类型等

对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等

对于key快速查询操作，例如：按指定策略查询key

操作

删除

del key

判断key是否存在

1	exists key

判断key对应值的类型

type key

排序

1 2	sort key alpha //alpha表示按照顺序输出 sort key alpha desc//降序

有效性

为指定key设置有效期

expire key seconds 
pexpire key milliseconds 
expireat key timestamp
pexpireat key milliseconds-timestamp

获取key的剩余有效时间，失效是负数

1 2	ttl key //单位是秒 pttl key//单位是毫秒

切换key从时效性转换为永久

1	persist key

查询所有的key

keys

查询通配符

* 匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号

db常用指令

问题描述

key是由程序员定义的

redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key

数据不区分种类、类别混杂在一起，极易出现重复或冲突

解决方案

redis为每个服务提供有16个数据库，编号从0到15

每个数据库之间的数据相互独立

命令

切换数据库

1	select num

其他指令ping,查看服务器是否通畅

ping

移动

1	move key db //把ｋｅｙ移动到其他ｄｂ

查看当前库中的数据总数

dbsize

数据清除

1 2	flushdb　//清除当前库 flushall　//全部清除

持久化

自动备份概念

持久化概念

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化持久化用于防止数据的意外丢失，确保数据安全性

持久化过程保存什么

将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

RDB持久化方案

save指令

1.配置redis.conf

[重要]设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb

1	dbfilename filename

[重要]设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

dir path

设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大

1	rdbcompression yes\|no

设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险

1	rdbchecksum yes\|no

２.使用命令添加或修改数据,然后执行save,将数据持久化到硬盘

1 2	set name jack save

原理

执行save指令时会阻塞，无法执行其他任何操作

bgsave指令

思考

数据量过大，单线程执行方式造成效率过低如何处理？

操作步骤

1.配置redis.conf

后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

1	stop-writes-on-bgsave-error yes\|no

2.手动启动后台保存操作，但不是立即执行，开启子线程执行保存数据操作，所以主线程不会阻塞

bgsave

原理

bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

自动保存

原理

设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

操作步骤，直接修改配置文件即可

1.修改配置文件redis.conf

格式　save second changes

second：监控时间范围

changes：监控key的变化量

1
2
3

save 900 1
save 300 10
save 60 10000

原理

save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的save配置启动后执行的是bgsave操作

三种区别

bgsave是主流

RDB持久化的启动方式

# 重启服务器也会持久化数据
debug reload

# 关闭服务器时保存数据
shutdown save

RDB优点

RDB是一个紧凑压缩的二进制文件，存储效率较高

RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景

RDB恢复数据的速度要比AOF快很多

应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点

RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据

bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能

Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF持久化方案(主流)

RDB弊端

存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低

大数据量下的IO性能较低

基于fork创建子进程，内存产生额外消耗

宕机带来的数据丢失风险

解决思路

不写全数据，仅记录部分数据

降低区分数据是否改变的难度，改记录数据为记录操作过程

对所有操作均进行记录，排除丢失数据的风险

概念

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

配置

修改redis.conf

# 开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no

# AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename

# AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir

# AOF写数据策略，默认为everysec，推荐使用默认
appendfsync always|everysec|no

AOF三种写入策略

always(每次）：每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。

everysec（每秒，推荐）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据数据准确性较高，性能较高，建议使用，也是默认配置

no（系统控制）：由操作系统控制每次同步到AOF文件的周期

整体过程不可控

优化

AOF重写

redis会把以上三个操作合并成一个。这个叫做重写.随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。