官网链接:http://www.redis.io

视频:Redis 6 尚硅谷

# 一、NoSQL 数据库简介

# 1- 技术发展

技术的分类

1、解决功能性的问题:Java、Jsp、RDBMS、Tomcat、HTML、Linux、JDBC、SVN
2、解决扩展性的问题:Struts、Spring、SpringMVC、Hibernate、Mybatis
3、解决性能的问题:NoSQL、Java 线程、Hadoop、Nginx、MQ、ElasticSearch

# 1.1.1. Web1.0 时代

Web1.0 的时代,数据访问量很有限,用一夫当关的高性能的单点服务器可以解决大部分问题。

image-20220726231113112

# 1.1.2. Web2.0 时代

随着 Web2.0 的时代的到来,用户访问量大幅度提升,同时产生了大量的用户数据。加上后来的智能移动设备的普及,所有的互联网平台都面临了巨大的性能挑战。

image-20220726231129462

# 1.1.3. 解决 CPU 及内存压力

image-20220726231204844

# 1.1.4. 解决 IO 压力

image-20220726231220567

# 2 - NoSQL 数据库

# 1.2.1. NoSQL 数据库概述

NoSQL(NoSQL = Not Only SQL ),意即 “不仅仅是 SQL”,泛指 非关系型 的数据库。
NoSQL 不依赖业务逻辑方式存储,而以简单的 key-value 模式存储。因此大大的增加了数据库的扩展能力。

  • 不遵循 SQL 标准。
  • 不支持 ACID。
  • 远超于 SQL 的性能。

# 1.2.2. NoSQL 适用场景

  • 对数据高并发的读写
  • 海量数据的读写
  • 对数据高可扩展性的

# 1.2.3. NoSQL 不适用场景

  • 需要事务支持

  • 基于 sql 的结构化查询存储,处理复杂的关系,需要 即席 查询。

  • (用不着 sql 的和用了 sql 也不行的情况,请考虑用 NoSql)

# 1.2.4. Memcache

image-20220726231803375

# 1.2.5. Redis

image-20220726231821129

# 1.2.6. MongoDB

image-20220726231850038

# 3 - 行式存储数据库(大数据时代)

# 1.3.1. 行式数据库

image-20220726232027994

# 1.3.2. 列式数据库

image-20220726232035860

1.3.2.1. Hbase

image-20220726232045024

HBase 是 Hadoop 项目中的数据库。它用于需要对大量的数据进行随机、实时的读写操作的场景中。
HBase 的目标就是处理数据量非常庞大的表,可以用普通的计算机处理超过 10 亿行数据,还可处理有数百万元素的数据表。

1.3.2.2. Cassandra[kəˈsændrə]

image-20220727003413693

Apache Cassandra 是一款免费的开源 NoSQL 数据库,其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集 (数据量通常达到 PB 级别)。在众多显著特性当中,Cassandra 最为卓越的长处是对写入及读取操作进行规模调整,而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。

计算机存储单位 计算机存储单位一般用BKBMBGBTBEBZBYBBB来表示,它们之间的关系是:
位 bit (比特)(Binary Digits):存放一位二进制数,即 01,最小的存储单位。
字节 byte8个二进制位为一个字节(B),最常用的单位。
1KB (Kilobyte 千字节)=1024B,
1MB (Megabyte 兆字节 简称“兆”)=1024KB
1GB (Gigabyte 吉字节 又称“千兆”)=1024MB
1TB (Trillionbyte 万亿字节 太字节)=1024GB,其中1024=2^10 ( 210次方)
1PBPetabyte 千万亿字节 拍字节)=1024TB
1EBExabyte 百亿亿字节 艾字节)=1024PB
1ZB (Zettabyte 十万亿亿字节 泽字节)= 1024 EB,
1YB (Jottabyte 一亿亿亿字节 尧字节)= 1024 ZB,
1BB (Brontobyte 一千亿亿亿字节)= 1024 YB.
注:“兆”为百万级数量单位。

# 4- 图关系型数据库

image-20220727003806092

主要应用:社会关系,公共交通网络,地图及网络拓谱 (n*(n-1)/2)

image-20220727003831658

# 5 - DB-Engines 数据库排名

http://db-engines.com/en/ranking

image-20220727003904477

# 二、Redis 概述安装

  • Redis 是一个 开源key-value 存储系统。
  • 和 Memcached 类似,它支持存储的 value 类型相对更多,包括 string (字符串)、 list (链表)、 set (集合)、 zset (sorted set -- 有序集合) 和 hash (哈希类型)
  • 这些数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作,而且这些操作都是 原子性
  • 在此基础上,Redis 支持各种不同方式的 排序
  • 与 memcached 一样,为了保证效率,数据都是 缓存在内存 中。
  • 区别的是 Redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。
  • 并且在此基础上实现了 master-slave(主从) 同步。

# 1 - 应用场景

# 2.1.1. 配合关系型数据库做高速缓存

  • 高频次,热门访问的数据,降低数据库 IO
  • 分布式架构,做 session 共享
  • image-20220727004314790

# 2.1.2. 多样的数据结构存储持久化数据

image-20220727004344728

# 2 - Redis 安装

Redis 官方网站: http://redis.io

Redis 中文官方网站: http://redis.cn/

参考链接:linux 系统安装和使用 Redis - 知乎 (zhihu.com)

image-20220727004514512

# 2.2.1. 安装版本

  • 6.2.1 for Linux(redis-6.2.1.tar.gz)
  • 不用考虑在 windows 环境下对 Redis 的支持 (如果真的需要可以去 github 上找找)

# 2.2.2. 安装步骤

2.2.2.1. 准备工作:下载安装最新版的 gcc 编译器
安装 C 语言的编译环境

yum install centos-release-scl scl-utils-build
yum install -y devtoolset-8-toolchain
scl enable devtoolset-8 bash
# 测试 gcc 版本 
gcc --version

image-20220727104704322

2.2.2.2. 下载 redis-6.2.1.tar.gz 放 /opt 目录

2.2.2.3. 解压命令:tar -zxvf redis-6.2.1.tar.gz

2.2.2.4. 解压完成后进入目录:cd redis-6.2.1

2.2.2.5. 在 redis-6.2.1 目录下再次执行 make 命令(只是编译好)

2.2.2.6. 如果没有准备好 C 语言编译环境,make 会报错 —Jemalloc/jemalloc.h:没有那个文件

image-20220727104834499

2.2.2.7. 解决方案:运行 make distclean

image-20220727104852287

2.2.2.8. 在 redis-6.2.1 目录下再次执行 make 命令(只是编译好)

image-20220727104906795

2.2.2.9. 跳过 make test 继续执行: make install

image-20220727104934592

# 实操

  1. 安装依赖,因为 Redis 是基于 C 语言编写的,因此首先需要安装 Redis 所需要的 gcc 依赖
yum install -y gcc tcl

image-20220727155634575

  1. 上传文件:我上传到了 /opt 目录下

  2. 解压: tar -zxvf redis-6.2.7.tar.gz

  3. cd 到该目录:cd redis-6.2.7

  4. make: 编译 make 这个完成之后 make install

image-20220727161333762

image-20220727161816964

默认安装路径:usr/local/bin/

image-20220727161855947

使用推荐的后台启动方式,需要对 redis.conf 备份一份

cp redis.conf redis.conf.copy

image-20220727162452302

# 2.2.3. 安装目录:/usr/local/bin

查看默认安装目录:
redis-benchmark : 性能测试工具,可以在自己本子运行,看看自己本子性能如何
redis-check-aof: 修复有问题的 AOF 文件,rdb 和 aof 后面讲
redis-check-dump:修复有问题的 dump.rdb 文件
redis-sentinel:Redis 集群使用
redis-server :Redis 服务器启动命令
redis-cli :客户端,操作入口

# 2.2.4. 前台启动(不推荐)

前台启动,命令行窗口不能关闭,否则服务器停止

redis-server

image-20220727105158482

# 2.2.5. 后台启动(推荐)

2.2.5.1. 备份 redis.conf

拷贝一份 redis.conf 到其他目录
cp /opt/redis-3.2.5/redis.conf /myredis

2.2.5.2. 后台启动设置 daemonize no 改成 yes

修改 redis.conf (128 行) 文件将里面的 daemonize no 改成 yes,让服务在后台启动

2.2.5.3. Redis 启动

redis-server/myredis/redis.conf 你的这个配置文件在那个文件夹下就执行哪个文件夹的配置配置文件

image-20220727105349213

2.2.5.4. 用客户端访问: redis-cli

image-20220727105413882

2.2.5.5. 多个端口可以: redis-cli -p6379
2.2.5.6. 测试验证: ping

image-20220727105506029

2.2.5.7. Redis 关闭

单实例关闭: redis-cli shutdown

image-20220727105606303

也可以进入终端后再关闭

image-20220727105620164

多实例关闭,指定端口关闭: redis-cli -p 6379 shutdown

# 2.2.6. Redis 介绍相关知识

image-20220727105742074

Redis 是单线程 + 多路 IO 复用技术

多路复用是指使用一个线程来检查多个文件描述符(Socket)的就绪状态,比如调用 select 和 poll 函数,传入多个文件描述符,如果有一个文件描述符就绪,则返回,否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行,也可以启动线程执行(比如使用线程池)

串行 vs 多线程+锁(memcached) vs 单线程+多路IO复用(Redis)

(与 Memcache 三点不同:支持多数据类型,支持持久化,单线程 + 多路 IO 复用)

