Redis超详细学习笔记

其他 2021-11-26 19:01:28 阅读次数: 0

Redis

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API

Redis 是一个高性能的key-value数据库

Redis支持主从同步

https://www.redis.net.cn/中文网址

英文官网：redis.io

特性

  1. 多样的数据类型
  2. 持久化
  3. 集群
  4. 事务
  5. ……

Redis 在windos下安装使用不建议，建议使用Linux服务器

Linux安装

1.下载linux安装包

2.解压完成

3.进入解压后的文件，可以看到redis的配置文件 redis.conf

4.基本的环境安装

yum install gcc-c++

make

make install

5.redis的默认安装路径 /usr/local/bin/

6.将redis配置文件，复制到/usr/local/bin/zidingyiConfig目录下,之后就使用此配置文件进行启动

7.默认不是后台启动的，需要修改配置文件，改成yes 后台启动

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-URlquEBk-1629963650161)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210824114732895.png)]

8.启动：通过指定的配置文件启动服务

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SqTpklZl-1629963650164)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210824114828968.png)]

9.连接测试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nveeoKrz-1629963650165)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210824114929687.png)]

10.关闭redis服务

​ shutdown

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hirII9hz-1629963650167)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210824115053743.png)]

基础知识

redis 默认有16个数据库，默认使用第0个数据库

​ select 3 :select 下标 切换数据库

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DjIF55Bp-1629963650168)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210824115949808.png)]

key * 查看所有key

flushdb清空数据库

flushdball清空全部数据库内容

redis是单线程的！

是基于内存的。 官方提供数据100000+QPS

Redis为什么单线程还这么快？

redis是将所有的数据全部放到内存中，所以说使用单线程去操纵效率就很高，多线程（CPU上下文会切换：耗时的操作！）对于内存系统来说，没有上下文切换效率是很高的。多次读写都在一个CPU上。

五大数据类型( redis不区分大小写命令)

https://www.redis.net.cn/order

命令大全

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。

Redis-key

	keys * 			获取所有Key

​	get key  		获取value

​	expire key 10   key十秒后过期,设置key的过期时间

​	ttl key    		查看key剩余过期时间 

​	exists key		查看key是否存在

String（字符串）

set key1 v1			#设置值
get key1			#获取值
append key "hello"	# 追加字符串，如果当前key不存在，相当于setkey
STRLEN key1			# 获取字符串的长度
-----------------------------
set views 0	 #初始浏览量0
incr views   #自增1
decr views	 #自减1
INCRBY views 10 #可以设置自增步长，指定增量
DECRBY views 5	#指定减量
-----------------------------
#字符串范围
GETRANGE key1 0 3		#查看字符串 ，截取字符串 [0-3]
GETRANGE key1 0 -1		#获取全部的字符才能
#字符换替换
SETRANGE key2 1 aa		#指定位置开始的字符串替换
------------------------------
setex key3 30 "hello" 	#设置过期时间
setnx key4 "helllle"	#如果不存在key则设置   如果存在则不设置，创建失败
------------------------------
mset k1 v1 k2 v2 k3 v3 	#设置多个值
mget k1 k2 k3 			#获取多个值
msetnx k1 v1 k4 v4		#如果不存在设置   是一个原子性操作，要么一起成功，要么一起失败
#对象
set user:1 {
    
    name:zhangsan,age:3}# 设置一个user:1 对象 值为json字符串来保存一个对象
#这里的Key是一个巧妙的设计：user:{id}:{filed}

getset    #先get再set
getset  key3 vlaue33	#如果存在值则获取原来的值，并设置新的值

String类似的使用场景：value除了是我们的字符串还是我们的数字

  • 计数器
  • 统计多单位数量
  • 对象缓存存储

List

在redis里可以把list做成 栈、队列、阻塞队列

所有的list命令都是L开头的



