开始

  • select 切换数据库(默认0—15)

    image-20220607163437577

  • dbsize 查看当前数据库key的量

    image-20220607163511447

  • flushdb清空当前库

  • flushall通杀所有库

Redis键(key)

  • keys * 查看当前库所有key

    image-20220607162439088

  • exists key 判断key是否存在

    image-20220607162505841

  • type key 查看key类型

    image-20220607162557570

  • del key 删除key数据

    image-20220607162640897

  • unlink key 根据value选择且非阻塞 删除

    （仅将keys从keyspace元数据中删除，真正的删除将在后续异步删除）

  • expire key 10 为key设定过期时间，10:10秒钟

  • ttl key 查看key还有多久过期，-1：永不过期，-2:已经过期

    <img src="https://raw.githubusercontent.com/boyiz/OSS/main/img/image-20220607163156282.png" alt="image-20220607163156282" style="zoom:50%;" />

Redis五大数据类型

String字符串

简介

  • String 是 Redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。
  • String 类型是二进制安全的。意味着 Redis 的 string 可以包含任何数据。比如 jpg 图片或者序列化的对象。
  • String 类型是 Redis 最基本的数据类型，一个 Redis 中字符串 value 最多可以是 512M。

命令

1
set <key> <value> 添加键值对

image-20220607164705091

  • *NX：当数据库中key不存在时，可以将key-value添加数据库
  • *XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥
  • *EX：key的超时秒数
  • *PX：key的超时毫秒数，与EX互斥
1
2
3
4
5
6
7
get  <key> 查询对应键值

append <key> <value> 将给定的<value> 追加到原值的末尾

strlen <key> 获得值的长度

setnx <key> <value> 只有在key不存在时,设置 key 的值,key存在不生效
image-20220607165330749 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
incr  <key>
		将 key 中储存的数字值增1
		只能对数字值操作，如果为空，新增值为1
decr  <key>
		将 key 中储存的数字值减1
		只能对数字值操作，如果为空，新增值为-1
		
incrby / decrby  <key><步长>将 key 中储存的数字值增减。自定义步长。

注⚠️
incr为原子操作不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会有任何 context 	switch （切换到另一个线程）。
（1）在单线程中，能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。
（2）在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。
Redis单命令的原子性主要得益于Redis的单线程。

image-20220607165604775 image-20220607171202625 
1
2
3
4
5
6
7
8
mset  <key1> <value1> <key2> <value2>  ..... 
	同时设置一个或多个 key-value对  
mget  <key1> <key2> <key3> .....
	同时获取一个或多个 value  
msetnx <key1> <value1> <key2> <value2>  ..... 
	同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。

⚠️原子性，有一个失败则都失败
image-20220607172405937 
1
2
3
4
getrange  <key> <起始位置> <结束位置>
	获得值的范围，类似java中的substring，前包，后包
setrange  <key> <起始位置> <value>
	用<value>覆写<key>所储存的字符串值，从<起始位置>开始(索引从0开始)。
image-20220607172755821 
1
2
3
4
setex  <key> <过期时间> <value>
	设置键值的同时，设置过期时间，单位秒。
getset <key> <value>
	以新换旧，设置了新值同时获得旧值。
image-20220607172936843 image-20220607173024991

数据结构

String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配.

image-20220607173312174

如图中所示，内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。

List列表

简介

单键多值

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

image-20220608163754941

命令

1
2
3
4
5
6
7
8
9
10
11
12
13
lpush/rpush  <key><value1><value2><value3> .... 从左边/右边插入一个或多个值。
	lpush，采用头插法插入
	rpush，采用尾插法插入
lpop/rpop  <key>从左边/右边吐出一个值。值在键在，值光键亡。

rpoplpush  <key1><key2>从<key1>列表右边吐出一个值，插到<key2>列表左边。

lrange <key><start><stop>
按照索引下标获得元素(从左到右)
lrange mylist 0 -1   0左边第一个，-1右边第一个，（0,-1表示获取所有）
lindex <key> <index> 按照索引下标获得元素(从左到右)
llen <key>获得列表长度

image-20220608165112005 image-20220608165224075 
1
2
3
linsert <key>  before｜after <value><newvalue>在<value>的 前｜后 面插入<newvalue>插入值
lrem <key><n><value>从左边删除n个value(从左到右)
lset <key> <index> <value>将列表key下标为index的值替换成value
image-20220608165601908 image-20220608165815683 image-20220608165913485