image-20220727105854506

# 三、常用五大数据类型

哪里去获得 redis 常见数据类型操作命令 http://www.redis.cn/commands.html

# 1 - Redis 键 (key)

key:

命令:
  (1)keys * : 查看当前库所有key    (匹配:keys *1)
  (2)exists key: 判断某个key是否存在
  (3)type key : 查看你的key是什么类型
  (4)del key  : 删除指定的key数据
  (5)unlink key : 根据value选择非阻塞删除(仅将keys从keyspace元数据中删除,真正的删除会在后续异步操作)
  (6)expire key 10 : 10秒钟,为给定的key设置过期时间
  (7)ttl key : 查看还有多少秒过期,-1表示永不过期,-2表示已过期
  (8)select  : 命令切换数据库
  (9)dbsize  : 查看当前数据库的key的数量
  (10)flushdb : 清空当前库
  (11)flushall: 通杀全部库

# 2 - Redis 字符串 (String)

# 3.2.1. 简介

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

# 3.2.2. 常用命令

String: k- key (键) v-value (值)

命令:
  (1)存:set k v  [另说明见下!]
  (2)取:get k         
  (3)追加字符:append k "追加字段" 
  (4)长度:strlen k
  (5)无该key时存:setnx k v:(只有在 key 不存在时设置 key 的值)
  (6)增指定值:incrby k [integer]
  (7)减指定值:decrby k [integer]
  (8)递增:incr k (一定是整数;如无值则赋0后加1)
  (9)递键:decr k (一定是整数;如无值则赋0后减1)
  
其他命令:
  (1)批量存:mset k1 v1 k2 v2...
  (2)批量取:mget k1 k2 k3 ....         
  (3)批量存:msetnx k1 v1 k2 v2...(当且仅当所有给定 key 都不存在,原子性,有一个失败则都失败)
  (4)范围取:getrange k 起始位置 结束位置(类似java中的substring,前包,后包)
  (5)取全部数据:getrange k 0 -1
  (6)覆盖值:setrange k 起始位置 v (<value>覆写<key>所储存的字符串值,从<起始位置>开始(索引从0开始))
  (7)过期时间:setex k 过期时间 value (设置键值的同时,设置过期时间,单位秒)
  (8)以新换旧:getset k v (设置了新值同时获得旧值)

存 set 的说明:

image-20220727111440940

  • NX:当数据库中 key 不存在时,可以将 key-value 添加数据库
  • XX:当数据库中 key 存在时,可以将 key-value 添加数据库,与 NX 参数互斥
  • EX:key 的超时秒数
  • PX:key 的超时毫秒数,与 EX 互斥

image-20220727113031192

image-20220727113111389

上面的值可能是 2~200,因为 i++ 不是原子操作,它分三步完成:获取 i 的值,进行 + 操作,赋值

# 3.2.3. 数据结构

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

image-20220727123548075

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

# 3 - Redis 列表 (List)

# 3.3.1. 简介

单键多值
Redis 列表是简单的字符串列表,按照插入顺序排序。你可以添加一个元素到列表的头部(左边)或者尾部(右边)。

它的底层实际是个 双向链表 ,对两端的操作性能很高,通过索引下标的操作中间的节点性能会较差。

image-20220727123852045

# 3.3.2. 常用命令

list:

概述:
元素插入
链表表头或结尾插入:高效,中间:低
存储list:
1.ArrayList使用数组方式:使用索引查询-块,新增删除时涉及位移操作-慢
2.LinkedList使用双向链接方式:每个元素记录前后元素指针
3.双向链表增加数据
4.双向链表删除数据
存储list常用命令:
`1.两端添加:lpush、rpush`
lpush list 1 2 3 #从左侧往 list 表中插入 1 2 3
rpush list a b c #从右侧往 list 表中插入 a b c 
`2.查看列表:lrange`
lrange list 0 -1 #从头到尾查看
lrange list 0 5  #从开始到第 5 个查看
`3.两端弹出:lpop、rpop (值在键在,值光键亡)`
lpop list #从左边弹出第一个数
rpop list #从尾部弹出第一个数
`4.获取列表元素个数:llen`
llen list #查看元素个数
`5.扩展命令:lpushx、rpushx、lrem、lset、rpoplppush`
lpushx list x #插入 x 到 list 表的开头(左边)
rpushx list y #插入 y 到 list 表的尾部(右边)
lrem list n value #从头到尾删除 n 个 value
lrem list 2 3 #从头到尾删除 2 个 3 (从左到右)
lrem list -2 1  #从尾到头删除 2 个 1(从右到左)
lrem list 0 2	#删除所有 2
lset key n value 	#在 key 表第 n 个角标设置为 value
lset list 3 mmm 	#在 list 表第 3 个角标设置 mmm
linset list before a yy	 #在 list 表中 a 之前插入 yy
linset list after b xx 	#在 list 表中 b 之后插入 xx
rpoplpush list1 list2 	#从 list1 表的右边吐出压入到 list2 表的左边

# 3.3.3. 数据结构

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

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

它将所有的元素紧挨着一起存储,分配的是一块连续的内存。

当数据量比较多的时候才会改成 quicklist

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

image-20220727135259344

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

# 4 - Redis 集合 (Set)

# 3.4.1. 简介

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

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

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

# 3.4.2. 常用命令

Set:

Redis数据结构(Set): List允许出现重复数据,Set不允许出现重复数据;Set最大元素数量是4294967295
命令:
  (1)存:sadd 列名 [...]
  (2)删:srem 列名 [...]
  (3)查全:smembers 列名
  (4)查是否存在:sismember 列名 值,1表示存在,0表示不存在
  (5)差集:sdiff 列名1 列名2 ((列1中的,不包含在列2中的)
  (6)交集:sinter 列名1 列名2
  (7)并集:sunion 列名1 列名2
  (8)查数量:scard 列名
  (9)随机查<n>个值:srandmember 列名 <n>(不会从集合中删除)
  (10)随机吐出一个值:spop 列名
  (11)从集合A的值移动到集合B:smove 列名1 列名2 值 
  (12)将差集存到新集合中:sdiffstore 新列名 列名1 列名2
  (13)将交集存到新集合中:sinterstore 新列名 列名1 列名2
  (14)将并集存到新集合中:sunionstore 新列名 列名1 列名2

# 3.4.3. 数据结构

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

Java 中 HashSet 的内部实现使用的是 HashMap,只不过所有的 value 都指向同一个对象。Redis 的 set 结构也是一样,它的内部也使用 hash 结构,所有的 value 都指向同一个内部值。

# 5 - Redis 哈希 (Hash)

# 3.5.1. 简介

Redis hash 是一个键值对集合。

Redis hash 是一个 string 类型的 fieldvalue 的映射表,hash 特别适合用于 存储对象
类似 Java 里面的 Map<String,Object>

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

主要有以下 2 种存储方式:

image-20220727140611227

# 3.5.2. 常用命令

Hash:

常用存储类型(Hash):每个可存4294967295个键值对
命令: 表名(key)(field)(value)
  (1)存:hset 表名 域 值 
  (2)批量存:hmset 表名 域 值 域 值...
  (2)取:hget 表名 域
  (4)批量取:hmget 表名 域 域 ...
  (5)取全:hgetall 表名
  (6)删除:hdel 表名 域...
  (7)全删:del 表名
  (8)增指定值:hincrby 表名 域 [integer](一定是整数)
  (9)判断存在:hexists 表名 域 (查看哈希表 key 中,给定域 field 是否存在)
  (10)设置域值:hsetnx 表名 f v (将hash表中域f的值设置为v,当且仅当field不存在时)
  (11)键值对数量:hlen 表名
  (12)取所有域():hkeys 表名(列出所有的field)
  (13)取所有值:hvals 表名(列出所有的value)

# 3.5.3. 数据结构

Hash 类型对应的数据结构是两种: ziplist (压缩列表), hashtable (哈希表)。当 field-value 长度较短且个数较少时,使用 ziplist,否则使用 hashtable。

# 6 - Redis 有序集合 Zset (sorted set)

# 3.6.1. 简介

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

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

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

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

# 3.6.2. 常用命令

Zset:

命令: 集合名(key) 评分(score)(value)
  (1)``:zadd 集合名 评分1 值1 评分2 值2...
  (2)`按下标取`:zrange 集合名 下标1 下标2 [WITHSCORES] 
  (返回有序集 key 中,下标在<下标1> <下标2>之间的元素,带WITHSCORES,可以让分数一起和值返回到结果集)
  (3)`按评分取`:zrangebyscore 集合名 min max [withscores] [limit offset count]
  (返回有序集 key 中,所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列)
  (4)`从大到小取`:zrevrangebyscore 集合名 max min [withscores] [limit offset count]   (同上,改为从大到小排列。)
  (5)`增指定值`:zincrby 集合名 增量 值(给值加上增量)
  (6)`删除`:zrem 集合名 值 
  (7)`统计`:zcount 集合名 min max (统计该集合,分数区间内的元素个数)
  (8)`排名`:zrank 集合名 值 (返回该值在集合中的排名,从0开始)

案例:如何利用 zset 实现一个文章访问量的排行榜?

# 3.6.3. 数据结构

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

zset 底层使用了两个数据结构
(1)hash,hash 的作用就是关联元素 value 和权重 score,保障元素 value 的唯一性,可以通过元素 value 找到相应的 score 值。
(2)跳跃表,跳跃表的目的在于给元素 value 排序,根据 score 的范围获取元素列表。

# 3.6.4. 跳跃表(跳表)

1、简介

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

2、实例

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

(1)有序链表

image-20220727150205067

要查找值为 51 的元素,需要从第一个元素开始依次查找、比较才能找到。共需要 6 次比较。
(2)跳跃表

image-20220727150256931

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

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

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

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

从此可以看出跳跃表比有序链表效率要高

# 四、Redis 配置文件介绍

我的目录:/opt/redis-6.2.7/redis.conf

# 1- Units 单位

配置大小单位,开头定义了一些基本的度量单位,只支持 bytes,不支持 bit 大小写不敏感

image-20220730115141232

# 2- INCLUDES 包含

类似 jsp 中的 include,多实例的情况可以把公用的配置文件提取出来

image-20220730115303933

# 3 - 网络相关配置

# 4.3.1 bind

默认情况 bind=127.0.0.1 只能接受本机的访问请求

不写的情况下,无限制接受任何 ip 地址的访问

生产环境肯定要写你应用服务器的地址;服务器是需要远程访问的,所以需要将其注释掉

如果开启了 protected-mode,那么在没有设定 bind ip 且没有设密码的情况下,Redis 只允许接受本机的响应

image-20220730141422593

保存配置,停止服务,重启启动查看进程,不再是本机访问了。

image-20220730114744786

# 4.3.2. protected-mode

将本机访问保护模式设置 no

image-20220730141730607

# 4.3.3 Port

端口号,默认 6379

image-20220730141828893

# 4.3.4. tcp-backlog

设置 tcp 的 backlog,backlog 其实是一个连接队列,backlog 队列总和 = 未完成三次握手队列 + 已经完成三次握手队列。

在高并发环境下你需要一个高 backlog 值来避免慢客户端连接问题。

注意 Linux 内核会将这个值减小到 /proc/sys/net/core/somaxconn 的值(128),所以需要确认增大 /proc/sys/net/core/somaxconn 和 /proc/sys/net/ipv4/tcp_max_syn_backlog(128)两个值来达到想要的效果

image-20220730142147649

# 4.3.5. timeout

一个空闲的客户端维持多少秒会关闭,0 表示关闭该功能。即永不关闭

image-20220730142318928

# 4.3.6. tcp-keepalive

对访问客户端的一种心跳检测,每个 n 秒检测一次。

单位为秒,如果设置为 0,则不会进行 Keepalive 检测,建议设置成 60

image-20220730143102388

# 4 - GENERAL 通用

# 4.4.1. daemonize

是否为后台进程,设置为 yes

守护进程,后台启动

image-20220730143234823

# 4.4.2. pidfile

存放 pid 文件的位置,每个实例会产生一个不同的 pid 文件

image-20220730143450301

# 4.4.3. loglevel

指定日志记录级别,Redis 总共支持四个级别:debug、verbose、notice、warning,默认为 notice

四个级别根据使用阶段来选择,生产环境选择 notice 或者 warning

image-20220730143541853

# 4.4.4. logfile

日志文件名称

image-20220730143639134

# 4.4.5. databases 16

设定库的数量 默认 16,默认数据库为 0,可以使用 SELECT 命令在连接上指定数据库 id

image-20220730143726917

# 5 - SECURITY 安全

# 5.5.1. 设置密码

image-20220730144004826

访问密码的查看、设置和取消

在命令中设置密码,只是临时的。重启 redis 服务器,密码就还原了。

永久设置,需要再配置文件中进行设置。

image-20220730144237188

# 6 - LIMITS 限制

# 6.6.1. maxclients

  • 设置 redis 同时可以与多少个客户端进行连接。

  • 默认情况下为 10000 个客户端。

  • 如果达到了此限制,redis 则会拒绝新的连接请求,并且向这些连接请求方发出 “max number of clients reached” 以作回应。

image-20220730144953788

# 6.6.2. maxmemory

  • 建议必须设置,否则,将内存占满,造成服务器宕机

  • 设置 redis 可以使用的内存量。一旦到达内存使用上限,redis 将会试图移除内部数据,移除规则可以通过 maxmemory-policy 来指定。

  • 如果 redis 无法根据移除规则来移除内存中的数据,或者设置了 “不允许移除”,那么 redis 则会针对那些需要申请内存的指令返回错误信息,比如 SET、LPUSH 等。

  • 但是对于无内存申请的指令,仍然会正常响应,比如 GET 等。如果你的 redis 是主 redis(说明你的 redis 有从 redis),那么在设置内存使用上限时,需要在系统中留出一些内存空间给同步队列缓存,只有在你设置的是 “不移除” 的情况下,才不用考虑这个因素。

image-20220730145049188

# 6.6.3. maxmemory-policy

  • volatile-lru:使用 LRU 算法移除 key,只对设置了过期时间的键;(最近最少使用)

  • allkeys-lru:在所有集合 key 中,使用 LRU 算法移除 key

  • volatile-random:在过期集合中移除随机的 key,只对设置了过期时间的键

  • allkeys-random:在所有集合 key 中,移除随机的 key

  • volatile-ttl:移除那些 TTL 值最小的 key,即那些最近要过期的 key

  • noeviction:不进行移除。针对写操作,只是返回错误信息

image-20220730145143860

# 6.6.4. maxmemory-samples

  • 设置样本数量,LRU 算法和最小 TTL 算法都并非是精确的算法,而是估算值,所以你可以设置样本的大小,redis 默认会检查这么多个 key 并选择其中 LRU 的那个。

  • 一般设置 3 到 7 的数字,数值越小样本越不准确,但性能消耗越小。

image-20220730145234892

# 五、Redis 的发布和订阅

# 1- 什么是发布和订阅

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

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

# 2- Redis 的发布和订阅

1、客户端可以订阅频道如下图

image-20220730145408989

2、当给这个频道发布消息后,消息就会发送给订阅的客户端

image-20220730145420014

# 3- 发布订阅命令行实现

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

image-20220730145530661

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

image-20220730145549967

返回的 1 是订阅者数量
3、打开第一个客户端可以看到发送的消息

image-20220730145629320

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

# 六、Redis 新数据类型

# 1- Bitmaps

# 6.1.1. 简介

现代计算机用二进制(位) 作为信息的基础单位, 1 个字节等于 8 位, 例如 “abc” 字符串是由 3 个字节组成, 但实际在计算机存储时将其用二进制表示, “abc” 分别对应的 ASCII 码分别是 97、 98、 99, 对应的二进制分别是 01100001、 01100010 和 01100011,如下图

image-20220730145703500

合理地使用操作位能够有效地提高内存使用率和开发效率。
Redis 提供了 Bitmaps 这个 “数据类型” 可以实现对位的操作:
(1) Bitmaps 本身不是一种数据类型, 实际上它就是字符串(key-value) , 但是它可以对字符串的位进行操作。
(2) Bitmaps 单独提供了一套命令, 所以在 Redis 中使用 Bitmaps 和使用字符串的方法不太相同。 可以把 Bitmaps 想象成一个以位为单位的数组, 数组的每个单元只能存储 0 和 1, 数组的下标在 Bitmaps 中叫做偏移量。

image-20220730145718081

# 6.1.2. 命令

命令:
  (1)存:setbit
  (2)取:getbit
  (3)统计:bitcount
  (4)并/交/异或操作:bitop
详见下列很实例示范。

1、 setbit
(1)格式
**setbit** 设置 Bitmaps 中某个偏移量的值(0 或 1)

image-20220730145758337

offset :偏移量从 0 开始

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

image-20220730145816388

unique:users:20201106 代表 2020-11-06 这天的独立访问用户的 Bitmaps

image-20220730150000867

注:💡
很多应用的用户 id 以一个指定数字(例如 10000) 开头, 直接将用户 id 和 Bitmaps 的偏移量对应势必会造成一定的浪费, 通常的做法是每次做 setbit 操作时将用户 id 减去这个指定数字。
在第一次初始化 Bitmaps 时, 假如偏移量非常大, 那么整个初始化过程执行会比较慢, 可能会造成 Redis 的阻塞。

2、 getbit
(1)格式
**getbit** 获取 Bitmaps 中某个偏移量的值

image-20220730150357659

获取键的第 offset 位的值(从 0 开始算)

(2)实例
获取 id=8 的用户是否在 2020-11-06 这天访问过, 返回 0 说明没有访问过:

image-20220730150425467

注:因为 100 根本不存在,所以也是返回 0

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

image-20220730150503473

(2)实例
计算 2022-11-06 这天的独立访问用户数量

image-20220730150516584

start 和 end 代表起始和结束字节数, 下面操作计算用户 id 在第 1 个字节到第 3 个字节之间的独立访问用户数, 对应的用户 id 是 11, 15, 19。

image-20220730150532060

举例:💡

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 位置。bit(位)byte(字节)

4、 bitop
(1) 格式
bitop and (or/not/xor) [key…]

image-20220731112131913

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

(2) 实例

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-20220731112424506

image-20220731112608764

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

image-20220731112642593

# 6.1.3. Bitmaps 与 set 对比

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

很明显, 这种情况下使用 Bitmaps 能节省很多的内存空间, 尤其是随着时间推移节省的内存还是非常可观的

image-20220731112933430

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

# 2 - HyperLogLog

# 6.2.1. 简介

在工作当中,我们经常会遇到与统计相关的功能需求,比如统计网站 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。 基数估计就是在误差可接受的范围内,快速计算基数。

# 6.2.2. 命令

命令:
  (1)存:pfadd
  (2)去重统计(可并集):pfcount
  (3)取并集(生成新数据):pfmerge
详见下列实例

1、 pfadd
(1)格式
pfadd < element> [element …] 添加指定元素到 HyperLogLog 中

image-20220731161114528

(2)实例

image-20220731161148573

将所有元素添加到指定 HyperLogLog 数据结构中。如果执行命令后 HLL 估计的近似基数发生变化,则返回 1,否则返回 0。

2、 pfcount
(1)格式
pfcount [key …] 计算 HLL 的近似基数,可以计算多个 HLL,比如用 HLL 存储每天的 UV,计算一周的 UV 可以使用 7 天的 UV 合并计算即可

image-20220731161256514

(2)实例

image-20220731161305107

3、 pfmerge
(1)格式
pfmerge [sourcekey …] 将一个或多个 HLL 合并后的结果存储在另一个 HLL 中,比如每月活跃用户可以使用每天的活跃用户来合并计算可得

image-20220731161447288

(2)实例

image-20220731161510641

# 3- Geospatial

# 6.3.1. 简介

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

# 6.3.2. 命令

命令:
   (1)存:geoadd
   (2)取:geopos
   (3)直线距离:geodist
   (4)指定中心、半径内的元素:georadius、
详见下列实例

1、 geoadd

(1)格式
geoadd< longitude> [longitude latitude member…] 添加地理位置(经度,纬度,名称)

image-20220731161856254

(2)实例

geoadd china:city 121.47 31.23 shanghai
geoadd china:city 106.50 29.53 chongqing 114.05 22.52 shenzhen 116.38 39.90 beijing

image-20220731161919961

两极无法直接添加,一般会下载城市数据,直接通过 Java 程序一次性导入。

有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。

当坐标位置超出指定范围时,该命令将会返回一个错误。
已经添加的数据,是无法再次往里面添加的。

2、 geopos

(1)格式
geopos [member…] 获得指定地区的坐标值

image-20220731162347572

(2)实例

image-20220731162359258

3、 geodist

(1)格式
geodist [m|km|ft|mi ] 获取两个位置之间的直线距离

image-20220731162423033

(2)实例
获取两个位置之间的直线距离

image-20220731162458356

单位:

m 表示单位为米[默认值]
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。

如果用户没有显式地指定单位参数, 那么 GEODIST 默认使用米作为单位

4、 georadius
(1)格式
georadius< longitude>radius m|km|ft|mi 以给定的经纬度为中心,找出某一半径内的元素

image-20220731162604335

经度 纬度 距离 单位

(2)实例

image-20220731162630641

# 七、Redis_Jedis_测试

# 1 - Jedis 所需要的 jar 包

<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.2.0</version>
</dependency>

# 2 - 连接 Redis 注意事项

禁用 Linux 的防火墙:Linux (CentOS7) 里执行命令

systemctl stop/disable firewalld.service   
redis.conf中注释掉bind 127.0.0.1 ,然后 protected-mode no

# 3 - Jedis 常用操作

# 7.3.1. 创建动态的工程

# 7.3.2. 创建测试程序

package com.atguigu.jedis;
import redis.clients.jedis.Jedis;
public class Demo01 {
    public static void main(String[] args) {
        Jedis jedis = new Jedis("192.168.137.3",6379);
        String pong = jedis.ping();
        System.out.println("连接成功:"+pong);
        jedis.close();
    }
}

# 4 - 测试相关数据类型

# 7.4.1. Jedis-API: Key

jedis.set("k1", "v1");
jedis.set("k2", "v2");
jedis.set("k3", "v3");
Set<String> keys = jedis.keys("*");
System.out.println(keys.size());
for (String key : keys) {
	System.out.println(key);
}
System.out.println(jedis.exists("k1"));
System.out.println(jedis.ttl("k1"));                
System.out.println(jedis.get("k1"));

# 7.4.2. Jedis-API: String

jedis.mset("str1","v1","str2","v2","str3","v3");
System.out.println(jedis.mget("str1","str2","str3"));

# 7.4.3. Jedis-API: List

List<String> list = jedis.lrange("mylist",0,-1);
for (String element : list) {
	System.out.println(element);
}

# 7.4.4. Jedis-API: set

jedis.sadd("orders", "order01");
jedis.sadd("orders", "order02");
jedis.sadd("orders", "order03");
jedis.sadd("orders", "order04");
Set<String> smembers = jedis.smembers("orders");
for (String order : smembers) {
	System.out.println(order);
}
jedis.srem("orders", "order02");

# 7.4.5. Jedis-API: hash

jedis.hset("hash1","userName","lisi");
System.out.println(jedis.hget("hash1","userName"));
Map<String,String> map = new HashMap<String,String>();
map.put("telphone","13810169999");
map.put("address","atguigu");
map.put("email","abc@163.com");
jedis.hmset("hash2",map);
List<String> result = jedis.hmget("hash2", "telphone","email");
for (String element : result) {
	System.out.println(element);
}

7.4.6. Jedis-API: zset

jedis.zadd("zset01", 100d, "z3");
jedis.zadd("zset01", 90d, "l4");
jedis.zadd("zset01", 80d, "w5");
jedis.zadd("zset01", 70d, "z6");
Set<String> zrange = jedis.zrange("zset01", 0, -1);
for (String e : zrange) {
	System.out.println(e);
}

# 八、Redis_Jedis_实例

# 1 - 完成一个手机验证码功能

要求:
1、输入手机号,点击发送后随机生成 6 位数字码,2 分钟有效
2、输入验证码,点击验证,返回成功或失败
3、每个手机号每天只能输入 3 次

image-20220731164343801

实现见:http://blog.dabing.cool/cache/redis 实现手机验证码校验 /

# 九、Redis 与 Spring Boot 整合

Spring Boot 整合 Redis 非常简单,只需要按如下步骤整合即可

# 1 - 整合步骤

1、 在 pom.xml 文件中引入 redis 相关依赖

<!-- redis -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- spring2.X 集成 redis 所需 common-pool2-->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
<version>2.6.0</version>
</dependency>

2、 application.properties 配置 redis 配置

#Redis 服务器地址
spring.redis.host=192.168.140.136
#Redis 服务器连接端口
spring.redis.port=6379
#Redis 数据库索引(默认为 0)
spring.redis.database= 0
#连接超时时间(毫秒)
spring.redis.timeout=1800000
#连接池最大连接数(使用负值表示没有限制)
spring.redis.lettuce.pool.max-active=20
#最大阻塞等待时间 (负数表示没限制)
spring.redis.lettuce.pool.max-wait=-1
#连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=5
#连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=0

3、 添加 redis 配置类

@EnableCaching
@Configuration
public class RedisConfig extends CachingConfigurerSupport {
    @Bean
	public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        template.setConnectionFactory(factory);
        //key 序列化方式
        template.setKeySerializer(redisSerializer);
        //value 序列化
        template.setValueSerializer(jackson2JsonRedisSerializer);
        //value hashmap 序列化
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        return template;
    }
    
    
    @Bean
	public CacheManager cacheManager(RedisConnectionFactory factory) {
    	RedisSerializer<String> redisSerializer = new StringRedisSerializer();
    	Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
    	// 解决查询缓存转换异常的问题
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
		// 配置序列化(解决乱码的问题), 过期时间 600 秒
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofSeconds(600)).serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer)).serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jackson2JsonRedisSerializer)).disableCachingNullValues();
        RedisCacheManager cacheManager = RedisCacheManager.builder(factory).cacheDefaults(config).build();
        return cacheManager;
    }
}