LPUSH list one  #将一个值或者多个值，插入到列表头部（左）
LPUSH list two
LPUSG list three
LRANGE list 0 -1	#获取list值  “three”  "two" "one"
Rpush list four		# 在队列的右边插入一个值
Lpop list			# 移除list的第一个元素
Rpop list			# 一处list的最后一个元素
lindex lisr 0		#通过下标获取list中的某一个值
Llen list			#获取list的长度
--------
#移除指定个数的值，精确匹配
Lrem list 1 one		
Lrem list 2 one		
---------
ltrim list 1 2		#通过下标截取指定的长度，这个list被改变了，截断了只剩下截取的元素
--------
rpoplpush list mylist # 移除最后一个元素，然后加入到新的列表中
----------
lset list 0 item		# 将list指定下标的值 替换为另外的值，如果不存在列表，或者不存在下标，则会报错
----------
linsert mylist before|after "hello" "other" #在数组指定值的前或者后面 插入一个指定的值

小结

  • 它实际是一个链表，before Node after , left , right 都可以插入值

  • 如果key不存在，创建新的链标

  • 如果key存在，新增内容

  • 如果移除了所有值，空链表，也代表不存在

  • 在两边插入或者改动值，效率最高。操作中间元素，效率会低

    可以做消息队列 或者 栈 消息队列（Lpush Rpop）,栈（Lpush Lpop）

Set(集合)

sadd myset "hello" 			#set集合中添加元素
SMEMBERS myset 				#查看指定set的所有值
SISMEMBER myset world		#判断某个值是不是在set集合中
scard myset					#获取set集合中的元素个数
srem myset "hello"			#移除set集合中的指个元素
SRANDMEMBER	myset			#随机抽出set集合中的元素
SRANDMEMBER	myset 3 		#随机抽出set集合中的N个元素
spop myset					#随机删除set中的一个元素
smove myset myset2 "hello"	#将一个指定的值，移动到另一个set集合
SDIFF key1 key2   			#两个集合的差集
SINTER key1 key2			#两个集合的交集
SUNION key1 key2			#两个集合的并集

Hash

HDEL key field1 field2				#删除一个或多个哈希表字段
HEXISTS key field 					#查看哈希表 key 中，指定的字段是否存在。
HGET key field 						#获取存储在哈希表中指定字段的值。          
HGETALL key 						#获取在哈希表中指定 key 的所有字段和值        
HINCRBY key field increment 		#为哈希表 key 中的指定字段的整数值加上增量 increment 。
HINCRBYFLOAT key field increment 	#为哈希表 key 中的指定字段的浮点数值加上增量 increment 。
HKEYS key 							#获取所有哈希表中的字段              
HLEN key 							#获取哈希表中字段的数量               
HMGET key field1 field2				#获取所有给定字段的值   
HMSET key field1 value1 field2 value2 #同时将多个 field-value (域-值)对设置到哈希表 key 中。
HSET key field value 				#将哈希表 key 中的字段 field 的值设为 value 。
HSETNX key field value 				#只有在字段 field 不存在时，设置哈希表字段的值。
HVALS key 							#获取哈希表中所有值。                
HSCAN key cursor [MATCH pattern\] [COUNT count] #迭代哈希表中的键值对。

Zset(有序集合)

在set基础上，增加了一个值，set k1 v1 zset k1 score1 v1