数据结构

List的数据结构为快速链表quickList。

首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，也即是压缩列表。

它将所有的元素紧挨着一起存储，分配的是一块连续的内存。当数据量比较多的时候才会改成quicklist。

因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。

image-20220608170132313

Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

Set集合

简介

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是*O(1)*。

一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变。

命令

1
2
3
4
sadd <key> <value1> <value2> ..... 
	将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略
smembers <key> 取出该集合的所有值。
sismember <key> <value> 判断集合<key>是否为含有该<value>值，有1，没有0
image-20220608171108490 
1
2
3
4
scard<key>返回该集合的元素个数。
srem <key><value1><value2> .... 删除集合中的某个元素。
spop <key>随机从该集合中吐出一个值。
srandmember <key> <n>随机从该集合中取出n个值。不会从集合中删除 。
image-20220608171528611 
1
2
3
4
smove <source><destination>value把集合中一个值从一个集合移动到另一个集合
sinter <key1><key2>返回两个集合的交集元素。
sunion <key1><key2>返回两个集合的并集元素。
sdiff <key1><key2>返回两个集合的差集元素(key1中的，不包含key2中的)
image-20220608171856646 image-20220608172044239

数据结构

Set数据结构是dict字典，字典是用哈希表实现的。

Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。

Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

Hash哈希

简介

Redis hash 是一个键值对集合。

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

类似Java里面的Map<String,Object>

用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储

image-20220609144209563

命令

1
2
3
4
5
6
7
8
hset <key> <field> <value>  给<key>集合中的<field>键赋值<value>
hget <key1> <field>  从<key1>集合<field>取出 value 
hmset <key1> <field1> <value1> <field2> <value2>...   批量设置hash的值
hexists <key1> <field>   查看哈希表 key 中，给定域 field 是否存在。 
hkeys <key>  列出该hash集合的所有field
hvals <key>  列出该hash集合的所有value
hincrby <key> <field> <increment> 为哈希表 key 中的域 field 的值加上增量 1   -1
hsetnx <key> <field> <value>  将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 .
image-20220609145017972 image-20220609145049780 image-20220609145455438

数据结构

Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。

当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable。

Zset有序集合

简介

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。

因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

命令

1
2
3
4
5
6
7
8
9
10
11
12
zadd  <key> <score1> <value1> <score2> <value2>…
	将一个或多个 member 元素及其 score 值加入到有序集 key 当中。
zrange <key> <start> <stop>  [WITHSCORES]   
	返回有序集 key 中，下标在<start><stop>之间的元素
	带WITHSCORES，可以让分数一起和值返回到结果集。
zrangebyscore key min max [withscores] [limit offset count]
	返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。
	有序集成员按 score值递增(从小到大)次序排列。 
	带WITHSCORES，可以让分数一起和值返回到结果集。
zrevrangebyscore key maxmin [withscores] [limit offset count]               
	同上，改为从大到小排列。

image-20220609150418548 
1
2
3
4
zincrby <key> <increment> <value>      为元素的score加上增量
zrem  <key> <value>                    删除该集合下，指定值的元素 
zcount <key> <min> <max>               统计该集合，分数区间内的元素个数 
zrank <key> <value>                    返回该值在集合中的排名，从0开始。
image-20220609150659702

数据结构

SortedSet（Zset）是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String, Double>，可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。

zset底层使用了两个数据结构

（1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。

image-20220609151205065

（2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

跳跃表

1、简介

有序集合在生活中比较常见，例如根据成绩对学生排名，根据得分对玩家排名等。对于有序集合的底层实现，可以用数组、平衡树、链表等。数组不便元素的插入、删除；平衡树或红黑树虽然效率高但结构复杂；链表查询需要遍历所有效率低。Redis采用的是跳跃表。跳跃表效率堪比红黑树，实现远比红黑树简单。

2、实例

对比有序链表和跳跃表，从链表中查询出51

（1） 有序链表

image-20220609151358270

​ 要查找值为51的元素，需要从第一个元素开始依次查找、比较才能找到。共需要6次比较。

（2） 跳跃表

image-20220609151451111

​ 从第2层开始，1节点比51节点小，向后比较。

​ 21节点比51节点小，继续向后比较，后面就是NULL了，所以从21节点向下到第1层