4、测试一下

RedisTestController中添加测试方法
@RestController
@RequestMapping("/redisTest")
public class RedisTestController {
    @Autowired
    private RedisTemplate redisTemplate;
    @GetMapping
	public String testRedis() {
        // 设置值到 redis
        redisTemplate.opsForValue().set("name","lucy");
        // 从 redis 获取值
        String name = (String)redisTemplate.opsForValue().get("name");
        return name;
	}
}

# 十、Redis_事务_锁机制_秒杀

# 1- Redis 的事务定义

image-20220731165702195

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

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

# 2 - Multi、Exec、discard

从输入 Multi 命令开始,输入的命令都会依次进入命令队列中,但不会执行,直到输入 Exec 后,Redis 会将之前的命令队列中的命令依次执行。

组队的过程中可以通过 discard 来放弃组队。

image-20220731165752989

案例:

image-20220731165812368

组队成功,提交成功

image-20220731165825351

组队阶段报错,提交失败

image-20220731165909910

组队成功,提交有成功有失败情况

# 3 - 事务的错误处理

组队中某个命令出现了报告错误,执行时整个的所有队列都会被取消。

image-20220731165948305

如果执行阶段某个命令报出了错误,则只有报错的命令不会被执行,而其他的命令都会执行,不会回滚。

image-20220731170100577

# 4 - 为什么要做成事务

想想一个场景:有很多人有你的账户,同时去参加双十一抢购

# 5 - 事务冲突的问题

# 10.5.1. 例子

一个请求想给金额减 8000
一个请求想给金额减 5000
一个请求想给金额减 1000

image-20220731170212554

# 10.5.2. 悲观锁

image-20220731170241787

