Redis基础-下载安装、配置、数据类型、指令、Jedis、持久化
Redis基础
学习计划
| 1. Redis入门 | （了解） | （操作） | |
|---|---|---|---|
| 2. 数据类型 | （重点） | （操作） | （理解） |
| 3. 常用指令 | （操作） | ||
| 4. Jedis | （重点） | （操作） | |
| 5. 持久化 | （重点） | （理解） | |
| 6. 数据删除与淘汰策略 | （理解） | ||
| 7. 主从复制 | （重点） | （操作） | （理解） |
| 8. 哨兵 | （重点） | （操作） | （理解） |
| 9. Cluster集群方案 | （重点） | （操作） | （理解） |
| 10. 企业级缓存解决方案 | （重点） | （理解） | |
| 11. 性能指标监控 | （了解） |
1. Redis 入门
1.1 NoSQL概念
1.1.1 问题现象
在讲解NoSQL的概念之前呢，我们先来看一个现象：
（1）问题现象
每年到了过年期间，大家都会自觉自发的组织一场活动，叫做春运！以前我们买票都是到火车站排队，后来呢有了12306，有了他以后就更方便了，我们可以在网上买票，但是带来的问题，大家也很清楚，春节期间买票进不去，进去了刷不着票。什么原因呢，人太多了！
除了这种做铁路的，它系统做的不专业以外，还有马爸爸做的淘宝，它面临一样的问题。淘宝也崩，也是用户量太大！作为我们整个电商界的东哥来说，他第一次做图书促销的时候，也遇到了服务器崩掉的这样一个现象，原因同样是因为用户量太大！
（2）现象特征
再来看这几个现象，有两个非常相似的特征：
第一，用户比较多，海量用户
第二，高并发
这两个现象出现以后，对应的就会造成我们的服务器瘫痪。核心本质是什么呢？其实并不是我们的应用服务器，而是我们的关系型数据库。关系型数据库才是最终的罪魁祸首！
（3）造成原因
什么样的原因导致的整个系统崩掉的呢：
1.性能瓶颈：磁盘IO性能低下
关系型数据库菜存取数据的时候和读取数据的时候他要走磁盘IO。磁盘这个性能本身是比较低的。
2.扩展瓶颈：数据关系复杂，扩展性差，不便于大规模集群
我们说关系型数据库，它里面表与表之间的关系非常复杂，不知道大家能不能想象一点，就是一张表，通过它的外键关联了七八张表，这七八张表又通过她的外键，每张又关联了四五张表。你想想，查询一下，你要想拿到数据，你就要从A到B、B到C、C到D的一直这么关联下去，最终非常影响查询的效率。同时，你想扩展下，也很难!
（4）解决思路
面对这样的现象，我们要想解决怎么版呢。两方面：
一，降低磁盘IO次数，越低越好。
二，去除数据间关系，越简单越好。
降低磁盘IO次数，越低越好，怎么搞？我不用你磁盘不就行了吗？于是，内存存储的思想就提出来了，我数据不放到你磁盘里边，放内存里，这样是不是效率就高了。
第二，你的数据关系很复杂，那怎么办呢？干脆简单点，我断开你的关系，我不存关系了，我只存数据，这样不就没这事了吗？
把这两个特征一合并一起，就出来了一个新的概念：NoSQL
1.1.2 NoSQL的概念
（1）概念
NoSQL：即 Not-Only SQL（ 泛指非关系型的数据库），作为关系型数据库的补充。 作用：应对基于海量用户和海量数据前提下的数据处理问题。
他说这句话说的非常客气，什么意思呢？就是我们数据存储要用SQL，但是呢可以不仅仅用SQL，还可以用别的东西，那别的东西叫什么呢？于是他定义了一句话叫做NoSQL。这个意思就是说我们存储数据，可以不光使用SQL，我们还可以使用非SQL的这种存储方案，这就是所谓的NoSQL。
（2）特征
可扩容，可伸缩。SQL数据关系过于复杂，你扩容一下难度很高，那我们Nosql 这种的，不存关系，所以它的扩容就简单一些。
大数据量下高性能。包数据非常多的时候，它的性能高，因为你不走磁盘IO，你走的是内存，性能肯定要比磁盘IO的性能快一些。
灵活的数据模型、高可用。他设计了自己的一些数据存储格式，这样能保证效率上来说是比较高的，最后一个高可用，我们等到集群内部分再去它！
（3）常见 Nosql 数据库
目前市面上常见的Nosql产品：Redis、memcache、HBase、MongoDB
（4）应用场景-电商为例
我们以电商为例，来看一看他在这里边起到的作用。
第一类，在电商中我们的基础数据一定要存储起来，比如说商品名称，价格，生产厂商，这些都属于基础数据，这些数据放在MySQL数据库。
第二类，我们商品的附加信息，比如说，你买了一个商品评价了一下，这个评价它不属于商品本身。就像你买一个苹果，“这个苹果很好吃”就是评论，但是你能说很好吃是这个商品的属性嘛？不能这么说，那只是一个人对他的评论而已。这一类数据呢，我们放在另外一个地方，我们放到MongoDB。它也可以用来加快我们的访问，他属于NoSQL的一种。
第三，图片内的信息。注意这种信息相对来说比较固定，他有专用的存储区，我们一般用文件系统来存储。至于是不是分布式，要看你的系统的一个整个 瓶颈 了？如果说你发现你需要做分布式，那就做，不需要的话，一台主机就搞定了。
第四，搜索关键字。为了加快搜索，我们会用到一些技术，有些人可能了解过，像分ES、Lucene、solr都属于搜索技术。那说的这么热闹，我们的电商解决方案中还没出现我们的redis啊！注意第五类信息。
第五，热点信息。访问频度比较高的信息，这种东西的第二特征就是它具有波段性。换句话说他不是稳定的，它具有一个时效性的。那么这类信息放哪儿了，放到我们的redis这个解决方案中来进行存储。
我们的基础数据都存MySQL，在它的基础之上，我们把它连在一块儿，同时对外提供服务。向上走，有一些信息加载完以后，要放到我们的MongoDB中。还有一类信息，我们放到我们专用的文件系统中（比如图片），就放到我们的这个搜索专用的，如Lucene、solr及集群里边，或者用ES的这种技术里边。那么剩下来的热点信息，放到我们的redis里面。
1.2 Redis概念
1.2.1 redis概念
Redis (Remote Dictionary Server：远程词典服务器) 是用 C 语言开发的一个开源的高性能（内存型）键值对（key-value）数据库。
- 特征：
（1）数据间没有必然的关联关系；
（2）内部采用单线程机制进行工作；
（3）高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
（4）多数据类型支持
字符串类型，string list
列表类型，hash set
散列类型，zset/sorted_set
集合类型
有序集合类型
（5）支持持久化，可以进行数据灾难恢复
1.2.2 redis的应用场景
（1）为热点数据加速查询（主要场景）。如热点商品、热点新闻、热点资讯、推广类等高访问量信息等。
（2）即时信息查询。如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等。
（3）时效性信息控制。如验证码控制、投票控制等。
（4）分布式数据共享。如分布式集群架构中的 session 分离。
（5）消息队列
1.3 Redis 的下载与安装
1.3.1 Redis 的下载与安装
基于Center OS7安装Redis。
安装的时候可能还会需要安装gcc环境：所以可以参照：
http://blog.sina.com.cn/s/blog_ae829c5c0102z27v.html
（1)下载Redis
下载安装包：
wget http://download.redis.io/releases/redis-5.0.0.tar.gz
解压安装包：
tar –xvf redis-5.0.0.tar.gz
编译（在解压的目录中执行）：
make
安装（在解压的目录中执行）：
make install
1.4 Redis服务器启动
1.4.1 Redis服务器启动
启动服务器——参数启动
redis-server [--port port]
范例
redis-server --port 6379
启动服务器——配置文件启动
redis-server config_file_name
范例
redis-server redis.conf
1.4.2 Redis客户端启动
启动客户端
redis-cli [-h host] [-p port]
范例
redis-cli –h 61.129.65.248 –p 6384
注意：服务器启动指定端口使用的是–port，客户端启动指定端口使用的是-p。-的数量也不同。
1.4.3 Redis基础环境设置约定
创建配置文件存储目录
mkdir conf
创建服务器文件存储目录（包含日志、数据、临时配置文件等）
mkdir data
创建快速访问链接
ln -s redis-5.0.0 redis
1.5 配置文件启动与常用配置
1.5.1 服务器端设定
- 修改启动配置文件redis.conf/redis.windows.conf
port 127.0.0.1
daemonize yes
logfile "log-6379.log"
dir /redis/data
-
配置项介绍：
-
设置服务器以守护进程的方式运行，开启后服务器控制台中将打印服务器运行信息（同日志内容相同）
daemonize yes|no # 改为yes就是后台启动，看不到之前的欢迎信息，cmd窗口关闭也没影响 #windows版本的redis不支持后台启动，配置也没有用 -
绑定主机地址：bind ip
bind 127.0.0.1 #指定当前redis服务运行在哪个ip上（一般都指定为本机） -
设置服务器端口
port 6379 #6379是redis的默认端口 -
日志文件
logfile "日志文件名" -
设置服务器文件保存地址：dir path
dir "/redis/data" windows配置为：dir "./data"（需要在redis安装的目录新建data文件夹）
-
-
启动
#启动服务器 redis-server /redis/conf/redis-6379.conf #查看进程 ps -ef | grep redis- 配置为后台启动之后，可以通过ps查看是否启动
-
开发的时候，我们还是通过前台启动，因为查看日志方便
- 杀掉进程：kill 9 6457
- 重新配置daemonize no
- 屏蔽logfile （如果不屏蔽，日志还是会写入日志文件，不会直接在cmd窗口显示）
1.5.2 客户端配置（了解，还是redis.conf配置文件中的配置项）
服务器允许客户端连接最大数量，默认0，表示无限制。当客户端连接到达上限后，Redis会拒绝新的连接
maxclients count
客户端闲置等待最大时长，达到最大值后关闭对应连接。如需关闭该功能，设置为 0
timeout seconds
1.5.3 日志配置
设置服务器以指定日志记录级别
loglevel debug|verbose|notice|warning
日志记录文件名
logfile filename
注意：日志级别开发期设置为verbose即可，生产环境中配置为notice，简化日志输出量，降低写日志IO的频度。
1.6 Redis基本操作
1.6.1 命令行模式工具使用思考
-
功能性命令
-
帮助信息查阅
-
退出指令
-
清除屏幕信息
1.6.2 信息读写
设置 key，value 数据
set key value
范例
set name itheima
根据 key 查询对应的 value，如果不存在，返回空（nil）
get key
范例
get name
1.6.3 帮助信息
获取命令帮助文档
help [command]
范例
help set
获取组中所有命令信息名称
help [@group-name]
范例
help @string
1.6.4 退出命令行客户端模式
退出客户端
quit 或
exit
快捷键
Ctrl+C
1.6.4 redis入门总结
到这里，Redis 入门的相关知识，我们就全部学习完了，再来回顾一下，这个部分我们主要讲解了哪些内容呢？
-
首先，我们对Redis进行了一个简单介绍，包括NoSQL的概念、Redis的概念等
-
然后，我们介绍了Redis 的下载与安装。包括下载与安装、服务器与客户端启动、以及相关配置文件（3类）
-
最后，我们介绍了Redis 的基本操作。包括数据读写、退出与帮助信息获取
2. 数据类型
在这个部分，我们将学习一共要学习三大块内容：
- 首先需要了解一下数据类型
- 接下来将针对着我们要学习的数据类型进行逐一的讲解，如string、hash、list、set等
- 最后我们通过一个案例来总结前面的数据类型的使用场景
2.1 数据存储类型介绍
2.1.1 业务数据的特殊性
在讲解数据类型之前，我们得先思考一个问题，数据类型既然是用来描述数据的存储格式的，如果你不知道哪些数据未来会进入到我们来的redis中，那么对应的数据类型的选择，你就会出现问题，我们一块来看一下：
（1）原始业务功能设计
秒杀。他这个里边数据变化速度特别的快，访问量也特别的高，用户大量涌入以后都会针对着一部分数据进行操作，这一类要记住。
618活动。对于我们京东的618活动、以及天猫的双11活动，相信大家不用说都知道这些数据一定要进去，因为他们的访问频度实在太高了。
排队购票。我们12306的票务信息。这些信息在原始设计的时候，他们就注定了要进redis。
（2）运营平台监控到的突发高频访问数据
此类平台临时监控到的这些数据，比如说现在出来的一个八卦的信息，这个新闻一旦出现以后呢，顺速的被围观了，那么这个时候，这个数据就会变得访量特别高，那么这类信息也要进入进去。
（3）高频、复杂的统计数据
在线人数。比如说直播现在很火，直播里边有很多数据，例如在线人数。进一个人出一个人，这个数据就要跳动，那么这个访问速度非常的快，而且访量很高，并且它里边有一个复杂的数据统计，在这里这种信息也要进入到我们的redis中。
投票排行榜。投票投票类的信息他的变化速度也比较快，为了追求一个更快的一个即时投票的名次变化，这种数据最好也放到redis中。
2.1.2 Redis 数据类型(5种常用)
基于以上数据特征我们进行分析，最终得出来我们的Redis中要设计5种 数据类型：
string、hash、list、set、sorted_set/zset（应用性较低）
2.2 string数据类型
2.2.1Redis 数据存储格式
- 在学习string这个数据形式之前，我们先要明白string到底是修饰什么的
- 我们知道redis 自身是一个 Map，其中所有的数据都是采用 key : value 的形式存储
- 对于这种结构来说，我们用来存储数据一定是一个值前面对应一个名称，我们通过名称来访问后面的值。
- 前面这一部分我们称为key，后面的一部分称为value，而我们的数据类型，他一定是修饰value的。
- 数据类型指的是存储的数据的类型，也就是 value 部分的类型，key 部分永远都是字符串。
2.2.2 string 类型
（1）存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型。
string，他就是存一个字符串儿，注意是value那一部分是一个字符串，它是redis中最基本、最简单的存储数据的格式。
（2）存储数据的格式：一个存储空间保存一个数据
每一个空间中只能保存一个字符串信息，这个信息里边如果是存的纯数字，他也能当数字使用，我们来看一下，这是我们的数据的存储空间。
（3）存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用.
一个key对一个value，而这个itheima就是我们所说的string类型，当然它也可以是一个纯数字的格式。
2.2.3 string 类型数据的基本操作
（1）基础指令
添加/修改数据添加/修改数据
set key value
获取数据
get key
删除数据
del key
判定性添加数据 （了解）
setnx key value
#SET if Not eXists （大写组成命令）
添加/修改多个数据
mset key1 value1 key2 value2 …
#m:Multiple 多个
获取多个数据
mget key1 key2 …
获取数据字符个数（字符串长度）
strlen key
#STRing LENgth
追加信息到原始信息后部（如果原始信息存在就追加，否则新建）
append key value
2.3 string 类型数据的扩展操作
2.3.1 string 类型数据的扩展操作
下面我们来看一string的扩展操作，分成两大块：一块是对数字进行操作的，第二块是对我们的key的时间进行操作的。
设置数值数据增加指定范围的值
incr key #类似于i++
incrby key increment #相当于i+n
incrbyfloat key increment #可以操作小数
#increment 增加
设置数值数据减少指定范围的值
decr key #类似于i--
decrby key increment #相当于i-n
#decrement 减少
设置数据具有指定的生命周期 （***）
setex key seconds value ***
psetex key milliseconds value
#expire ： 有效期，期限
2.3.2 string 类型数据操作的注意事项
-
数据操作不成功的反馈与数据正常操作之间的差异
表示运行结果是否成功 ： 例如setnx
(integer) 0 → false 失败
(integer) 1 → true 成功
表示运行结果值：例如获取数据长度 strlen
(integer) 3 → 3 3个
(integer) 1 → 1 1个
-
数据未获取到时，对应的数据为（nil），等同于null
-
数据最大存储量：512MB
-
string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算
- 注意：redis虽然可以存储数字，但是数字在内部存储时依然是字符串类型
-
按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis 数值上限范围，将报错
上限是：9223372036854775807（也就是java中Long型数据最大值，Long.MAX_VALUE）
-
redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响.
2.4string应用场景与key命名约定
2.4.1 应用场景
它的应用场景在于：主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量。
我们来思考一下：这些信息是不是你进入大V的页面儿以后就要读取这写信息的啊，那这种信息一定要存储到我们的redis中，因为他的访问量太高了！那这种数据应该怎么存呢？我们来一块儿看一下方案！
2.4.2 解决方案
（1）在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可。
#eg就是例子的意思
eg: user:id:3506728370:fans → 12210947
eg: user:id:3506728370:blogs → 6164
eg: user:id:3506728370:focuses → 83
- 这个用户的id为3506728370，这个大v存储了blogs和fans俩信息，分开存储
（2）也可以使用json格式保存数据
eg: user:id:3506728370 → {“fans”：12210947，“blogs”：6164，“ focuses ”：83 }
（3） key 的设置约定
数据库中的热点数据key命名惯例：由表名：主键名：主键值：字段名，作为key名
| 表名 | 主键名 | 主键值 | 字段名 | |
|---|---|---|---|---|
| eg1： | order | id | 29437595 | name |
| eg2： | equip | id | 390472345 | type |
| eg3： | news | id | 202004150 | title |
2.5 hash的基本操作
下面我们来学习第二个数据类型hash
2.5.1 数据存储的困惑
对象类数据的存储如果具有较频繁的更新需求操作会显得笨重！
- 比如说前面我们用以上形式存了数据，如果我们用单条去存的话，它存的条数会很多。
- 但如果我们用json格式，它存一条数据就够了。
- 问题来了，假如说现在粉丝数量发生变化了，你要把整个值都改了。
- 但是用单条存的话就不存在这个问题，你只需要改其中一个就行了。
- 这个时候我们就想，有没有一种新的存储结构，能帮我们解决这个问题呢。
- 我们使用field字段来解决。
- hash的结构是：key:{field:value，field2:value2}
- 在redis中的hash的值，可以理解为是一个对象
2.5.2 hash 类型
新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
需要的存储结构：一个存储空间保存多个键值对数据
hash类型：底层使用哈希表结构实现数据存储
这种结构叫做hash，左边一个key，对右边一个存储空间。这里要明确一点，右边存储空间叫hash，也就是说hash是指的一个数据类型，他指的不是一个数据，是这里边的一堆数据，那么它底层呢，是用hash表的结构来实现的。
值得注意的是：
如果field数量较少，存储结构优化为类数组结构
如果field数量较多，存储结构使用HashMap结构
2.5.3 hash 类型数据的基本操作
添加/修改数据
hset key field value
#h：hash
获取数据
hget key field
hgetall key
删除数据
hdel key field1 [field2]
#可以删除多个field，空格分隔即可
设置field的值，如果该field存在则不做任何操作
hsetnx key field value
添加/修改多个数据
hmset key field1 value1 field2 value2 …
获取多个数据
hmget key field1 field2 …
获取哈希表中字段的数量
hlen key
获取哈希表中是否存在指定的字段
hexists key field
2.6 hash的拓展操作
2.6.1 hash 类型数据扩展操作
获取哈希表中所有的字段名或字段值
hkeys key
hvals key
设置指定字段的数值数据增加指定范围的值
hincrby key field increment
hincrbyfloat key field increment
2.6.2 hash类型数据操作的注意事项
-
（1）hash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）
-
（2）每个 hash 可以存储 （2的32次方 - 1） 个键值对
-
（3）hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计 的，切记不可滥用，更不可以将hash作为对象列表使用
-
（4）hgetall 操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈
2.7 list基本操作
- 前面我们存数据的时候呢，单个数据也能存，多个数据也能存
- 但是这里面有一个问题，我们存多个数据用hash的时候它是没有顺序的
- 我们平时操作，实际上数据很多情况下都是有顺序的，那有没有一种能够用来存储带有顺序的这种数据模型呢
- list就专门来干这事儿
2.7.1 list 类型
数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
list类型：保存多个数据，底层使用双向链表存储结构实现
- 顺序表：想要插入cnpc，需要将后边的元素都向后移动，比较麻烦
- 链表：想要插入cnpc，需要将头指针和huawei的链条断开，然后重新连接
- 链表的形式，插入挺高效，就是查询比较慢，如果要查询alibaba，就需要从头查到尾
- 双向链表：它的链条是双向的
- 想要插入cnpc，也是需要断开头指针和华为的链条，重新连接，所以插入也高效
- 但是查询也是高效的，查询可以双向查询
- 虽然查询alibaba也是从头开始查询，但是如果这时再查询tencent，就可以反向直接查询到
list对应的存储结构是什么呢？里边存的这个东西是个列表，他有一个对应的名称。
就是key存一个list的这样结构。对应的基本操作，你其实是可以想到的。
因为它是双向的，所以他左边右边都能操作，它对应的操作结构两边都能进数据。这就是链表的一个存储结构。
往外拿数据的时候怎么拿呢？通常是从一端拿，当然另一端也能拿。
如果两端都能拿的话，这就是个双端队列，两边儿都能操作。如果只能从一端进一端出，这个模型咱们前面了解过，叫做栈。
2.7.2 list 类型数据基本操作
最后看一下他的基本操作
添加/修改数据
lpush key value1 [value2] ……
rpush key value1 [value2] ……
#l：left
#r：right
获取数据：因为列表存储的数据有顺序，所以可以通过索引来获取
lrange key start stop # range：范围，查询某个范围的数据。stop如果写-1，意味着直接查询所有
lindex key index #index：索引，查询某个索引的数据
llen key
获取并移除数据：删除之后会返回被删除的数据
lpop key #左侧删除末尾数据（删除最左侧的数据）
rpop key #右侧删除末尾数据（删除最右侧的数据）
2.8 list扩展操作
2.8.1 list 类型数据扩展操作
移除指定数据：不返回删除的数据
lrem key count value
#rem remove移除
#count 可以删除多个，如果list中存储了俩a，就可以是 lrem list1 2 a
规定时间内获取并移除数据：规定时间内取数据，能取到就返回，取不到就返回nil
blpop key1 [key2] timeout
brpop key1 [key2] timeout
brpoplpush source destination timeout
#b:block：阻塞，块
2.8.2 list 类型数据操作注意事项
（1）list中保存的数据都是string类型的，数据总容量是有限的，最多 （2的32次方- 1） 个元素(4294967295)。
（2）list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
（3）获取全部数据操作结束索引设置为-1
（4）list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载
2.9 set 基本操作
2.9.1 set类型
新的存储需求：存储大量的数据，在查询方面提供更高的效率
需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
set类型：与hash存储结构完全相同，仅存储field，不存储值（存储的值都是nil），并且field是不允许重复的
2.9.2 set类型数据的基本操作
添加数据
sadd key member1 [member2]
获取全部数据
smembers key
#s:set
#members:成员，set集合中每一个元素叫做成员
删除数据
srem key member1 [member2]
获取集合数据总量
scard key
判断集合中是否包含指定数据
sismember key member
#ismember：是成员么，是集合中的成员么
随机获取集合中指定数量的数据 （了解）
srandmember key [count]
#rand：random随即
随机获取集中的某个数据并将该数据移除集合
spop key [count]
2.10 set 类型数据的扩展操作
2.10.1 set 类型数据的扩展操作
求两个集合的交、并、差集
sinter key1 [key2 …] #intersection ： 交叉，交集
sunion key1 [key2 …] # union ：联合
sdiff key1 [key2 …] # difference：不同，差别
求两个集合的交、并、差集并存储到指定集合中
sinterstore destination key1 [key2 …]
sunionstore destination key1 [key2 …]
sdiffstore destination key1 [key2 …]
# store：存储
# destination：目的
将指定数据从原始集合中移动到目标集合中
smove source destination member
#move：移动
#source：源
2.10.2 set 类型数据操作的注意事项
set 类型不允许数据重复，如果添加的数据在 set 中已经存在，将只保留一份。
set 虽然与hash的存储结构相同，但是无法启用hash中存储值的空间。
3. 常用指令
- 在这部分学习两个知识，第一个是key的常用指令，第二个是数据库的常用指令
- 和前面我们学数据类型做一下区分，前面学的那些指令都是针对某一个数据类型操作的，现在学的都是对所有的操作的
3.1 key 操作分析
3.1.1 key应该设计哪些操作？
-
key是一个字符串，通过key获取redis中保存的数据
-
对于key自身状态的相关操作，例如：删除，判定存在，获取类型等
-
对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等
-
对于key快速查询操作，例如：按指定策略查询key
3.1.2 key 基本操作
删除指定key
del key
获取key是否存在
exists key
获取key的类型
type key
3.1.3 拓展操作
排序
sort
改名
rename key newkey
renamenx key newkey
3.1.3 key 扩展操作（时效性控制）
为指定key设置有效期
expire key seconds
pexpire key milliseconds
expireat key timestamp
pexpireat key milliseconds-timestamp
获取key的有效时间
ttl key # ttl：time to live：存活时间（过期时间）
pttl key
切换key从时效性转换为永久性
persist key #persist 继续存在，坚持
3.1.4 key 扩展操作（查询模式）
查询key
keys pattern
查询模式规则
*匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号
keys * keys 查询所有
it* keys 查询所有以it开头
*heima 查询所有以heima结尾
keys ??heima 查询所有前面两个字符任意，后面以heima结尾 查询所有以
keys user:? user:开头，最后一个字符任意
keys u[st]er:1 查询所有以u开头，以er:1结尾，中间包含一个字母，s或t
3.2 数据库指令
3.2.1 key 的重复问题
在这个地方我们来讲一下数据库的常用指令，在讲这个东西之前，我们先思考一个问题：
假如说你们十个人同时操作redis，会不会出现key名字命名冲突的问题。
一定会，为什么?因为你的key是由程序而定义的。你想写什么写什么，那在使用的过程中大家都在不停的加，早晚有一天他会冲突的。
redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key。
那这个问题我们要不要解决？要！怎么解决呢？我们最好把数据进行一个分类，除了命名规范我们做统一以外，如果还能把它分开，这样是不是冲突的机率就会小一些了，这就是咱们下面要说的解决方案！
3.2.2 解决方案
redis为每个服务提供有16个数据库，编号从0到15
每个数据库之间的数据相互独立
在对应的数据库中划出一块区域，说他就是几，你就用几那块，同时，其他的这些都可以进行定义，一共是16个，这里边需要注意一点，他们这16个共用redis的内存。没有说谁大谁小，也就是说数字只是代表了一块儿区域，区域具体多大未知。这是数据库的一个分区的一个策略！
3.2.3 数据库的基本操作
切换数据库
select index
其他操作
ping
3.2.4 数据库扩展操作
数据移动
move key db
数据总量
dbsize
数据清除
flushdb # 清除当前库的数据
flushall # 清除所有库的数据
#flush:冲洗，冲掉
4. Jedis
4.1 Jedis简介
4.1.1 编程语言与redis
-
对于我们现在的数据来说，它是在我们的redis中，而最终我们是要做程序。那么程序就要和我们的redis进行连接。
-
干什么事情呢？两件事：程序中有数据的时候，我们要把这些数据全部交给redis管理。
-
同时，redis中的数据还能取出来，回到我们的应用程序中。
-
那在这个过程中，在Java与redis之间打交道的这个东西就叫做Jedis.
-
简单说，Jedis就是提供了Java与redis的连接服务的，里边有各种各样的API接口，你可以去调用它。
-
除了Jedis外，还有没有其他的这种连接服务呢？其实还有很多，了解一下：
-
Java语言连接redis服务 Jedis（SpringData、Redis 、 Lettuce）
-
其它语言：C 、C++ 、C# 、Erlang、Lua 、Objective-C 、Perl 、PHP 、Python 、Ruby 、Scala
4.1.2 准备工作
(1)jar包导入：
下载地址：https://mvnrepository.com/artifact/redis.clients/jedis
(2)客户端连接redis
连接redis
Jedis jedis = new Jedis("localhost", 6379);
操作redis
jedis.set("name", "itheima"); jedis.get("name");
关闭redis连接
jedis.close();
4.1.3 代码实现
创建：com.lichee.JedisTest
public class JedisTest {
public static void main(String[] args) {
//1.获取连接对象
Jedis jedis = new Jedis("127.0.0.1",6379);
//2.执行操作
jedis.set("age","39"); // jedis提供的方法与redis命令基本一致
String hello = jedis.get("hello");
System.out.println(hello);
jedis.lpush("list1","a","b","c","d");
List<String> list1 = jedis.lrange("list1", 0, -1);
for (String s:list1 ) {
System.out.println(s);
}
jedis.sadd("set1","abc","abc","def","poi","cba");
Long len = jedis.scard("set1");
System.out.println(len);
//3.关闭连接
jedis.close();
}
}
报ConnectException异常：
修改配置文件bind为虚拟机真实ip
bind 192.168.40.130
port 6379
logfile "log-6379.log"
dir /redis/data
修改程序
Jedis jedis = new Jedis("192.168.40.130",6379); //ip需要为redis服务所在的真实ip
4.2 Jedis简易工具类开发
前面做的程序还是有点儿小问题，就是我们的Jedis对象的管理是我们自己创建的，真实企业开发中是不可能让你去new一个的，那接下来咱们就要做一个工具类，简单来说，就是做一个创建Jedis的这样的一个工具。
4.2.1 基于连接池获取连接
JedisPool：Jedis提供的连接池技术
poolConfig:连接池配置对象
host:redis服务地址
port:redis服务端口号
JedisPool的构造器如下：（源码）
public JedisPool(GenericObjectPoolConfig poolConfig, String host, int port) {
this(poolConfig, host, port, 2000, (String)null, 0, (String)null);
}
4.2.2 封装连接参数
创建jedis的配置文件：jedis.properties
jedis.host=192.168.40.130
jedis.port=6379
jedis.maxTotal=50 #控制一个pool可分配多少个jedis实例
jedis.maxIdle=10 #控制一个pool最多有多少个状态为idle(空闲的)的jedis实例
# 就是说如果没人用jedis，那么这个池子里就只有10个jedis实例
# 如果用的人非常多，但是不会超过50个
4.2.3 加载配置信息
创建JedisUtils：com.lichee.util.JedisUtils，使用静态代码块初始化资源
public class JedisUtils {
private static int maxTotal;
private static int maxIdel;
private static String host;
private static int port;
private static JedisPoolConfig jpc;
private static JedisPool jp;
static {
ResourceBundle bundle = ResourceBundle.getBundle("redis");
maxTotal = Integer.parseInt(bundle.getString("redis.maxTotal"));
maxIdel = Integer.parseInt(bundle.getString("redis.maxIdel"));
host = bundle.getString("redis.host");
port = Integer.parseInt(bundle.getString("redis.port"));
//Jedis连接池配置
jpc = new JedisPoolConfig();
jpc.setMaxTotal(maxTotal);
jpc.setMaxIdle(maxIdel);
jp = new JedisPool(jpc,host,port);
}
}
4.2.4 获取连接
对外访问接口，提供jedis连接对象，连接从连接池获取，在JedisUtils中添加一个获取jedis的方法：getJedis
public static Jedis getJedis(){
Jedis jedis = jedisPool.getResource();
return jedis;
}
测试类：使用连接池
public class JedisTest {
public static void main(String[] args) {
//1.获取连接对象
// Jedis jedis = new Jedis("192.168.40.130",6379);
Jedis jedis = JedisUtils.getJedis();
//2.执行操作
// jedis.set("age","39");
// String hello = jedis.get("hello");
// System.out.println(hello);
// jedis.lpush("list1","a","b","c","d");
// List list1 = jedis.lrange("list1", 0, -1);
// for (String s:list1 ) {
// System.out.println(s);
// }
jedis.sadd("set1","abc","abc","def","poi","cba");
Long len = jedis.scard("set1");
System.out.println(len);
//3.关闭连接
jedis.close();
}
}
5. 持久化
5.1 持久化简介
5.1.1 场景-意外断电
- 不知道大家有没有遇见过，就是正工作的时候停电了，如果你用的是笔记本电脑还好，你有电池
- 但如果你用的是台式机呢，那恐怕就比较灾难了
- 假如你现在正在写一个比较重要的文档，如果你要使用的是word，这种办公自动化软件的话，他一旦遇到停电，其实你不用担心，因为它会给你生成一些其他的文件
我们说自动恢复，其实基于的一个前提就是他提前把你的数据给存起来了。你平常操作的所有信息都是在内存中的，而我们真正的信息是保存在硬盘中的，内存中的信息断电以后就消失了，硬盘中的信息断电以后还可以保留下来！
我们将文件由内存中保存到硬盘中的这个过程，我们叫做数据保存，也就叫做持久化。
但是把它保存下来不是你的目的，最终你还要把它再读取出来，它加载到内存中这个过程，我们叫做数据恢复，
这就是我们所说的word为什么断电以后还能够给你保留文件，因为它执行了一个自动备份的过程，也就是通过自动的形式，把你的数据存储起来，那么有了这种形式以后，我们的数据就可以由内存到硬盘上实现保存。
5.1.2 什么是持久化
(1)什么是持久化
利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化 。
持久化用于防止数据的意外丢失，确保数据安全性。
(2)持久化过程保存什么？
我们知道一点，计算机中的数据全部都是二进制，如果现在我要你给我保存一组数据的话，你有什么样的方式呢，其实最简单的就是现在长什么样，我就记下来就行了，那么这种是记录纯粹的数据，也叫做快照存储，也就是它保存的是某一时刻的数据状态。
还有一种形式，它不记录你的数据，它记录你所有的操作过程，比如说大家用idea的时候，有没有遇到过写错了ctrl+z撤销，然后ctrl+y还能恢复，这个地方它也是在记录，但是记录的是你所有的操作过程，那我想问一下，操作过程，我都给你留下来了，你说数据还会丢吗？肯定不会丢，因为你所有的操作过程我都保存了。这种保存操作过程的存储，用专业术语来说可以说是日志，这是两种不同的保存数据的形式啊。
总结一下：
第一种：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。
第二种：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。
5.2 RDB
5.2.1 save指令
手动执行一次保存操作
save
save指令相关配置
设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb
dbfilename filename
设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data
dir path
设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大
rdbcompression yes|no
设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险
rdbchecksum yes|no
5.2.2 bgsave指令
之前我们讲到了当save指令的数据量过大时，单线程执行方式造成效率过低，那应该如何处理？
此时我们可以使用：bgsave指令，bg其实是background的意思，后台执行的意思
手动启动后台保存操作，但不是立即执行
bgsave
bgsave指令相关配置
后台存储过程中如果出现错误现象，是否停止保存操作，默认yes
stop-writes-on-bgsave-error yes|no
bgsave指令工作原理
- 当执行bgsave的时候，客户端发出bgsave指令给到redis服务器。
- 注意，这个时候服务器马上回一个结果告诉客户端后台已经开始了，与此同时它会创建一个子进程，使用Linux的fork（分叉）函数创建一个子进程，让这个子进程去执行save相关的操作
- 此时我们可以想一下，我们主进程一直在处理指令，而子进程在执行后台的保存，它会不会干扰到主进程的执行吗？
- 答案是不会，所以说他才是主流方案。
- 子进程开始执行之后，它就会创建啊RDB文件把它存起来，操作完以后他会把这个结果返回，也就是说bgsave的过程分成两个过程，
- 第一个是服务端拿到指令直接告诉客户端开始执行了；
- 另外一个过程是一个子进程在完成后台的保存操作，操作完以后回一个消息。
5.2.3 save配置自动执行
设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化
save second changes
参数
second：监控时间范围
changes：监控key的变化量
范例：
save 900 1 #900s之内只有有1个key发生改变，就会保存
save 300 10
save 60 10000
5.2.4 RDB三种启动方式对比
| 方式 | save指令 | bgsave指令 |
|---|---|---|
| 读写 | 同步 | 异步 |
| 阻塞客户端指令 | 是 | 否 |
| 额外内存消耗 | 否 | 是 |
| 启动新进程 | 否 | 是 |
RDB特殊启动形式
之前已经介绍了三种，还有三种了解一下即可：
服务器运行过程中重启
debug reload
关闭服务器时指定保存数据
shutdown save
全量复制（在主从复制中详细讲解）
RDB优点：
- RDB是一个紧凑压缩的二进制文件，存储效率较高
- RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
- RDB恢复数据的速度要比AOF快很多
- 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
RDB缺点
- RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
- bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
- Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象
5.3 AOF
为什么要有AOF,这得从RDB的存储的弊端说起：
- 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程，内存产生额外消耗
- 宕机带来的数据丢失风险
那解决的思路是什么呢？
- 不写全数据，仅记录部分数据
- 降低区分数据是否改变的难度，改记录数据为记录操作过程
- 对所有操作均进行记录，排除丢失数据的风险
5.3.1 AOF概念
AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
启动AOF相关配置
开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no
AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename
AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir
AOF写数据策略，默认为everysec
appendfsync always|everysec|no
5.3.2 AOF执行策略
AOF写数据三种策略(appendfsync)
-
always(每次）：每次写入操作均同步到AOF文件中数据零误差，性能较低，不建议使用。
-
everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高，性能较高，建议使用，也是默认配置
-
no（系统控制）：由操作系统控制每次同步到AOF文件的周期，整体过程不可控
5.3.3 AOF重写
场景：AOF写数据遇到的问题，如果连续执行如下指令该如何处理
什么叫AOF重写？
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。
AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。
简单说就是将对同一个数据的若干个条命令执行结果 转化成 最终结果数据对应的指令进行记录。
AOF重写作用
- 降低磁盘占用量，提高磁盘利用率
- 提高持久化效率，降低持久化写时间，提高IO性能
- 降低数据恢复用时，提高数据恢复效率
AOF重写规则
-
进程内具有时效性的数据，并且数据已超时将不再写入文件
-
非写入类的无效指令将被忽略，只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
-
对同一数据的多条写命令合并为一条命令
如lpushlist1 a、lpush list1 b、lpush list1 c可以转化为：lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
AOF重写方式
- 手动重写
bgrewriteaof # 这是一个redis指令，不是配置
- 自动重写
自动重写触发条件设置
auto-aof-rewrite-min-size size # 达到指定大小就自动重写，size可以指定多少兆：2MB 、 4MB
auto-aof-rewrite-percentage percent #按照存储占用整体的百分比自动重写，percent指定10%，达到10%就可以自动重写
自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）
aof_current_size
aof_base_size
5.4 RDB与AOF区别
5.4.1 RDB与AOF对比（优缺点）
| 持久化方式 | RDB | AOF |
|---|---|---|
| 占用存储空间 | 小（数据级：压缩） | 大（指令级：重写） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |
5.4.2 RDB与AOF应用场景
RDB与AOF的选择之惑
- 对数据非常敏感，建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
- 数据呈现阶段有效性，建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结
综合比对
- RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
- 灾难恢复选用RDB
- 双保险策略，同时开启 RDB和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量