127.0.0.1:6379[3]> zadd myset 1 one  #添加元素
1
127.0.0.1:6379[3]> zadd myset 2 two 3 three
2
127.0.0.1:6379[3]> ZRANGE myset 0 -1
one
two
three
---------------------------------------
排序
127.0.0.1:6379[3]> zadd salary 25 kuangshen	#添加三个用户
1
127.0.0.1:6379[3]> zadd salary 30 guoguo
1
127.0.0.1:6379[3]> zadd salary 59 wanghao
1
127.0.0.1:6379[3]> ZRANGEBYSCORE salary -inf +inf#显示所有用户 从小到大
kuangshen
guoguo
wanghao
127.0.0.1:6379[3]> ZRANGEBYSCORE salary -inf +inf withscores#显示所有用户 从小到大附带成绩
kuangshen
25
guoguo
30
wanghao
59
127.0.0.1:6379[3]> ZRANGEBYSCORE salary -inf 25 withscores#判断小于25的 用户 降序排列
kuangshen
25
-----------------------------------
127.0.0.1:6379[3]> zrange salary 0 -1
kuangshen
guoguo
wanghao
127.0.0.1:6379[3]> zrem salary wanghao	#删除指定的用户
1
127.0.0.1:6379[3]> zrange salary 0 -1
kuangshen
guoguo
127.0.0.1:6379[3]> zcard salary			#获取元素个数
2
-----------------------
127.0.0.1:6379[3]> zadd myset 1 hello
1
127.0.0.1:6379[3]> zadd myset 2 worelr 3 kguoguo
2
127.0.0.1:6379[3]> zcount myset 1 3   #获取指定区间的成员数量
3
127.0.0.1:6379[3]> zcount myset 1 2
2

三种特殊数据类型

geospatial地理位置

操作方法：

  • geoadd：添加地理位置的坐标。
  • geopos：获取地理位置的坐标。
  • geodist：计算两个位置之间的距离。
  • georadius：根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
  • georadiusbymember：根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
  • geohash：返回一个或多个位置对象的 geohash 值。
# 一般用java一次性导入
127.0.0.1:6379[3]> geoadd china:city 116.40 39.90 bejing
1
127.0.0.1:6379[3]> geoadd china:city 121.47 31.23 shanghai
1
127.0.0.1:6379[3]> geoadd china:city 160.50 29.53 chongqing 114.05 22.52 shenzhen
2
127.0.0.1:6379[3]> geoadd china:city 120.26 30.24 hangzhou 108.96 34.26 xian
2
#查看经纬度
127.0.0.1:6379[3]> geopos china:city bejing
116.39999896287918091
39.90000009167092543
#查看两地直线距离
127.0.0.1:6379[3]> geodist china:city bejing chongqing km
4148.3285
---------------------------------------------------------
127.0.0.1:6379[3]> GEORADIUS china:city 110 30 1000 km #以 110 30 为中心，寻找元素集合中方圆1000km内的城市
xian
shenzhen
hangzhou
127.0.0.1:6379[3]> GEORADIUS china:city 110 30 500 km
xian
127.0.0.1:6379[3]> GEORADIUS china:city 110 30 500 km withdist#显示到中间距离的位置
xian
483.8340
127.0.0.1:6379[3]> GEORADIUS china:city 110 30 500 km withcoord #显示他人的定位信息
xian
108.96000176668167114
34.25999964418929977
127.0.0.1:6379[3]> GEORADIUS china:city 110 30 1000 km withcoord count 2#筛选指定结果
xian
108.96000176668167114
34.25999964418929977
shenzhen
114.04999762773513794
22.5200000879503861
127.0.0.1:6379[3]>

Hyperloglog

127.0.0.1:6379[3]> PFADD mykey a b c d e f g h i  #添加一组元素
1
127.0.0.1:6379[3]> PFADD mykey2 i j k l m n
1
127.0.0.1:6379[3]> PFCOUNT mykey					#查看一组的元素基数数量
9
127.0.0.1:6379[3]> PFMERGE mykey3 mykey mykey2		#合并多个组到新组
OK
127.0.0.1:6379[3]> PFCOUNT mykey3
14

Bitmaps

位存储

统计用户信息，打卡，等两个状态的

bitmaps 位图。操作二进制位来进行记录，只有0和1 两个状态

测试