悲观锁 (Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会 block 直到它拿到锁。

传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

# 10.5.3. 乐观锁

image-20220731170516369

乐观锁 (Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用 版本号 等机制。

乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的。

# 10.5.4. WATCH key [key …]

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

image-20220731170841894

# 10.5.5. unwatch

取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后,EXEC 命令或 DISCARD 命令先被执行了的话,那么就不需要再执行 UNWATCH 了。

http://doc.redisfans.com/transaction/exec.html

# 6 - Redis 事务三特性

  • 单独的隔离操作
    • 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
  • 没有隔离级别的概念
    • 队列中的命令没有提交之前都不会实际被执行,因为事务提交前任何指令都不会被实际执行
  • 不保证原子性
    • 事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚

# 十一、Redis_事务_秒杀案例

# 1 - 解决计数器和人员记录的事务操作

image-20220731171148364

# 2 - Redis 事务–秒杀并发模拟

使用工具 ab 模拟测试

CentOS6 默认安装

CentOS7 需要手动安装

# 11.2.1. 联网:yum install httpd-tools

# 11.2.2. 无网络

(1) 进入 cd /run/media/root/CentOS 7 x86_64/Packages(路径跟 centos6 不同)

cd  /run/media/root/CentOS 7 x86_64/Packages

(2) 顺序安装

apr-1.4.8-3.el7.x86_64.rpm
apr-util-1.5.2-6.el7.x86_64.rpm
httpd-tools-2.4.6-67.el7.centos.x86_64.rpm

# 11.2.3. 测试及结果

11.2.3.1. 通过 ab 测试
vim postfile 模拟表单提交参数,以 & 符号结尾;存放当前目录。
** 内容:**prodid=0101&

ab -n 2000 -c 200 -p ~/postfile -T application/x-www-form-urlencoded http://192.168.2.115:8081/Seckill/doseckill

表示:- n 参数表示 2000 次请求,-c 参数表示并发请求 200 次,-p 是请求参数,写在当前文件夹的 postfile 文件中

11.2.3.2. 超卖
image-20220731171742352

# 3 - 超卖问题

image-20220731171820876

# 4 - 利用乐观锁淘汰用户,解决超卖问题。

image-20220731171831377

// 增加乐观锁
jedis.watch(qtkey);
//3. 判断库存
String qtkeystr = jedis.get(qtkey);
if(qtkeystr==null || "".equals(qtkeystr.trim())) {
System.out.println("未初始化库存");
jedis.close();
return false ;
}
int qt = Integer.parseInt(qtkeystr);
if(qt<=0) {
System.err.println("已经秒光");
jedis.close();
return false;
}
// 增加事务
Transaction multi = jedis.multi();
//4. 减少库存
//jedis.decr(qtkey);
multi.decr(qtkey);
//5. 加人
//jedis.sadd(usrkey, uid);
multi.sadd(usrkey, uid);
// 执行事务
List<Object> list = multi.exec();
// 判断事务提交是否失败
if(list==null || list.size()==0) {
System.out.println("秒杀失败");
jedis.close();
return false;
}
System.err.println("秒杀成功");
jedis.close();

image-20220731172004110

image-20220731172018038

# 5 - 继续增加并发测试

# 11.5.1. 连接有限制

ab -n 2000 -c 200 -k -p postfile -T ‘application/x-www-form-urlencoded’

http://192.168.140.1:8080/seckill/doseckill

image-20220731172350447

增加 - r 参数,-r Don’t exit on socket receive errors.

ab -n 2000 -c 100 -r -p postfile -T ‘application/x-www-form-urlencoded’

http://192.168.140.1:8080/seckill/doseckill

# 11.5.2. 已经秒光,可是还有库存

ab -n 2000 -c 100 -p postfile -T ‘application/x-www-form-urlencoded’

http://192.168.137.1:8080/seckill/doseckill

已经秒光,可是还有库存。原因,就是乐观锁导致很多请求都失败。先点的没秒到,后点的可能秒到了。

image-20220731172717687

# 11.5.3. 连接超时,通过连接池解决

image-20220731172732412

# 11.5.4. 连接池

节省每次连接 redis 服务带来的消耗,把连接好的实例反复利用。

通过参数管理连接的行为

代码见项目中

  • 链接池参数
    • MaxTotal :控制一个 pool 可分配多少个 jedis 实例,通过 **pool.getResource ()** 来获取;如果赋值为 - 1,则表示不限制;如果 pool 已经分配了 MaxTotal 个 jedis 实例,则此时 pool 的状态为 exhausted 。
    • maxIdle :控制一个 pool 最多有多少个状态为 idle (空闲) 的 jedis 实例;
    • MaxWaitMillis :表示当 borrow 一个 jedis 实例时,最大的等待毫秒数,如果超过等待时间,则直接抛 JedisConnectionException;
    • testOnBorrow :获得一个 jedis 实例的时候是否检查连接可用性(ping ());如果为 true,则得到的 jedis 实例均是可用的;

# 6 - 解决库存遗留问题

** 问题描述:** 由于乐观锁造成的库存遗留问题

假设现在有 500 个商品要出售,版本号是 1.0,有 2000 个人同时秒杀,其中有 1 个人购买成功并且修改库存为 499,版本号 1.1,那其他的 1999 人都不能成功购买,即有预存但是无法购买,造成的库存预留问题。

image-20220804125018740

** 解决:** 用 LUA 脚本,脚本可见 11.7.5 代码

# 11.6.1. LUA 脚本

image-20220731173040454

Lua 是一个小巧的脚本语言,Lua 脚本可以很容易的被 C/C++ 代码调用,也可以反过来调用 C/C++ 的函数,Lua 并没有提供强大的库,一个完整的 Lua 解释器不过 200k,所以 Lua 不适合作为开发独立应用程序的语言,而是作为嵌入式脚本语言

很多应用程序、游戏使用 LUA 作为自己的嵌入式脚本语言,以此来实现可配置性、可扩展性。

这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。

参考:https://www.w3cschool.cn/lua/

# 11.6.2. LUA 脚本在 Redis 中的优势

将复杂的或者多步的 redis 操作,写为一个脚本,一次提交给 redis 执行,减少反复连接 redis 的次数。提升性能。

LUA 脚本是类似 redis 事务,有一定的原子性,不会被其他命令插队,可以完成一些 redis 事务性的操作。

但是注意 redis 的 lua 脚本功能,只有在 Redis 2.6 以上的版本才可以使用。
利用 lua 脚本淘汰用户,解决超卖问题

redis 2.6 版本以后,通过 lua 脚本解决争抢问题,实际上是 redis 利用其单线程的特性,用任务队列的方式解决多任务并发问题

image-20220731173328775

# 7 - Redis_事务_秒杀案例_代码

# 11.7.1. 项目结构

image-20220731173358460

# 11.7.2. 第一版:简单版

老师点 10 次,正常秒杀

同学一起点试一试,秒杀也是正常的。这是因为还达不到并发的效果。

使用工具 ab 模拟并发测试,会出现超卖情况。查看库存会出现负数

# 11.7.3. 第二版:加事务 - 乐观锁 (解决超卖), 但出现遗留库存和连接超时

# 11.7.4. 第三版:连接池解决超时问题

# 11.7.5. 第四版:解决库存遗留问题,LUA 脚本

local userid=KEYS[1]; 
local prodid=KEYS[2];
local qtkey="sk:"..prodid..":qt";
local usersKey="sk:"..prodid.":usr'; 
local userExists=redis.call("sismember",usersKey,userid);
if tonumber(userExists)==1 then 
  return 2;
end
local num= redis.call("get" ,qtkey);
if tonumber(num)<=0 then 
  return 0; 
else 
  redis.call("decr",qtkey);
  redis.call("sadd",usersKey,userid);
end
return 1;

# 十二、Redis 持久化之 RDB

# 1 - 总体介绍

官网介绍:http://www.redis.io

image-20220731173617123

Redis 提供了 2 个不同形式的持久化方式。

  • RDB(Redis DataBase)
  • AOF(Append Of File)

# 2 - RDB(Redis DataBase)

# 12.2.1. 官网介绍

image-20220731173702411

# 12.2.2. 是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的 Snapshot 快照,它恢复时是将快照文件直接读到内存里

# 12.2.3. 备份是如何执行的

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

RDB 的缺点是最后一次持久化后的数据可能丢失

# 12.2.4. Fork

  • Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
  • 在 Linux 程序中,fork () 会产生一个和父进程完全相同的子进程,但子进程在此后多会 exec 系统调用,出于效率考虑,Linux 中引入了 “写时复制技术
  • 一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程。

# 12.2.5. RDB 持久化流程

image-20220731174221520

# 12.2.6. dump.rdb 文件

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

image-20220731174310211

# 12.2.7. 配置位置

rdb 文件的保存路径,也可以修改。默认为 Redis 启动时命令行所在的目录下
dir “/myredis/”

image-20220731174540479

# 12.2.8. 如何触发 RDB 快照;保持策略

12.2.8.1. 配置文件中默认的快照配置

image-20220731174621350

12.2.8.2. 命令 save VS bgsave

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

bgsave :Redis 会在后台异步进行快照操作, 快照同时还可以响应客户端请求。

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

12.2.8.3. flushall 命令

执行 flushall 命令,也会产生 dump.rdb 文件,但里面是空的,无意义

12.2.8.4. ###SNAPSHOTTING 快照 ###

12.2.8.5. Save

格式:save 秒钟 写操作次数

RDB 是整个内存的压缩过的 Snapshot,RDB 的数据结构,可以配置复合的快照触发条件,

默认是 1 分钟内改了 1 万次,或 5 分钟内改了 10 次,或 15 分钟内改了 1 次。

禁用:不设置 save 指令,或者给 save 传入空字符串

12.2.8.6. stop-writes-on-bgsave-error

image-20220731175145278

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

12.2.8.7. rdbcompression 压缩文件

image-20220731175201409

对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis 会采用 LZF算法 进行压缩。

如果你不想消耗 CPU 来进行压缩的话,可以设置为关闭此功能。推荐 yes.

12.2.8.8. rdbchecksum 检查完整性

image-20220731175342119

在存储快照后,还可以让 redis 使用 CRC64算法 来进行数据校验,

但是这样做会增加大约 10% 的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能 。推荐 yes.

12.2.8.9. rdb 的备份

先通过 config get dir 查询 rdb 文件的目录

将 *.rdb 的文件拷贝到别的地方

rdb 的恢复

  • 关闭 Redis
  • 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
  • 启动 Redis, 备份数据会直接加载

# 12.2.9. 优势

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

image-20220731175646400

# 12.2.10. 劣势

  • Fork 的时候,内存中的数据被克隆了一份,大致 2 倍的膨胀性需要考虑

  • 虽然 Redis 在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能

  • 在备份周期在一定间隔时间做一次备份,所以如果 Redis 意外 down 掉的话,就会丢失最后一次快照后的所有修改

# 12.2.11. 如何停止

动态停止 RDB: redis-cli config set save "" #save 后给空值,表示禁用保存策略

# 12.2.12. 小总结

image-20220731175756853

# 十三、Redis 持久化之 AOF

# 1 - AOF(Append Only File)

# 13.1.1. 是什么

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

# 13.1.2. AOF 持久化流程

(1)客户端的请求写命令会被 append 追加到 AOF 缓冲区内;

(2)AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中;

(3)AOF 文件大小超过重写策略或手动重写时,会对 AOF 文件 rewrite 重写,压缩 AOF 文件容量;

(4)Redis 服务重启时,会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的;

image-20220731180326215

# 13.1.3. AOF 默认不开启

可以在 redis.conf 中配置文件名称,默认为 appendonly.aof

AOF 文件的保存路径,同 RDB 的路径一致。

# 13.1.4. AOF 和 RDB 同时开启,redis 听谁的?

AOF 和 RDB 同时开启,系统默认取 AOF 的数据(数据不会存在丢失)

# 13.1.5. AOF 启动 / 修复 / 恢复

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

  • 正常恢复

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

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

# 13.1.6. AOF 同步频率设置

appendfsync always
始终同步,每次 Redis 的写入都会立刻记入日志;性能较差但数据完整性比较好
appendfsync everysec
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
appendfsync no
redis 不主动进行同步,把同步时机交给操作系统。

# 13.1.7. Rewrite 压缩

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

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

    no-appendfsync-on-rewrite
    如果 no-appendfsync-on-rewrite=yes , 不写入 aof 文件只写入 缓存 ,用户请求不会阻塞,但是在这段时间如果宕机会丢失这段时间的缓存数据。(降低数据安全性,提高性能

    ​ 如果 no-appendfsync-on-rewrite=no, 还是会把数据往 磁盘 里刷,但是遇到重写操作,可能会发生阻塞。(数据安全,但是性能降低

    触发机制,何时重写

    Redis 会记录上次重写时的 AOF 大小,默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发

    重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定 Redis 要满足一定条件才会进行重写。

    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 进行重写。

  3. 重写流程
    (1)bgrewriteaof 触发重写,判断是否当前有 bgsave 或 bgrewriteaof 在运行,如果有,则等待该命令结束后再继续执行。

    (2)主进程 fork 出子进程执行重写操作,保证主进程不会阻塞。

    (3)子进程遍历 redis 内存中数据到临时文件,客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf 重写缓冲区保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失。

    (4)1). 子进程写完新的 AOF 文件后,向主进程发信号,父进程更新统计信息。2). 主进程把 aof_rewrite_buf 中的数据写入到新的 AOF 文件。

    (5)使用新的 AOF 文件覆盖旧的 AOF 文件,完成 AOF 重写。

    image-20220731213215703

# 13.1.8. 优势

image-20220731213229824

  • 备份机制更稳健,丢失数据概率更低。

  • 可读的日志文本,通过操作 AOF 稳健,可以处理误操作。

# 13.1.9. 劣势

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

# 13.1.10. 小总结

image-20220731213332159

# 2 - 总结 (Which one)

# 13.2.1. 用哪个好

官方推荐两个都启用。

如果对数据不敏感,可以选单独用 RDB。

不建议单独用 AOF,因为可能会出现 Bug。

如果只是做纯内存缓存,可以都不用。

# 13.2.2. 官网建议

image-20220731213526710

  • RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储
  • AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF 命令以 redis 协议追加保存每次写的操作到文件末尾.
  • Redis 还能对 AOF 文件进行后台重写,使得 AOF 文件的体积不至于过大
  • 只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
  • 同时开启两种持久化方式
  • 在这种情况下,当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据,因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整.
  • RDB 的数据不实时,同时使用两者时服务器重启也只会找 AOF 文件。那要不要只使用 AOF 呢?
  • 建议不要,因为 RDB 更适合用于备份数据库 (AOF 在不断变化不好备份), 快速重启,而且不会有 AOF 可能潜在的 bug,留着作为一个万一的手段。
  • 性能建议

image-20220731213730871

# 十四、Redis_主从复制

# 1 - 是什么

主机数据更新后根据配置和策略, 自动同步到备机的 master/slaver 机制,Master 以写为主,Slave 以读为主

# 2 - 能干嘛

  • 读写分离,性能扩展
  • 容灾快速恢复

image-20220731213848099

# 3 - 怎么玩:主从复制

  1. 拷贝多个 redis.conf 文件 include (写绝对路径)

  2. 开启 daemonize yes

  3. Pid 文件名字 pidfile

  4. 指定端口 port

  5. Log 文件名字

  6. dump.rdb 名字 dbfilename

  7. Appendonly 关掉或者换名字

# 14.3.1. 新建 redis6379.conf,填写以下内容

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

image-20220731214026263

# 14.3.2. 新建 redis6380.conf,填写以下内容

image-20220731214039132

# 14.3.3. 新建 redis6381.conf,填写以下内容

image-20220731214050893

slave-priority 10

设置从机的优先级,值越小,优先级越高,用于选举主机时使用。默认 100

# 14.3.4. 启动三台 redis 服务器

image-20220731233845060

# 14.3.5. 查看系统进程,看看三台服务器是否启动

image-20220731233859352

# 14.3.6. 查看三台主机运行情况

info replication
打印主从复制的相关信息

image-20220731233920372

# 14.3.7. 配从 (库) 不配主 (库)

slaveof <ip><port>

成为某个实例的从服务器

1、在 6380 和 6381 上执行 : slaveof 127.0.0.1 6379

image-20220731233955771

2、在主机上写,在从机上可以读取数据

在从机上写数据报错

image-20220731234014747

3、主机挂掉,重启就行,一切如初

4、从机重启需重设:slaveof 127.0.0.1 6379

可以将配置增加到文件中。永久生效。

image-20220731234028351

# 4 - 常用 3 招

# 14.4.1. 一主二仆

切入点问题?slave1、slave2 是从头开始复制还是从切入点开始复制?比如从 k4 进来,那之前的 k1,k2,k3 是否也可以复制?

从机是否可以写?set 可否?

主机 shutdown 后情况如何?从机是上位还是原地待命?

主机又回来了后,主机新增记录,从机还能否顺利复制?

其中一台从机 down 后情况如何?依照原有它能跟上大部队吗?

image-20220801105448121

# 14.4.2. 薪火相传

上一个 Slave 可以是下一个 slave 的 Master,Slave 同样可以接收其他 slaves 的连接和同步请求,那么该 slave 作为了链条中下一个的 master, 可以有效减轻 master 的写压力,去中心化降低风险。

slaveof <ip><port>
中途变更转向:会清除之前的数据,重新建立拷贝最新的

风险是一旦某个 slave 宕机,后面的 slave 都没法备份

主机挂了,从机还是从机,无法写数据了

image-20220801105607960

image-20220801105732231

# 14.4.3. 反客为主

当一个 master 宕机后,后面的 slave 可以立刻升为 master,其后面的 slave 不用做任何修改。(手动)

slaveof no one 将从机变为主机。

image-20220801105740685

# 5 - 复制原理

  • Slave 启动成功连接到 master 后会发送一个 sync 命令
  • Master 接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master 将传送整个数据文件到 slave, 以完成一次完全同步
  • 全量复制:而 slave 服务在接收到数据库文件数据后,将其存盘并加载到内存中。
  • 增量复制:Master 继续将新的所有收集到的修改命令依次传给 slave, 完成同步
  • 但是只要是重新连接 master, 一次完全同步(全量复制) 将被自动执行

image-20220801105844173

# 6 - 哨兵模式 (sentinel)

# 14.6.1. 是什么

反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

image-20220801110018170

# 14.6.2. 怎么玩 (使用步骤)

14.6.2.1. 调整为一主二仆模式,6379 带着 6380、6381

image-20220801110034320

14.6.2.2. 自定义的 /myredis 目录下新建 sentinel.conf 文件,名字绝不能错

14.6.2.3. 配置哨兵,填写内容

sentinel monitor mymaster 127.0.0.1 6379 1

其中 mymaster 为监控对象起的服务器名称, 1 为至少有多少个哨兵同意迁移的数量。

14.6.2.4. 启动哨兵

/usr/local/bin

redis 做压测可以用自带的 redis-benchmark 工具

执行 redis-sentinel /myredis/sentinel.conf

image-20220801110305367

14.6.2.5. 当主机挂掉,从机选举中产生新的主机

(大概 10 秒左右可以看到哨兵窗口日志,切换了新的主机)

哪个从机会被选举为主机呢?根据优先级别: replica-priority

原主机重启后会变为从机。

14.6.2.6. 复制延时

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

# 14.6.3. 故障恢复

image-20220801110846257

优先级 在 redis.conf 中默认:replica-priority 100,值越小优先级越高

偏移量 是指获得原主机数据最全的

每个 redis 实例启动后都会随机生成一个 40 位的 runid

# 14.6.4. 主从复制

private static JedisSentinelPool jedisSentinelPool=null;
public static  Jedis getJedisFromSentinel(){
	if(jedisSentinelPool==null){
        Set<String> sentinelSet=new HashSet<>();
        sentinelSet.add("192.168.11.103:26379");
        JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10); // 最大可用连接数
 		jedisPoolConfig.setMaxIdle(5); // 最大闲置连接数
		jedisPoolConfig.setMinIdle(5); // 最小闲置连接数
		jedisPoolConfig.setBlockWhenExhausted(true); // 连接耗尽是否等待
		jedisPoolConfig.setMaxWaitMillis(2000); // 等待时间
		jedisPoolConfig.setTestOnBorrow(true); // 取连接的时候进行一下测试 ping pong
		jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
		return jedisSentinelPool.getResource();
     }else{
		return jedisSentinelPool.getResource();
     }
}

# 十五、Redis 集群

# 1 - 问题

容量不够,redis 如何进行扩容?

并发写操作, redis 如何分摊?

另外,主从模式,薪火相传模式,主机宕机,导致 ip 地址发生变化,应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决,但是 redis3.0 中提供了解决方案。就是无中心化集群配置。

# 2 - 什么是集群

Redis 集群实现了对 Redis 的水平扩容,即启动 N 个 redis 节点,将整个数据库分布存储在这 N 个节点中,每个节点存储总数据的 1/N。

Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯, 集群也可以继续处理命令请求。

# 3 - 删除持久化数据

将 rdb,aof 文件都删除掉。

# 4 - 制作 6 个实例,6379,6380,6381,6389,6390,6391

# 15.4.1. 配置基本信息

  1. 开启 daemonize yes
  2. Pid 文件名字
  3. 指定端口
  4. Log 文件名字
  5. Dump.rdb 名字
  6. Appendonly 关掉或者换名字

# 15.4.2. redis cluster 配置修改

  1. cluster-enabled yes 打开集群模式
  2. cluster-config-file nodes-6379.conf 设定节点配置文件名
  3. cluster-node-timeout 15000 设定节点失联时间,超过该时间(毫秒),集群自动进行主从切换。
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"
clu - ster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000

# 15.4.3. 修改好 redis6379.conf 文件,拷贝多个 redis.conf 文件

image-20220801113056666

# 15.4.4. 使用查找替换修改另外 5 个文件

例如::% s/6379/6380

# 15.4.5. 启动 6 个 redis 服务

image-20220801113121076

# 5 - 将六个节点合成一个集群

组合之前,请确保所有 redis 实例启动后,nodes-xxxx.conf 文件都生成正常。

image-20220801113311052

  • 合体:

cd /opt/redis-6.2.1/src

redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391

此处不要用 127.0.0.1, 请用真实 IP 地址
–replicas 1 采用最简单的方式配置集群,一台主机,一台从机,正好三组。

image-20220801113349156

image-20220801113414617

  • 普通方式登录
    可能直接进入读主机,存储数据时,会出现 MOVED 重定向操作。所以,应该以集群方式登录。

image-20220801113425849

# 6 - -c 采用集群策略连接,设置数据会自动切换到相应的写主机

image-20220801113550736

# 7- 通过 cluster nodes 命令查看集群信息

image-20220801123052282

# 8 - redis cluster 如何分配这六个节点?

一个集群至少要有三个主节点

选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

分配原则尽量保证每个主数据库运行在不同的 IP 地址,每个从库和主库不在一个 IP 地址上。

# 9 - 什么是 slots

[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 号插槽。

# 10 - 在集群中录入值

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

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

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

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

image-20220801123630199

可以通过 {} 来定义组的概念,从而使 key 中 {} 内相同内容的键值对放到一个 slot 中去。

image-20220801123644949

# 11 - 查询集群中的值

CLUSTER GETKEYSINSLOT 返回 count 个 slot 槽中的键。

image-20220801123657501

# 12 - 故障恢复

如果主节点下线?从节点能否自动升为主节点?注意:15 秒超时

image-20220801123757512

主节点恢复后,主从关系会如何?主节点回来变成从机

image-20220801123820814

如果所有某一段插槽的主从节点都宕掉,redis 服务是否还能继续?

如果某一段插槽的主从都挂掉,而 cluster-require-full-coverage 为 yes ,那么 ,整个集群都挂掉

如果某一段插槽的主从都挂掉,而 cluster-require-full-coverage 为 no ,那么,该插槽数据全都不能使用,也无法存储。

redis.conf 中的参数 cluster-require-full-coverage

# 13 - 集群的 Jedis 开发

即使连接的不是主机,集群会自动切换主机存储。主机写,从机读。

无中心化主从集群。无论从哪台主机写的数据,其他主机上都能读到数据。

public class JedisClusterTest {
  public static void main(String[] args) { 
     Set<HostAndPort>set =new HashSet<HostAndPort>();
     set.add(new HostAndPort("192.168.31.211",6379));
     JedisCluster jedisCluster=new JedisCluster(set);
     jedisCluster.set("k1", "v1");
     System.out.println(jedisCluster.get("k1"));
  }
}

# 14 - Redis 集群提供了以下好处

  1. 实现扩容
  2. 分摊压力
  3. 无中心配置相对简单

# 15 - Redis 集群的不足

  1. 多键操作是不被支持的

  2. 多键的 Redis 事务是不被支持的。lua 脚本不被支持

  3. 由于集群方案出现较晚,很多公司已经采用了其他的集群方案,而代理或者客户端分片的方案想要迁移至 redis cluster,需要整体迁移而不是逐步过渡,复杂度较大。

# 十六、Redis 应用问题解决

# 1- 缓存穿透

# 16.1.1. 问题描述

key 对应的数据在数据源并不存在,每次针对此 key 的请求从缓存获取不到,请求都会压到数据源,从而可能压垮数据源。比如用一个不存在的用户 id 获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。

image-20220801124314744

image-20220808134718629

# 16.1.2. 解决方案

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

解决方案:
(1) ** 对空值缓存:** 如果一个查询返回的数据为空(不管是数据是否不存在),我们仍然把这个空结果(null)进行缓存,设置空结果的过期时间会很短,最长不超过五分钟

(2) 设置可访问的名单(白名单)
使用 bitmaps 类型定义一个可以访问的名单,名单 id 作为 bitmaps 的偏移量,每次访问和 bitmap 里面的 id 进行比较,如果访问 id 不在 bitmaps 里面,进行拦截,不允许访问。

(3) 采用布隆过滤器:(布隆过滤器(Bloom Filter)是 1970 年由布隆提出的。它实际上是一个很长的 二进制向量 (位图) 和一系列随机 映射函数 (哈希函数)。

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。)

将所有可能存在的数据哈希到一个足够大的 bitmaps 中,一个一定不存在的数据会被 这个 bitmaps 拦截掉,从而避免了对底层存储系统的查询压力。

(4) 进行实时监控:当发现 Redis 的命中率开始急速降低,需要排查访问对象和访问的数据,和运维人员配合,可以设置黑名单限制服务

# 2 - 缓存击穿

# 16.2.1. 问题描述

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

image-20220801124751949

image-20220808135145459

# 16.2.2. 解决方案

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

解决问题:

(1)预先设置热门数据:在 redis 高峰访问之前,把一些热门数据提前存入到 redis 里面,加大这些热门数据 key 的时长

(2)实时调整:现场监控哪些数据热门,实时调整 key 的过期时长

(3)使用锁

  1. 就是在缓存失效的时候(判断拿出来的值为空),不是立即去 load db。
  2. 先使用缓存工具的某些带成功操作返回值的操作(比如 Redis 的 SETNX)去 set 一个 mutex key
  3. 当操作返回成功时,再进行 load db 的操作,并回设缓存,最后删除 mutex key;
  4. 当操作返回失败,证明有线程在 load db,当前线程睡眠一段时间再重试整个 get 缓存的方法。

image-20220801125032132

# 3 - 缓存雪崩

# 16.3.1. 问题描述

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

缓存雪崩与缓存击穿的区别在于这里针对很多 key 缓存,前者则是某一个 key

正常访问⬇

image-20220801125120331

缓存失效瞬间⬇

image-20220801125130104

image-20220808140122025

# 16.3.2. 解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕!

解决方案:
(1) ** 构建多级缓存架构:**nginx 缓存 + redis 缓存 + 其他缓存(ehcache 等)

(2) 使用锁或队列:
加锁 或者 队列 的方式保证来保证不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

(3) 设置过期标志更新缓存
记录缓存数据是否过期(设置提前量),如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。

(4) 将缓存失效时间分散开
比如我们可以在原有的失效时间基础上增加一个随机值,比如 1-5 分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。

# 4 - 分布式锁

# 16.4.1. 问题描述

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

分布式锁主流的实现方案

  1. 基于数据库实现分布式锁
  2. 基于缓存(Redis 等)
  3. 基于 Zookeeper
    每一种分布式锁解决方案都有各自的优缺点:
  4. 性能:redis 最高
  5. 可靠性:zookeeper 最高
    这里,我们就基于 redis 实现分布式锁。

# 16.4.2. 解决方案:使用 redis 实现分布式锁

redis命令 : 
set sku:1:info “OK” NX PX 10000
EX second:设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value
PX millisecond:设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 
NX :只在键不存在时,才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 
XX :只在键已经存在时,才对键进行设置操作。

image-20220801152803095

image-20220808141133285

  1. 多个客户端同时获取锁(setnx)
  2. 获取成功,执行业务逻辑 {从 db 获取数据,放入缓存},执行完成释放锁(del)
  3. 其他客户端等待重试

# 16.4.3. 编写代码

Redis: set num 0

@GetMapping("testLock")
public void testLock(){
    //1 获取锁,setne
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //2 获取锁成功、查询 num 的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1 判断 num 为空 return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2 有值就转成成 int
        int num = Integer.parseInt(value+"");
        //2.3 把 redis 的 num 加 1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4 释放锁,del
        redisTemplate.delete("lock");
    }else{
        //3 获取锁失败、每隔 0.1 秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

重启,服务集群,通过网关压力测试:
ab -n 1000 -c 100 http://192.168.140.1:8080/test/testLock

image-20220801153313835

查看 redis 中 num 的值 :

image-20220801153341490

但是还会有一些问题,见下,问题及相关解决方案。

# 16.4.4. 优化之设置锁的过期时间

** 问题:**setnx 刚好获取到锁,业务逻辑出现异常,导致锁无法释放

** 解决:** 设置过期时间,自动释放锁。

设置过期时间有两种方式:

  1. 首先想到通过 expire 设置过期时间(缺乏原子性:如果在 setnx 和 expire 之间出现异常,锁也无法释放)
  2. 在 set 时指定过期时间(推荐)

image-20220801153615051

设置过期时间:

image-20220801153652058

压力测试肯定也没有问题。自行测试

# 16.4.5. 优化之 UUID 防误删

** 问题:** 可能会释放其他服务器的锁。

** 场景:** 如果业务逻辑的执行时间是 7s。执行流程如下

  1. index1 业务逻辑没执行完,3 秒后锁被自动释放。
  2. index2 获取到锁,执行业务逻辑,3 秒后锁被自动释放。
  3. index3 获取到锁,执行业务逻辑
  4. index1 业务逻辑执行完成,开始调用 del 释放锁,这时释放的是 index3 的锁,导致 index3 的业务只执行 1s 就被别人释放。
    最终等于没锁的情况。

** 解决:**setnx 获取锁时,设置一个指定的唯一值(例如:uuid);释放前获取这个值,判断是否自己的锁

图片分析:

image-20220808142646549

image-20220802091705477

image-20220802091817746

# 16.4.6. 优化之 LUA 脚本保证删除的原子性

** 问题:** 删除操作缺乏原子性。

图片分析:

image-20220808143635697

场景:

  1. index1 执行删除时,查询到的 lock 值确实和 uuid 相等
uuid=v1
set(lock,uuid)

image-20220802091921511

  1. index1 执行删除前,lock 刚好过期时间已到,被 redis 自动释放
    在 redis 中没有了 lock,没有了锁。

image-20220802091953632

  1. index2 获取了 lock
    index2 线程获取到了 cpu 的资源,开始执行方法
uuid=v2
set(lock,uuid)
  1. index1 执行删除,此时会把 index2 的 lock 删除
    index1 因为已经在方法中了,所以不需要重新上锁。index1 有执行的权限。index1 已经比较完成了,这个时候,开始执行

image-20220802092126594

删除的 index2 的锁!

@GetMapping("testLockLua")
public void testLockLua() {
    //1 声明一个 uuid , 将做为一个 value 放入我们的 key 所对应的值中
    String uuid = UUID.randomUUID().toString();
    //2 定义一个锁:lua 脚本可以使用同一把锁,来实现删除!
    String skuId = "25"; // 访问 skuId 为 25 号的商品 100008348542
    String locKey = "lock:" + skuId; // 锁住的是每个商品的数据
    // 3 获取锁
    Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);
	// 第一种: lock 与过期时间中间不写任何的代码。
	//redisTemplate.expire ("lock",10, TimeUnit.SECONDS);// 设置过期时间
	// 如果 true
	if (lock) {
        // 执行的业务逻辑开始
        // 获取缓存中的 num 数据
        Object value = redisTemplate.opsForValue().get("num");
        // 如果是空直接返回
        if (StringUtils.isEmpty(value)) {
            return;
        }
        // 不是空 如果说在这出现了异常! 那么 delete 就删除失败! 也就是说锁永远存在!
        int num = Integer.parseInt(value + "");
        // 使 num 每次 + 1 放入缓存
        redisTemplate.opsForValue().set("num", String.valueOf(++num));
        /* 使用 lua 脚本来锁 */
        // 定义 lua 脚本
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        // 使用 redis 执行 lua 执行
        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptText(script);
        // 设置一下返回值类型 为 Long
        // 因为删除判断的时候,返回的 0, 给其封装为数据类型。如果不封装那么默认返回 String 类型,
        // 那么返回字符串与 0 会有发生错误。
        redisScript.setResultType(Long.class);
        // 第一个要是 script 脚本 ,第二个需要判断的 key,第三个就是 key 所对应的值。
        redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
    } else {
        // 其他线程等待
        try {
            // 睡眠
            Thread.sleep(1000);
            // 睡醒了之后,调用方法。
            testLockLua();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
	}
}

Lua 脚本详解:

image-20220802092521165

项目中正确使用:

定义 key,key 应该是为每个 sku 定义的,也就是每个 sku 有一把锁。

String locKey ="lock:"+skuId; // 锁住的是每个商品的数据
Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid,3,TimeUnit.SECONDS);

image-20220802092834206

# 16.4.7. 总结

1、加锁

// 1. 从 redis 中获取锁,set k1 v1 px 20000 nx
String uuid = UUID.randomUUID().toString();
Boolean lock = this.redisTemplate.opsForValue()
      .setIfAbsent("lock", uuid, 2, TimeUnit.SECONDS);

2、使用 lua 释放锁

// 2. 释放锁 del
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 设置 lua 脚本返回的数据类型
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
// 设置 lua 脚本返回类型为 Long
redisScript.setResultType(Long.class);
redisScript.setScriptText(script);
redisTemplate.execute(redisScript, Arrays.asList("lock"),uuid);

3、重试

Thread.sleep(500);
testLock();

为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件

  • 互斥性。在任意时刻,只有一个客户端能持有锁。
  • 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
  • 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
  • 加锁和解锁必须具有原子性。

# 十七、Redis6.0 新功能

# 1 - ACL

# 17.1.1. 简介

Redis ACLAccess Control List (访问控制列表)的缩写,该功能允许根据可以执行的命令可以访问的键来限制某些连接。

在 Redis 5 版本之前,Redis 安全规则只有密码控制 还有通过 rename 来调整高危命令比如 flushdb , KEYS* , shutdown 等。Redis 6 则提供 ACL 的功能对用户进行更细粒度的权限控制 :

(1)接入权限:用户名和密码
(2)可以执行的命令
(3)可以操作的 KEY

参考官网:https://redis.io/topics/acl

# 17.1.2. 命令

命令:
	(1)查看权限列表:acl list
	(2)查看权限类别:acl cat
	(3)查看当前用户:acl whoami
	(4)创建和编辑用户:acl setuser
具体使用见下:

1、使用 acl list 命令展现用户权限列表
(1)数据说明

image-20220802093424775

2、使用 acl cat 命令
(1)查看添加权限指令类别

image-20220802093544283

(2)加参数类型名可以查看类型下具体命令

image-20220802093606610

3、使用 acl whoami 命令查看当前用户

image-20220802093652694

4、使用 aclsetuser 命令创建和编辑用户 ACL

(1)ACL 规则
下面是有效 ACL 规则的列表。某些规则只是用于激活或删除标志,或对用户 ACL 执行给定更改的单个单词。其他规则是字符前缀,它们与命令或类别名称、键模式等连接在一起。

image-20220802094003527

(2)通过命令创建新用户默认权限
acl setuser user1

image-20220802094158447

在上面的示例中,我根本没有指定任何规则。如果用户不存在,这将使用 just created 的默认属性来创建用户。如果用户已经存在,则上面的命令将不执行任何操作。

(3)设置有用户名、密码、ACL 权限、并启用的用户
acl setuser user2 on >password ~cached:* +get

image-20220802094428400

(4) 切换用户,验证权限

image-20220802094549151

# 2 - IO 多线程

# 17.2.1. 简介

Redis6 终于支撑多线程了,告别单线程了吗?

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

# 17.2.2. 原理架构

Redis 6 加入多线程,但跟 Memcached 这种从 IO 处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析,执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂,需要去控制 key、lua、事务,LPUSH/LPOP 等等的并发问题。整体的设计大体如下:

image-20220802094700691

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

io-threads-do-reads  yes 
io-threads 4

# 3 - 工具支持 Cluster

之前老版 Redis 想要搭集群需要单独安装 ruby 环境,Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。

另外官方 redis-benchmark 工具开始支持 cluster 模式了,通过多线程的方式对多个分片进行压测。

image-20220802095313745

# 4 - Redis 新功能持续关注

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 一开始就是一个向编写各种系统开放的平台。

更新于 阅读次数

请我喝[茶]~( ̄▽ ̄)~*

Dabing-He 微信支付

微信支付