​ 在第1层，41节点比51节点小，继续向后，61节点比51节点大，所以从41向下

​ 在第0层，51节点为要查找的节点，节点被找到，共查找4次。

发布和订阅

1、 打开一个客户端订阅channel1 

1
SUBSCRIBE channel1
image-20220611180236798

2、打开另一个客户端，给channel1发布消息hello

1
publish channel1 hello
image-20220611180325241

返回的1是订阅者数量

3、打开第一个客户端可以看到发送的消息

image-20220611180407001

注：发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息。

Redis6新数据类型

Bitmaps

简介

Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：

（1）Bitmaps本身不是一种数据类型，实际上它就是字符串(key-value) 但是它可以对字符串的位进行操作。

（2）Bitmaps单独提供了一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太相同。可以把Bitmaps想象成一个以位为单位的数组，数组的每个单元只能存储0和1，数组的下标在Bitmaps中叫做偏移量。

image-20220613153812668

实例

每个独立用户是否访问过网站存放在Bitmaps中， 将访问的用户记做1， 没有访问的用户记做0， 用偏移量作为用户的id。设置键的第offset个位的值（从0算起） ， 假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问， 那么当前Bitmaps初始化结果如图

image-20220613154031820

命令

setbit

1
setbit <key> <offset> <value>   设置Bitmaps中某个偏移量的值（0或1）;*offset:偏移量从0开始
image-20220613154142764 
1
2
3
4
5
注：

很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字。

在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。

getbit

1
getbit <key> <offset>   获取Bitmaps中某个偏移量的值;获取键的第offset位的值（从0开始算）
image-20220613154532255

bitcount
统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。

1
bitcount <key> [start end] 统计字符串从start字节到end字节比特值为1的数量
image-20220613154936251 
1
2
3
4
5
6
7
8
9
10
11
举例： K1 【01000001 01000000  00000000 00100001】，对应【0，1，2，3】
bitcount K1 1 2  ： 统计下标1、2字节组中bit=1的个数，即 01000000  00000000
--》bitcount K1 1 2 　　--》1

bitcount K1 1 3  ： 统计下标1、2字节组中bit=1的个数，即 01000000  00000000 00100001
--》bitcount K1 1 3　　--》3

bitcount K1 0 -2  ： 统计下标0到下标倒数第2，字节组中bit=1的个数，即 01000001  01000000   00000000
--》bitcount K1 0 -2　　--》3

注意：redis的setbit设置或清除的是bit位置，而bitcount计算的是byte位置。££

bitop

bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。

1
bitop  and(or/not/xor) <destkey> [key…]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
实例
2020-11-04 日访问网站的userid=1,2,5,9。
setbit unique:users:20201104 1 1
setbit unique:users:20201104 2 1
setbit unique:users:20201104 5 1
setbit unique:users:20201104 9 1

2020-11-03 日访问网站的userid=0,1,4,9。
setbit unique:users:20201103 0 1
setbit unique:users:20201103 1 1
setbit unique:users:20201103 4 1
setbit unique:users:20201103 9 1

计算出两天都访问过网站的用户数量
bitop and unique:users:and:20201104_03  unique:users:20201103  unique:users:20201104

image-20220613160253857

计算出任意一天都访问过网站的用户数量（例如月活跃就是类似这种） ， 可以使用or求并集

1
bitop or unique:users:or:20201104_03  unique:users:20201103  unique:users:20201104

image-20220613160613517

Bitmaps与Set对比

假设网站有1亿用户， 每天独立访问的用户有5千万， 如果每天用集合类型和Bitmaps分别存储活跃用户可以得到表

set和Bitmaps存储一天活跃用户对比
数据类型 每个用户id占用空间 需要存储的用户量 全部内存量
集合类型 64位 50000000 64位*50000000 = 400MB
Bitmaps 1位 100000000 1位*100000000 = 12.5MB
很明显， 这种情况下使用Bitmaps能节省很多的内存空间， 尤其是随着时间推移节省的内存还是非常可观的。
set和Bitmaps存储独立用户空间对比
数据类型 一天 一月 一年
集合类型 400MB 12GB 144GB
Bitmaps 12.5MB 375MB 4.5GB

但Bitmaps并不是万金油， 假如该网站每天的独立访问用户很少， 例如只有10万（大量的僵尸用户） ， 那么两者的对比如下表所示， 很显然， 这时候使用Bitmaps就不太合适了， 因为基本上大部分位都是0。