127.0.0.1:6379[3]> setbit sign 0 1
0
127.0.0.1:6379[3]> setbit sign 1 0
0
127.0.0.1:6379[3]> setbit sign 2 0
0
127.0.0.1:6379[3]> setbit sign 3 1
0
127.0.0.1:6379[3]> setbit sign 4 0
0
127.0.0.1:6379[3]> setbit sign 5 1
0
127.0.0.1:6379[3]> setbit sign 6 0
0
127.0.0.1:6379[3]> GETBIT sign 1 #查看状态
0
127.0.0.1:6379[3]> GETBIT sign 3
1
127.0.0.1:6379[3]> BITCOUNT sign #统计打卡的天数
3

使用bitmap记录一周打卡记录

1 打卡 0 未打卡

统计打卡天数：bitcount

事务

Redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行。

一次性、顺序性、排他性！执行一些列的命令

Redis事务没有隔离级别的概念！

Redis单条命令是保证原子性的，但是事务不保证原子性。

redis的事务：

  • 开启事务(multi)
  • 命令入队(…)
  • 执行事务(exec)

正常执行事务

127.0.0.1:6379[3]> multi		#开启事务
OK
127.0.0.1:6379[3]> set k2 v2	#命令入队
QUEUED
127.0.0.1:6379[3]> set k3 v3
QUEUED
127.0.0.1:6379[3]> exec			#执行事务
1) OK
2) OK

放弃事务

discard


127.0.0.1:6379[3]> multi
OK
127.0.0.1:6379[3]> set k2 v2
QUEUED
127.0.0.1:6379[3]> set k3 v3
QUEUED
127.0.0.1:6379[3]> set k4 v4
QUEUED
127.0.0.1:6379[3]> DISCARD		#取消事务
OK
127.0.0.1:6379[3]> get k4		# 事务队列中的命令都不会执行
(nil)
127.0.0.1:6379[3]>

编译型异常（代码有问题！命令有问题！），事务中的所有命令都不会被执行

127.0.0.1:6379[3]> multi
OK
127.0.0.1:6379[3]> set k5 v5
QUEUED
127.0.0.1:6379[3]> getset k2 v2
QUEUED
127.0.0.1:6379[3]> getset k4343
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379[3]> exec
(error) EXECABORT Transaction discarded because of previous errors.

运行时异常，如果事务队列中的命令存在语法性，执行命令时正常命令可以执行，问题命令会抛出异常

127.0.0.1:6379[3]> set k1 "v1"
OK
127.0.0.1:6379[3]> get k1
"v1"
127.0.0.1:6379[3]> multi
OK
127.0.0.1:6379[3]> incr k1
QUEUED
127.0.0.1:6379[3]> get k1
QUEUED
127.0.0.1:6379[3]> exec
1) (error) ERR value is not an integer or out of range  #运行时异常
2) "v1"

监控

悲观锁

  • 很悲观，认为什么时候都会出问题，无论做什么都加锁

乐观锁

  • 很乐观，认为什么时候都不会出现问题，所以不会上锁，更新数据的时候判断一下是否有人修改数据
  • 获取version
  • 更新时比较version

Redis监控测试
watch

unwath

127.0.0.1:6379[3]> set money 10
OK
127.0.0.1:6379[3]> set out 0
OK
127.0.0.1:6379[3]> watch money
OK
127.0.0.1:6379[3]> multi
OK
127.0.0.1:6379[3]> DECRBY money 10
QUEUED
127.0.0.1:6379[3]> INCRBY out 10
QUEUED

此时另外一个进程修改了money

127.0.0.1:6379[3]> set money 1000
OK

原来的进程执行事务，执行失败。

测试多线程修改值，使用watch能当作redis的乐观锁操作

127.0.0.1:6379[3]> watch money
OK
127.0.0.1:6379[3]> multi
OK
127.0.0.1:6379[3]> DECRBY money 10
QUEUED
127.0.0.1:6379[3]> INCRBY out 10
QUEUED
127.0.0.1:6379[3]> exec			# 执行之前另一个进程修改了元素，元素发生改变 事务执行失败
(nil)

