一起重新开始学大数据-hadoop先导篇-Day42-Redis的列表、散列、set集合、Sorted和Redis持久化

一起重新开始学大数据-hadoop先导篇-Day42-Redis的列表、散列、set集合、Sorted和Redis持久化

在这里插入图片描述

列表


在这里插入图片描述

特点

  • 基于Linked List实现

  • 元素是字符串类型

  • 列表头尾增删快,中间增删慢,增删元素是常态

  • 元素可以重复出现

  • 最多包含2^32-1元素

在这里插入图片描述

列表的索引

从左至右,

从0开始

从右至左,

从-1开始
在这里插入图片描述

增加

左右或者头尾压入元素

LPUSH key value [value ...]
在这里插入图片描述

LPUSHX key value
在这里插入图片描述

RPUSH key value [value ...]
在这里插入图片描述

RPUSHX key value
在这里插入图片描述

注解:

B block 块,阻塞
L left 左
R right 右
X exist 存在

左右或者头尾弹出元素

LPOP key
RPOP key

从一个列表尾部弹出元素压入到另一个列表的头部

RPOPLPUSH source destination
返回列表中指定范围元素

LRANGE key start stop

LRANGE key 0 -1 表示返回所有元素

查改

获取指定位置的元素
LINDEX key index
设置指定位置元素的值

LSET key index value

列表长度,元素个数

LLEN key
从列表头部开始删除值等于value的元素count次

LREM key count value

count > 0 : 从表头开始向表尾搜索,移除与 value 相等的元素,数量为count
count < 0 : 从表尾开始向表头搜索,移除与 value 相等的元素,数量为 count 的绝对值
count = 0 : 移除表中所有与 value 相等的值

去处指定范围外元素
LTRIM key start stop

例子: 微博的评论最后500条

LTRIM weibo:comments 0 499

在列表中某个存在的值(pivot)前或后插入元素(指定元素前后插入元素)

LINSERT key BEFORE|AFTER pivot value

key和pivot不存在,不进行任何操作

阻塞

如果弹出的列表不存在或者为空,就会阻塞
超时时间设置为0,就是永久阻塞,直到有数据可以弹出
如果多个客户端阻塞在同一个列表上,使用First In First Service原则,先到先服务

左右或者头尾阻塞弹出元素
BLPOP key [key ...] timeout

BRPOP key [key ...] timeout
从一个列表尾部阻塞弹出元素压入到另一个列表的头部

BRPOPLPUSH source destination timeout

散列hash


在这里插入图片描述

特点

  • 由field和关联的value组成的map键值对

  • field和value是字符串类型

  • 一个hash中最多包含2^32-1键值对
    在这里插入图片描述

设置单个字段

HSET key field value
HSETNX key field value

key的filed不存在的情况下执行,key不存在直接创建

设置多个字段

HMSET key field value [field value ...]
返回字段个数

HLEN key
判断字段是否存在

HEXISTS key field

key或者field不存在,返回0
返回字段值

HGET key field
返回多个字段值

HMGET key field [field ...]
返回所有的键值对

HGETALL key
返回所有字段名

HKEYS key
返回所有值

HVALS key

在字段对应的值上进行整数的增量计算

HINCRBY key field incremen

在字段对应的值上进行浮点数的增量计算

HINCRBYFLOAT key field increment
删除指定的字段

HDEL key field [field ...]

用途

  1. 节约内存空间
  2. 每创建一个键,它都会为这个键储存一些附加的管理信息(比如这个键的类型,这个键最后一次被访问的时间等等)
  3. 所以数据库里面的键越多,redis数据库服务器在储存附加管理信息方面耗费的内存就越多,花在管理数据库键上的CPU也会越多在字段对应的值上进行浮点数的增量计算

set集合


在这里插入图片描述

特点

  • 无序的、去重的

  • 元素是字符串类型

  • 最多包含2^32-1元素
    在这里插入图片描述

命令

增加一个或多个元素
SADD key member [member ...]

	如果元素已经存在,则自动忽略