set和Bitmaps存储一天活跃用户对比（独立用户比较少）
数据类型 每个userid占用空间 需要存储的用户量 全部内存量
集合类型 64位 100000 64位*100000 = 800KB
Bitmaps 1位 100000000 1位*100000000 = 12.5MB
### HyperLogLog

简介

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。但像UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。

解决基数问题有很多种方案：

（1）数据存储在MySQL表中，使用distinct count计算不重复个数

（2）使用Redis提供的hash、set、bitmaps等数据结构来处理

以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。能否能够降低一定的精度来平衡存储空间？Redis推出了HyperLogLog

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数?

比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。

命令

pfadd

1
pfadd <key> <element> [element ...]   添加指定元素到 HyperLogLog 中
image-20220614150819292

pfcount

1
2
pfcount <key> [key ...]  计算HLL的近似基数，可以计算多个HLL
	比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可
image-20220614150947037

pfmerge

1
2
pfmerge<destkey><sourcekey> [sourcekey ...]  将一个或多个HLL合并后的结果存储在另一个HLL中
	比如每月活跃用户可以使用每天的活跃用户来合并计算可得
image-20220614151519938

Geospatial

简介

Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

命令

geoadd

1
geoadd <key><longitude> <latitude> <member> [longitude latitude member...]   添加地理位置（经度，纬度，名称）
image-20220614151945341
  • 两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。
  • 有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。
  • 当坐标位置超出指定范围时，该命令将会返回一个错误。
  • 已经添加的数据，是无法再次往里面添加的。

geopos

1
geopos <key> <member> [member...]  获得指定地区的坐标值
image-20220614152122713

geodist

1
geodist <key> <member1> <member2>  [m|km|ft|mi]  获取两个位置之间的直线距离
image-20220614152401647

单位：

  • ​ m 表示单位为米[默认值]。
  • ​ km 表示单位为千米。
  • ​ mi 表示单位为英里。
  • ​ ft 表示单位为英尺。
  • ​ 如果用户没有显式地指定单位参数， 那么 GEODIST 默认使用米作为单位

georadius

1
2
georadius <key> <longitude> <latitude> radius  m|km|ft|mi   以给定的经纬度为中心，找出某一半径内的元素
										经度         纬度     距离      单位
image-20220614152618638

Redis事务操作

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按 顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

Multi、Exec、Discard

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。组队的过程中可以通过discard来放弃组队。

image-20220716145220905

multi、exec

image-20220716145556212

multi、discard

image-20220716145710725

事务的错误处理

  • 如果组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。
  • 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

在组队队列中出现错误，整个队列取消操作

image-20220716150233717

在执行阶段出现错误，跳过错误命令，其他命令正常执行

image-20220716150601925

锁机制

悲观锁

悲观锁在执行时，会将其他处理数据库的请求拦截，使其他请求等待。

每次在修改数据的时候都会上锁，这样别人想要拿到这个数据就会block，直到它拿到锁，传统的关系型数据里面就用到了很多这样的锁机制，比如行锁、表锁、读锁，写锁，都在在做操做之前先上锁

这种锁算是真正意义的锁。不过这种方式有个缺点：效率低

乐观锁

乐观锁在执行时，不会将数据加锁，让其他数据库请求等待。

需要在执行修改操作的时候，比较一下原来的数据是否发生变化，如果没有变化就修改，有变化就不修改。

乐观锁适用于多读的应用类型，这样可以提高吞吐，redis就是使用这种chek—and—set机制实现事务的

在mysl中通常是使用version字段处理。

watch
  • 在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key被其他命令所改动，那么事务将被打断。

image-20220716152627560image-20220716152657763

unwatch

取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

事务三特性

  • 单独的隔离操作

​ 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

  • 没有隔离级别的概念

​ 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

  • 不保证原子性

​ 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis持久化

RDB (Redis DataBase)

  • 在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。
  • RDB默认开启，默认在当前启动路径下生成

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork

  • Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

  • 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”。

  • 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

    image-20220716180950653

redis.conf文件中SNAPSHOTTING快照参数

  • dbfilename dump.rdb

    • 在redis.conf中配置文件名称，默认为dump.rdb

  • save (不建议使用)

1
2
3
4
5
格式: save 秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
禁用:不设置save指令，或者给save传入空字符串