事务执行失败之后要关闭监视，然后重新监视执行事务

127.0.0.1:6379[3]> exec	
(nil)
127.0.0.1:6379[3]> UNWATCH     #如果发现事务执行失败，就先解锁
OK
127.0.0.1:6379[3]> watch money	#获取新的值，再次监视
OK
127.0.0.1:6379[3]> multi
OK
127.0.0.1:6379[3]> DECRBY money 1
QUEUED
127.0.0.1:6379[3]> INCRBY out 1
QUEUED
127.0.0.1:6379[3]> exec			#对比监视的值是否发生变化，如果没有变化，执行成功，如果变了，执行则失败
1) (integer) 999
2) (integer) 1
127.0.0.1:6379[3]>

Redis.conf配置文件详解

单位 不区分大小写

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XyDpWhnA-1629963650169)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825151600624.png)]

包含

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tJatvb6O-1629963650169)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825151953999.png)]

可以引入多个配置文件

网络

bind 127.0.0.1		#绑定的ip
protected-mode yes	#保护模式
port 6379			#端口设置

通用GENERAL

daemonize yes  		#是否以守护进程的方式运行，默认是no，需要自己开启为yes,后台运行
pidfile /var/run/redis_6379.pid	#如果以后台的方式运行，我们就需要指定过一个pid文件
databases 16 		#数据库的数量  默认是16个数据库
always-show-logo yes	#是否总是显示logo

日志

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pjvTfrAO-1629963650170)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825152443177.png)]

快照

持久化，在规定的时间内，执行了多少次操作，则会持久到文件.rdb .aof

redis是内存数据库，如果不持久化，断点就会导致数据消失

#  如果900s 内，如果至少有1个key进行了修改，则进行持久化操作
save 900 1
save 300 10
save 60 10000

stop-weites-on-bgsave-error yes 	#持久化如果出错，是否还需要继续工作

rdbcompression  yes   		#是否压缩 rdb文件，需要消耗cpu资源

rdbchecksum  yes			#保存rdb文件的时候，是否进行错误的检查校验

dir  ./     			#rdb文件的保存目录

SECURITY 安全

可以在这儿设置redis的密码，默认是没有密码的

config set requirepass "123456"   #设置redis密码
auth 123456						#使用密码登陆

限制 CLIENTS

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-buDk0hxV-1629963650171)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825154133604.png)]

APPEND ONLY模式 aof配置

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-36wcySVi-1629963650172)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825154828889.png)]

Redis的持久化

redis是内存数据库，断电即失

RDB

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZRRSFdPh-1629963650173)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825163859241.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SiBKLBPj-1629963650173)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825163944640.png)]

rdb保存的文件是dump.rdb

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KO50cXxR-1629963650174)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825164053923.png)]

触发机制

  1. save的规则满足的情况下，会自动触发rdb规则
  2. 执行flushall命令，也会触发我们的rdb规则！
  3. 退出redis，也会产生rdb文件

备份就会自动生成dump.rdb文件

如何恢复rdb文件

  1. 只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候就会自动检查dump.rdb，恢复其中的数据

优缺点

优点：

  1. 适合大规模的数据恢复！
  2. 对数据的完整性要求不高！

缺点：

  1. 需要一定的时间间隔进行操作，如果redis意外宕机，这个最后一次修改的数据就没有了
  2. fork进程的时候，会占用一定的内存空间！

AOF(Apend Only File)

将我们所有的命令记录下来，history,恢复的时候就把这个文件全部再执行一遍

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0urmuDed-1629963650175)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825165424397.png)]

以日志的行是来记录每个写操作，将reis执行过的所有指令记录下来（读操作不记录），只许追加文件但是不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，reids重启的化就根据日志文件的内容将写指令 从前到后执行一次，以完成数据的恢复工作