移除一个或者多个元素
SREM key member [member ...]

元素不存在,自动忽略

返回集合包含的所有元素
SMEMBERS key

如果集合元素过多,例如百万个,需要遍历,可能会造成服务器阻塞,生产环境应避免使用

注意 :

SMEMBERS 有可能返回不同的结果,所以,如果需要存储有序且不重复的数据使用有序集合,存储有序可重复的使用列表

检查给定元素是否存在于集合中
SISMEMBER key member

随机返回集合中指定个数的
SRANDMEMBER key [count]

如果 count 为正数,且小于集合基数,那么命令返回一个包含 count 个元素的数组,数组中的元素各不相同。
如果 count 大于等于集合基数,那么返回整个集合
如果 count 为负数,那么命令返回一个数组,数组中的元素可能会重复出现多次,而数组的	长度为 count 的绝对值
如果 count 为 0,返回空
如果 count 不指定,随机返回一个元素

返回集合中元素的个数

SCARD key

键的结果会保存信息,集合长度就记录在里面,所以不需要遍历

随机从集合中移除并返回这个被移除的元素

SPOP key
把元素从源集合移动到目标集合

SMOVE source destination member

集合操作

差集

SDIFF key [key ...],从第一个key的集合中去除其他集合和自己的交集部分

SDIFFSTORE destination key [key ...],将差集结果存储在目标key中
在这里插入图片描述

交集

SINTER key [key ...],取所有集合交集部分
SINTERSTORE destination key [key ...],将交集结果存储在目标key中
在这里插入图片描述

并集

SUNION key [key ...],取所有集合并集

SUNIONSTORE destination key [key ...],将并集结果存储在目标key中

在这里插入图片描述

SortedSet有序集合

在这里插入图片描述

特点

  • 类似Set

  • 集合

  • 有序的、去重的

  • 元素是字符串类型

  • 每一个元素都关联着一个浮点数分值(Score),并按照分值从小到大的顺序排列集合中的元素。分值可以相同

  • 最多包含2^32-1元素

命令

增加一个或多个元素

ZADD key score member [score member ...]

如果元素已经存在,则使用新的score

移除一个或者多个元素
ZREM key member [member ...]

元素不存在,自动忽略

显示分值

ZSCORE key member
增加或者减少分值

ZINCRBY key increment member

increment为负数就是减少

返回元素的排名(索引)

ZRANK key member
返回元素的逆序排名
ZREVRANK key member

返回指定索引区间元素
ZRANGE key start stop [WITHSCORES]

如果score相同,则按照字典序lexicographical order 排列
默认按照score从小到大,如果需要score从大到小排列,使用ZREVRANGE

返回指定索引区间元素
ZREVRANGE key start stop [WITHSCORES]

如果score相同,则按照字典序lexicographical order 的 逆序 排列
默认按照score从大到小,如果需要score从小到大排列,使用ZRANGE

返回指定分值区间元素

ZREVRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]