save时只管保存，其它不管，全部阻塞。手动保存。不建议。

  • bgsave (建议使用)：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求，推荐使用。

    • 可以通过lastsave命令获取最后一次成功执行快照的时间

  • stop-writes-on-bgsave-error

    • 当Redis无法写入磁盘的话，直接关掉Redis的写操作；推荐yes。

  • rdbcompression 压缩文件

    • 对于存储到磁盘中的快照，可以设置是否进行压缩存储。
    • 如果是的话，redis会采用LZF算法进行压缩。
    • 如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能；推荐yes。

  • rdbchecksum 检查完整性

    • 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能；推荐yes。

RDB恢复

  • 先通过config get dir 查询rdb文件的目录
  • 将*.rdb的文件拷贝到别的地方
  • rdb的恢复
    • 关闭Redis
    • 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
    • 启动Redis, 备份数据会直接加载

优势

  • 适合大规模的数据恢复
  • 对数据完整性和一致性要求不高更适合使用
  • 节省磁盘空间
  • 恢复速度快

劣势

  • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
  • 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
  • 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF (Append Only File)

  • 以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
  • AOF默认不开启

AOF开启

  • redis.conf 中 appendonly no 改为 appendonly yes
  • 配置文件中 appendfilename “appendonly.aof” 为默认aof文件名，可修改。
  • 默认和rdb文件位置相同

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF恢复/修复

  • AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

  • 正常恢复

    • 修改默认的appendonly no，改为yes
    • 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
    • 恢复：重启redis然后重新加载

  • 异常恢复

    • 修改默认的appendonly no，改为yes
    • 如遇到AOF文件损坏，通过redis-check-aof--fix appendonly.aof进行恢复
    • 备份被写坏的AOF文件
    • 恢复：重启redis，然后重新加载

AOF同步时间设置

  • appendfsync always

​ 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

  • appendfsync everysec

​ 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

  • appendfsync no

​ redis不主动进行同步，把同步时机交给操作系统。

Rewrite压缩

  • AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

  • 重写原理：AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

  • no-appendfsync-on-rewrite

    1
    2
    如果no-appendfsync-on-rewrite = yes,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
    如果no-appendfsync-on-rewrite = no,还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

  • 触发机制

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
      
    auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写。（文件是原来重写后文件的2倍时触发）
    auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。
      
    例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？————100MB
      
    系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size
      如果Redis  AOF当前大小 >= base_size + base_size * 100% (默认)
              且   当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

  • 重写流程

    1
    2
    3
    4
    5
    （1）bgrewriteaof 触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
    （2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。
    （3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区，保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
    （4）子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
    （5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

优势

  • 备份机制更稳健，丢失数据概率更低。
  • 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

  • 比起RDB占用更多的磁盘空间。
  • 恢复备份速度要慢。
  • 每次读写都同步的话，有一定的性能压力。
  • 存在个别Bug，造成恢复不能。

总结

  • 官方推荐两个都启用。
  • 如果对数据不敏感，可以选单独用RDB。
  • 不建议单独用 AOF，因为可能会出现Bug。
  • 如果只是做纯内存缓存，可以都不用。
1
2
3
4
5
6
7
8
9
10
11
性能建议：

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。

代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。

默认超过原大小100%大小时重写可以改到适当的数值。

官方建议

Redis主从复制

  • 主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slave以读为主。
  • 作用
    • 读写分离，性能扩展
    • 容灾快速恢复

image-20220716202209056

配置主从复制

image-20220717151826475

image-20220717155302826

1
2
3
4
include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

创建conf文件 image-20220717151920287

配置两个从机image-20220717152228902image-20220717152035861

在主机上写，在从机上可以读取数据，在从机上写数据报错

image-20220717152420940

注意⚠️

1
2
1、当从机down掉，重启后默认为master，需重新配置为从机，自动同步master数据。
2、当主机down掉，从机仍保持从机状态，主机恢复后仍为主机。

复制原理

1
2
3
4
5
6
1、Slave启动成功连接到master后会发送一个sync命令。（从机主动）
2、Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件（RDB）到slave,以完成一次完全同步。

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

薪火相传

  • 上一个slave可以是下一个slave的Master，slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。image-20220717154709983
1
2
3
4
5
6
7
用 slaveof  <ip> <port>
      6379 ——> 6380 ——> 6381
      master   slave   slave
      