Aof保存的是appendonly.aof 文件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ujXHr7OT-1629963650175)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825170036648.png)]

默认是不开启的，需要手动开启，将appendonly 改为 yes即可

重启redis生效

如果aof文件有错误，这时候redis无法启动，可以通过redis-check-aof修复，然后启动redis

redis-check-aof --fix appendonly.aof

然后重启即可

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zr0kU3vB-1629963650176)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825171535122.png)]

如果aof过大超过64M，会fork一个新的进程对文件重写

aof默认得就是 对文件得无限追加

优缺点

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2SCsNw8a-1629963650176)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210825170914606.png)]

优点：

  1. 每次修改都会同步，文件的完整性会更好
  2. 每秒同步一次，可能丢失一秒的数据
  3. 从不同步，效率最高

缺点：

  1. 相对于数据文件来说，aof远远大于rdb，修复速度也比rdb慢！
  2. Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化

Redis订阅

菜鸟教程 https://www.runoob.com/redis/redis-pub-sub.html

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

img

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

img

序号 命令及描述
1 [PSUBSCRIBE pattern pattern …] 订阅一个或多个符合给定模式的频道。
2 PUBSUB subcommand [argument [argument …]] 查看订阅与发布系统状态。
3 PUBLISH channel message 将信息发送到指定的频道。
4 PUNSUBSCRIBE [pattern [pattern …]] 退订所有给定模式的频道。
5 [SUBSCRIBE channel channel …] 订阅给定的一个或多个频道的信息。
6 UNSUBSCRIBE [channel [channel …]] 指退订给定的频道。

测试

# 订阅端
127.0.0.1:6379[3]> SUBSCRIBE guoguo				#订阅一个频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "guoguo"
3) (integer) 1
1) "message"					#等到读取推送的信息
2) "guoguo"
3) "hello melody"
1) "message"
2) "guoguo"
3) "this is my redis"

# 发送端
127.0.0.1:6379[3]> PUBLISH guoguo "hello melody"	#发布者发布消息到频道
(integer) 1
127.0.0.1:6379[3]> PUBLISH guoguo "this is my redis"
(integer) 1

Redis主从复制

概念

主从复制，是指将一台redis服务器的数据，复制到其它的redis服务器。前者称为主节点（master/leader），后者称为从节点（slave/follower）；数据的复制是单向的，只能从主节点到从节点。Master节点以写威住，slave以读为主。

**默认情况下每台redis服务器都是主机点；**且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制的作用主要包括：

  1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
  2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
  3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写redis数据时的应用连接主节点，读redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量
  4. 高可用基石：除了上述作用外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是redis高可用的基础

一般来说，要将redis运行于工程项目中，只使用一台redis服务器是万万不能的，原因如下：

  1. 从结构上，单个reids服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大

  2. 从容量上，单个redis服务器内存容量有限，就算一台redis服务器内存容量为256G，也不能将所有内存用作redis存储内存，一般来说，单台redis最大使用内存不应该超过20G.

    电商网站上的商品，一般都是一次上传，无数次的浏览，也就是“多读少写”

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zTw7DwM7-1629963650178)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210826111141794.png)]

在企业中，主从复制是必须要用的。

环境配置

查看redis当前库信息

127.0.0.1:6379[3]> info replication   #查看当前库信息
# Replication
role:master		#角色 master
connected_slaves:0# 没有从机
master_replid:d9a05aef9ff6ede81a656de97e7fa2d0c2b634d8
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9jZ4lfeR-1629963650178)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210826112650432.png)]

#再从机中选择谁为主机
slaveof ip port

使用命令配置主机从机，是暂时的，在配置文件中配置才是永久的。

config配置文件中：

# 配置主机的IP 端口
replicaof <masterip> <masterport>
# 如果有密码
masterauth <master-password>

主机负责写请求，从机负责读请求不能写。主机中的所有信息和数据都会自动被从机保存。