返回score默认属于[min,max]之间,元素按照score降序排列,score相同字典降序
LIMIT中offset代表跳过多少个元素,count是返回几个。类似于Mysql
使用小括号,修改区间为开区间,例如(5、(10、5)
-inf和+inf表示负无穷和正无穷

移除指定排名范围的元素

ZREMRANGEBYRANK key start stop
移除指定分值范围的元素
ZREMRANGEBYSCORE key min max
返回集合中元素个数

ZCARD key
返回指定范围中元素的个数
ZCOUNT key min max

操作

并集
ZUNIONSTORE destination numkeys key [key ...] [WEIGHTS weight] [AGGREGATE SUM|MIN|MAX]

numkeys指定key的数量,必须 WEIGHTS选项,与前面设定的key对应,对应key中每一个score都要乘以这个权重

AGGREGATE选项,指定并集结果的聚合方式

SUM:将所有集合中某一个元素的 score值之和作为结果集中该成员的score值
MIN:将所有集合中某一个元素的score值中最小值作为结果集中该成员的score值

MAX:将所有集合中某一个元素的score值中最大值作为结果集中该成员的score值

交集
ZINTERSTORE destination numkeys key [key ...] [WEIGHTS weight] [AGGREGATE SUM|MIN|MAX]

numkeys指定key的数量,必须

WEIGHTS选项,与前面设定的key对应,对应key中每一个score都要乘以这个权重

AGGREGATE选项,指定并集结果的聚合方式
SUM:将所有集合中某一个元素的score值之和作为结果集中该成员的score值

MIN:将所有集合中某一个元素的score值中最小值作为结果集中该成员的score值
MAX:将所有集合中某一个元素的score值中最大值作为结果集中该成员的score值

持久化概述


什么是持久化

将数据从掉电易失的内存存放到能够永久存储的设备上

Redis为什么需要持久化

基于内存的
缓存服务器,需要吗?
内存数据库,需要吗?
消息队列,需要吗?

Redis持久化方式

RDB(Redis DB)

AOF(AppendOnlyFile)

RDB


RDB概述

在默认情况下,Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中

策略

自动:按照配置文件中的条件满足就执行BGSAVE

	save 60 1000,Redis要满足在60秒内至少有1000个键被改动,会自动保存一次

手动:客户端发起SAVE、BGSAVE命令

SAVE命令

redis > save
阻塞Redis服务,无法响应客户端请求
创建新的dump.rdb替代旧文件

在这里插入图片描述

BGSAVE命令

redis > bgsave

非阻塞,Redis服务正常接收处理客户端请求

Redis会通过folk()一个新的子进程来创建RDB文件,子进程处理完后会向父进程发送一个信号,通知它处理完毕

父进程用新的dump.rdb替代旧文件

BGSAVE是一个异步命令

在这里插入图片描述

SAVE 和 BGSAVE 命令比较

SAVE不用创建新的进程,速度略快
BGSAVE需要创建子进程,消耗额外的内存
SAVE适合停机维护,服务低谷时段
BGSAVE适合线上执行

自动执行

本质上就是BGSAVE

默认配置

save 900 1
save 300 10
save 60 10000
在这里插入图片描述

dbfilename dump.rdb

dir /var/lib/redis/6379

只要上面三个条件满足一个,就自动执行备份。创建RDB文件之后,时间计数器和次数计数器会清零。所以多个条件的效果不是叠加的

优缺点

优点

  • 完全备份,不同时间的数据集备份可以做到多版本恢复

  • 紧凑的单一文件,方便网络传输,适合灾难恢复

  • 恢复大数据集速度较AOF快

缺点

  • 会丢失最近写入、修改的而未能持久化的数据
  • folk过程非常耗时,会造成毫秒级不能响应客户端请求

AOF


AOF概述

  • Append only file,采用追加的方式保存
  • 默认文件appendonly.aof
  • 记录所有的写操作命令,在服务启动的时候使用这些命令就可以还原数据库

在这里插入图片描述

AOF写入机制

AOF方式不能保证绝对不丢失数据
目前常见的操作系统中,执行系统调用write函数,将一些内容写入到某个文件里面时,为了提高效率,系统通常不会直接将内容写入硬盘里面,而是先将内容放入一个内存缓冲区(buffer)里面,等到缓冲区被填满,或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里,未写入磁盘之前,数据可能会丢失

写入磁盘的策略

appendfsync选项,这个选项的值可以是always、everysec或者no

Always:服务器每写入一个命令,就调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据

Everysec(默认):服务器每一秒重调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据

No:服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外停机时,丢失命令的数量是不确定的
运行速度:always的速度慢,everysec和no都很快

AOF重写机制

AOF文件过大
合并重复的操作,AOF会使用尽可能少的命令来记录

重写过程

folk一个子进程负责重写AOF文件

子进程会创建一个临时文件写入AOF信息

父进程会开辟一个内存缓冲区接收新的写命令

子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写操作由子进程写入到临时文件中

新文件替代旧文件
注:如果写入操作的时候出现故障导致命令写半截,可以使用redis-check-aof工具修复
在这里插入图片描述

AOF重写触发

手动:客户端向服务器发送BGREWRITEAOF命令
自动:配置文件中的选项,自动执行BGREWRITEAOF命令

  • auto-aof-rewrite-min-size <size>,触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size时,才会考虑是否需要进行AOF重写,这个选项用于避免对体积过小的AOF文件进行重写

-auto-aof-rewrite-percentage <percent>,指定触发重写所需的AOF文件体积百分比:当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积,并且超 过上一次重写之后的AOF文件体积的percent %时,就会触发AOF重写。(如果服务器刚刚启动不久,还没有进行过AOF重写,那么使用服务器启动时载入的AOF文件的体积来作为基准值)。将这个值设置为0表示关闭自动AOF重写

AOF重写配置项举例

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

当AOF文件大于64MB时候,可以考虑重写AOF文件
只有当AOF文件的增量大于起始size的100%时(就是文件大小翻了一倍),启动重写

appendonly yes(AOF持久化开关在配置文件中是默认关闭)
默认关闭,请开启(no改yes)

优缺点

优点

  • 写入机制,默认fysnc每秒执行,性能很好不阻塞服务,最多丢失一秒的数据

  • 重写机制,优化AOF文件

  • 如果误操作了(FLUSHALL等),只要AOF未被重写,停止服务移除AOF文件尾部FLUSHALL命令,重启Redis,可以将数据集恢复到 FLUSHALL 执行之前的状态

缺点

  • 相同数据集,AOF文件体积较RDB大了很多
  • 恢复数据库速度叫RDB慢(文本,命令重演)

|
|
|
|

上一章-hadoop先导篇-Day41-Redis安装及字符串类型基本命令
下一章hadoop先导篇-Day42-Redis的主从复制和集群搭建
|
|
|
|
|

听说长按大拇指👍会发生神奇的事情呢!好像是下面的画面,听说点过的人🧑一个月内就找到了对象的💑💑💑,并且还中了大奖💴$$$,考试直接拿满分💯,颜值突然就提升了😎,虽然对你好像也不需要,是吧,吴彦祖🤵!

在这里插入图片描述在这里插入图片描述在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
flink-shaded-hadoop3和flink-shaded-hadoop3-uber是Apache Flink项目中与Hadoop 3.x版本集成相关的两个模块。 首先,Hadoop是一个分布式计算框架,用于处理大规模数据。而Flink是一个快速而可扩展的流式处理引擎,它可以在实时和批处理任务之间无缝切换。为了与Hadoop集成,并且能够在Flink中使用Hadoop生态系统的各种功能和工具,例如HDFS、YARN和MapReduce等,Flink提供了与Hadoop版本兼容的特殊模块。 flink-shaded-hadoop3模块是Flink所提供的一个可防止与Hadoop 3.x版本依赖冲突的模块。在Flink应用程序中,当需要使用Hadoop 3.x相关功能时,可以将flink-shaded-hadoop3模块添加到项目的依赖中。该模块会将特定版本的Hadoop 3.x依赖项重新打包,以避免与Flink自身或其他依赖项产生冲突。这样一来,Flink就能够与Hadoop 3.x版本协同工作,平滑地使用Hadoop的功能。 而flink-shaded-hadoop3-uber模块则是更加完整和庞大的用于集成Hadoop 3.x版本的模块。它将包含Hadoop 3.x依赖的所有必需库和资源等,以便于使用和编译。相比于flink-shaded-hadoop3模块,flink-shaded-hadoop3-uber模块更像是一个“全能版”,其中包含了实现与Hadoop 3.x版本深度集成所需的所有组件。这使得开发人员能够方便地构建和部署Flink应用程序,并且在与Hadoop生态系统进行交互时更加方便。 总的来说,flink-shaded-hadoop3和flink-shaded-hadoop3-uber模块都是Flink为了与Hadoop 3.x版本无缝集成,提供的两个特殊模块。它们通过重新打包Hadoop依赖,解决了可能产生的冲突问题,使得Flink能够顺利使用并利用Hadoop的功能和工具。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

你的动作太慢了!

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值