中途变更转向：会清除之前的数据，重新建立拷贝最新数据。
⚠️风险是一旦某个slave宕机，后面的slave都没法备份。
主机挂了，从机还是从机，无法写数据。

反客为主

  • 当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
  • 用 slaveof no one 将从机变为主机，需要手动完成。

哨兵模式**(sentinel)**

  • 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1、Redis调整为一主二从模式，假设6379带着6380、6381
2、在自定义的/myredis目录下新建sentinel.conf文件
3、配置哨兵,填写内容
	sentinel monitor mymaster 127.0.0.1 6379 1
	其中 mymaster 为监控对象起的服务器名称， 1为至少有1个哨兵同意迁移。 
4、启动哨兵
	/usr/local/bin
	执行redis-sentinel  /myredis/sentinel.conf 
	redis做压测可以用自带的redis-benchmark工具
5、当主机挂掉，从机选举中产生新的主机

⚠️如何选举为主机
	根据优先级别：replica-priority  默认为100，值越小优先级越高(redis.conf中)
	原主机重启后会变为从机。

复制延时

  • 由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。

故障恢复

  • 偏移量：指获得原主机数据的完整度，偏移量越高代表与主机数据同步的完整性越高。
  • runid：每个redis实例启动后都会随机生成一个40位的runid

image-20220717163807561

Redis集群

  • 解决容量不够，并发写操作
  • Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
  • Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

集群配置

  1. 删除持久化数据，将rdb,aof文件都删除掉。

  2. 制作6个实例，6379,6380,6381,6389,6390,6391

    配置基本信息

    1
    2
    3
    4
    5
    6
    开启daemonize yes
    pid文件名字
    指定端口
    log文件名字
    dump.rdb 名字
    appendonly 关掉或者换名字

  3. redis cluster配置修改（redis6379.conf为例）

    1
    2
    3
    4
    5
    6
    7
    8
    9
    include /home/bigdata/redis.conf
    port 6379
    pidfile "/var/run/redis_6379.pid"
    dbfilename "dump6379.rdb"
    dir "/home/bigdata/redis_cluster"
    logfile "/home/bigdata/redis_cluster/redis_err_6379.log"
    cluster-enabled yes    打开集群模式
    cluster-config-file nodes-6379.conf  设定节点配置文件名
    cluster-node-timeout 15000   设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

  4. 拷贝多个redis.conf文件，修改内容（6380,6381,6389,6390,6391）

  5. 启动6个redis服务

  6. 将六个节点合成一个集群

    1. 组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常
1
2
3
4
5
redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6389 127.0.0.1:6390 127.0.0.1:6391

1、请用真实IP地址
2、--replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组。

1
2
3
4
5
6
7
普通方式登录
	redis-cli -p 6379
	⚠️采用普通方式登录可能会直接进入读主机，存储数据时，会出现MOVED重定向操作。所以，应该以集群方式登录。
	
集群方式登录 //-c 采用集群策略连接，设置数据会自动切换到相应的写主机
	redis-cli -c -p 6379  //任意节点都可以
  1. 通过 cluster nodes 命令查看集群信息
1
2
3
一个集群至少要有三个主节点。
选项 --cluster-replicas 1 表示为集群中的每个主节点创建一个从节点。
分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

slots

1
2
3
4
5
6
7
8
9
10
11
12
13
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

表示一个Redis集群包含16384个插槽（hash slot），数据库中的每个键都属于这16384个插槽的其中一个，集群使用公式 CRC16(key)%16384来计算键key属于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验和。

集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：
节点 A 负责处理 0 号至 5460 号插槽。
节点 B 负责处理 5461 号至 10922 号插槽。
节点 C 负责处理 10923 号至 16383 号插槽。

各节点之间数据相互独立，无法跨节点查看。

在集群中录入值

  • 在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。

  • redis-cli客户端提供了 –c 参数实现自动重定向。

    • 如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

    • 不在一个slot下的键值，不能使用mget,mset等多键操作。

通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。image-20220717192627528image-20220717192636459

查询集群中的值

  • CLUSTER GETKEYSINSLOT 返回 count 个 slot 槽中的键。image-20220717192730789

故障恢复

  • 如果主节点下线，从节点自动升为主节点
  • 主节点恢复后，主节点变成从机。
  • 如果所有某一段插槽的主从节点都宕掉（redis.conf中的参数 cluster-require-full-coverage）
    • cluster-require-full-coverage 为yes，整个集群都挂掉
    • cluster-require-full-coverage 为no，当前插槽数据不能使用，无法存储。