测试发现：主机断开连接，从机依旧是连接主机的，但是没有写操作，这个时候如果主机重新连接，从机一九可以直接获得主机写的信息！

复制原理

Slave启动成功连接到master后会发送一个sync命令

Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，**master将传送整个数据文件到slave，并完成一次完全同步（全量复制）。**然后如果再有新增的，后来增加的就是增量复制。

  • 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
  • 增量复制：Master继续将新的所有收集到的修改命令依次传递给slave，完成同步

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

层层链路

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GxvLURiC-1629963650179)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210826120415895.png)]

如果没有老大了，手动提高到主机

如果主机断开了连接，使用SLAVEOF no one让自己变为主机，其他节点就可以手动连接到最新的主节点（手动）

如果 这时候原主节点重启，那么再重新手动连接原主机

哨兵模式

（自动选举新的主机的模式）

概述

主从切换技术的方法是：当主服务器宕机互殴，需要手动把一台服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用，所以在Redis2.8之后开始提供sentinel（哨兵）架构来解决这个问题。

哨兵模式能够监控主机是否故障，如果故障了根据投票数来自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行、其原理是**哨兵通过发送命令，等待Redis服务器响应，从而监控运行多个Redis实例。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TSk55Swz-1629963650179)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210826135908578.png)]

这里的哨兵有连个作用

  • 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
  • 当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换为主机。

然后一个哨兵进程对redis服务器来进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FpMk2zQf-1629963650180)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210826140454018.png)]

假设主服务器宕机，哨兵1 检测到这个结果，并不会马上进行failover进程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定的值得时候，那么哨兵之间就会进行一次投票，投票结果由一个哨兵发起，进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试

  1. 配置哨兵配置文件sentinel.conf
#sentinel monitor 被监控的名称 host post 1
sentinel monitor myredis 127.0.0.1 7379 1

后面的数字1，代表主机挂了，slave投票看让谁接替称为主机，票数最多的就会称为主机！

2.启动哨兵

redis-sentinel kconfig/sentinel.conf

如果Master节点断开了，这个时候就会在从机中随机选择一个服务器作为主机。

如果原master节点重新恢复了，只能归并到新的主机下，当做从机。

优缺点

优点：

  1. 哨兵集群，基于主从复制模式，所有的主从配置优点，他也都有。
  2. 主从可以切换，故障可以转移，系统的可用性会更好
  3. 哨兵模式就是主从模式的升级，手动到自动，更加健壮！

缺点：

  1. redis不好在线扩容，集群容量一旦到达上限，在线扩容会十分麻烦！
  2. 实现哨兵模式的配置是十分麻烦的，里面有很多的配置

哨兵模式的全部配置

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
  sentinel monitor mymaster 127.0.0.1 6379 2
 
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
 
 
 
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。  
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
 
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本，
这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
一个是事件的类型，
一个是事件的描述。
如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
#通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
 sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

Redis缓存穿透和雪崩

缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

img

解决方案

  1. 缓存空对象

    缓存空对象：是指在持久层没有命中的情况下，对key进行set （key,null）

缓存空对象会有两个问题：第一，value为null 不代表不占用内存空间，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象

  2. 布隆过滤器拦截

    在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截，当收到一个对key请求时先用布隆过滤器验证是key否存在，如果存在在进入缓存层、存储层。可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景，代码维护较为复杂，但是缓存空间占用少。

布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

算法描述：

初始状态时，BloomFilter是一个长度为m的位数组，每一位都置为0。

添加元素x时，x使用k个hash函数得到k个hash值，对m取余，对应的bit位设置为1。

判断y是否属于这个集合，对y使用k个哈希函数得到k个哈希值，对m取余，所有对应的位置都是1，则认为y属于该集合（哈希冲突，可能存在误判），否则就认为y不属于该集合。可以通过增加哈希函数和增加二进制位数组的长度来降低错报率。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xWcReVlU-1629963650180)(C:\Users\guochunning\AppData\Roaming\Typora\typora-user-images\image-20210826150755813.png)]

错报原因：

​ 一个key映射数组上多位，一位会被多个key使用，也就是多对多的关系。如果一个key映射的所有位值为1，就判断为存在。但是可能会出现key1 和 key2 同时映射到下标为100的位，key1不存在，key2存在，这种情况下会发生错误率

方案对比：

img

缓存雪崩

由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不可用（宕机）或者大量缓存由于超时时间相同在同一时间段失效（大批key失效/热点数据失效），大量请求直接到达存储层，存储层压力过大导致系统雪崩。

解决方案：

  • 可以把缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务。利用sentinel或cluster实现。
  • 采用多级缓存，本地进程作为一级缓存，redis作为二级缓存，不同级别的缓存设置的超时时间不同，即使某级缓存过期了，也有其他级别缓存兜底
  • 缓存的过期时间用随机值，尽量让不同的key的过期时间不同（例如：定时任务新建大批量key，设置的过期时间相同）

缓存击穿

缓存击穿，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。

  1. 分布式互斥锁

    只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。set(key,value,timeout)

img

  1. 永不过期

从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去更新缓

img

2种方案对比：

  • 分布式互斥锁：这种方案思路比较简单，但是存在一定的隐患，如果在查询数据库 + 和 重建缓存（key失效后进行了大量的计算）时间过长，也可能会存在死锁和线程池阻塞的风险，高并发情景下吞吐量会大大降低！但是这种方法能够较好地降低后端存储负载，并在一致性上做得比较好。

  • “永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点key产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。
    ter实现。

  • 采用多级缓存，本地进程作为一级缓存，redis作为二级缓存，不同级别的缓存设置的超时时间不同，即使某级缓存过期了，也有其他级别缓存兜底

  • 缓存的过期时间用随机值，尽量让不同的key的过期时间不同（例如：定时任务新建大批量key，设置的过期时间相同）

缓存击穿

缓存击穿，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。

  1. 分布式互斥锁

    只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。set(key,value,timeout)

img

  1. 永不过期

从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去更新缓

img

2种方案对比：

  • 分布式互斥锁：这种方案思路比较简单，但是存在一定的隐患，如果在查询数据库 + 和 重建缓存（key失效后进行了大量的计算）时间过长，也可能会存在死锁和线程池阻塞的风险，高并发情景下吞吐量会大大降低！但是这种方法能够较好地降低后端存储负载，并在一致性上做得比较好。

  • “永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点key产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。

学习途径来自狂神说

猜你喜欢

转载自blog.csdn.net/qq_39306234/article/details/119933056
今日推荐
面壁智能发布 Eurux-8x22B 开源大模型 —— 堪称「理科状元」
开源日报 | 谷歌扶持鸿蒙上位；开源Rabbit R1；Docker加持的安卓手机；微软的焦虑和野心；海尔电器把开放平台关了
中国码农的“35岁魔咒”
蘭雅 CorelDRAW 插件 2024.5.1 国际劳动节版，免费下载
Arc Browser for Windows 1.0 正式 GA
90后程序员开发视频搬运软件、不到一年获利超 700 万，结局很刑！
周排行
【转】spring中对控制反转和依赖注入的理解
tms webcore 安装和使用
java程序员进阶相关书籍
SpringMVC接受请求参数、
如何保存训练好的机器学习模型
MyEclipse、Eclipse设置项目JDK的三个地方
商超行业微信小程序开发定制一般多少钱 （行业技术人员解读）
Markdown编辑器语言——30分钟入门到到精通
Linux系统下MongoDB的简单安装与基本操作
Power Strings
每日归档
更多
2024-05-07(14)
2024-05-06(40)
2024-05-05(0)
2024-05-04(7)
2024-05-03(19)
2024-05-02(0)
2024-05-01(4)
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022