优势

  • 实现扩容
  • 分摊压力
  • 无中心配置相对简单

劣势

  • 多键操作是不被支持的
  • 多键的Redis事务是不被支持的。
  • lua脚本不被支持
  • 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

Redis应用问题解决

缓存穿透

  • 缓存和数据库都没有的数据，被大量请求

​ image-20220717203322523

​ 现象

  • 应用服务器压力变大
  • redis命中率降低
  • 一直查询数据库

解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

  1. 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
  2. 设置可访问的名单（白名单）：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
  3. 采用布隆过滤器：【布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。】将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
  4. 进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

缓存击穿

  • key对应的数据存在，但在redis中过期，此时有大量并发请求过来，缓存过期后从后端DB加载数据并返回设置到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

    image-20220717204538482

​ 现象

  • 数据库访问压力瞬时增加

  • redis中没有出现大量key过期

  • redis正常运行

解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

解决问题：

  1. 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长。
  2. 实时调整：现场监控热门数据，实时调整key的过期时长。
  3. 使用锁：
    • 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
    • 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key
    • 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
    • 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。
image-20220717204820172

缓存血崩

  • 缓存雪崩与缓存击穿的区别在于雪崩针对很多key缓存，击穿则是某一个key

    image-20220717205253121

​ 现象

  • 数据库压力变大服务器崩溃
  • 极少时间段内，大量key集中过期

解决方案

  1. 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）
  2. 使用锁或队列：
    用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
  3. 设置过期标志更新缓存：
    记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
  4. 将缓存失效时间分散开：
    比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

分布式锁

  • 单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问。

分布式锁主流的实现方案：

  • 基于数据库实现分布式锁
  • 基于缓存（Redis等） //性能好
  • 基于Zookeeper //可靠性高

redis实现分布式锁

使用setnx上锁，del释放锁（此方法锁一直存在，不会自动释放，可以设置key的过期时间）

  • set NX PX 10000

  • set NX EX 10

1
2
3
4
5
NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
 
EX second：设置键的过期时间为second秒。 SET key value EX second 效果等同于 SETEX key second value 。
 
PX millisecond：设置键的过期时间为millisecond毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
image-20220718101117096

UUID防误删

image-20220718100951137

image-20220718101029139

原子性操作

用LUA脚本保证删除的原子性

image-20220718102018301

Redis6.0新特性

ACL

  • Redis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。在Redis 5版本之前，Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb ， KEYS* ， shutdown 等。
  • Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 ：
    • 接入权限:用户名和密码
    • 可以执行的命令
    • 可以操作的 KEY

命令

1
AUTH  <username>  <password>   --切换用户

acl list

image-20220718105731639

acl cat

1
2
ACL CAT     -- 列出可用的类别.
ACL CAT <category>    -- 列出指定类别中的命令.

acl whoami

1
ACL WHOAMI   -- 返回当前的连接用户.

acl setuser

1
2
3
ACL SETUSER <username> [attribs ...] -- 创建或则修改一个用户.
ACL GETUSER <username>               -- 得到一个用户的详细信息.
ACL DELUSER <username> [...]         -- 删除列表中的用户.

IO多线程

  • IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。

  • 多线程IO默认也是不开启的，需要再配置文件中配置

    io-threads-do-reads yes

    io-threads 4

Redis6新功能还有：

1、RESP3新的 Redis 通信协议：优化服务端与客户端之间通信

2、Client side caching客户端缓存：基于 RESP3 协议实现的客户端缓存功能。为了进一步提升缓存的性能，将客户端经常访问的数据cache到客户端。减少TCP网络交互。

3、Proxy集群代理模式：Proxy 功能，让 Cluster 拥有像单实例一样的接入方式，降低大家使用cluster的门槛。不过需要注意的是代理不改变 Cluster 的功能限制，不支持的命令还是不会支持，比如跨 slot 的多Key操作。

4、Modules API

Redis 6中模块API开发进展非常大，因为Redis Labs为了开发复杂的功能，从一开始就用上Redis模块。Redis可以变成一个框架，利用Modules来构建不同系统，而不需要从头开始写然后还要BSD许可。Redis一开始就是一个向编写各种系统开放的平台。