admin管理员组文章数量:1651837
Redis6
1. NoSQL数据库简介
1.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的时代，数据访问量很有限，用一夫当关的高性能的单点服务器可以解决大部分问题。
1.1.2 Web2.0时代
随着Web2.0的时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据。加上后来的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。
因此出现了分布式应用服务器。那么问题来了?比如一个用户登录的时候访问的是第一个服务器，进行业务操作的时候访问了另一个服务器。那么怎么判断是否登录了?登录状态怎么确定?
1.1.3 解决应用服务器CPU及磁盘压力
解决应用服务器的CPU及磁盘压力,将一些分布式需要的数据存到缓存数据库服务器中。
1.1.4 解决IO压力
随着数据量的增加，数据库压力增加，查询时的IO压力增大。传统方式是通过分库分表，主从复制等等来解决，破坏了一定的业务逻辑来换取性能。可以通过缓存数据库来解决这一问题。
1.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的结构化查询存储，处理复杂的关系,需要即席查询。即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表
-
（用不着 s q l 的和用了 s q l 也不行的情况，请考虑用 N o S q l ） \textcolor{red}{（用不着sql的和用了sql也不行的情况，请考虑用NoSql）} （用不着sql的和用了sql也不行的情况，请考虑用NoSql）
1.2.4 Memcache
1.2.5 Redis
1.2.6 MongoDB
1.3 行式存储数据库（大数据时代）
1.3.1 行式数据库
1.3.2 列式数据库
1.3.2.1 Hbase
HBase是Hadoop项目中的数据库。它用于需要对大量的数据进行随机、实时的读写操作的场景中。
HBase的目标就是处理数据量非常庞大的表，可以用普通的计算机处理超过10亿行数据，还可处理有数百万列元素的数据表。
1.3.2.2.Cassandra[kəˈsændrə]
Apache Cassandra是一款免费的开源NoSQL数据库，其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集(数据量通常达到PB级别)。在众多显著特性当中，Cassandra最为卓越的长处是对写入及读取操作进行规模调整，而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。
1.4.图关系型数据库
主要应用：社会关系，公共交通网络，地图及网络拓谱(n*(n-1)/2)
1.5.DB-Engines 数据库排名
http://db-engines/en/ranking
2. Redis概述安装
-
Redis是一个开源的key-value存储系统。
-
和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。
-
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。
-
在此基础上，Redis支持各种不同方式的排序。
-
与memcached一样，为了保证效率，数据都是缓存在内存中。
-
区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。
-
并且在此基础上实现了master-slave(主从)同步。
2.1 应用场景
2.1.1 配合关系型数据库做高速缓存
-
高频次，热门访问的数据，降低数据库IO
-
分布式架构，做session共享
2.1.2 多样的数据结构存储持久化数据
2.2 Redis安装
| Redis官方网站 | Redis中文官方网站 |
|---|---|
| http://redis.io | http://redis/ |
2.2.1 安装版本
-
6.2.1 for Linux（redis-6.2.1.tar.gz） 上传到 /opt/software
-
不用考虑在windows环境下对Redis的支持
2.2.2 安装步骤
2.2.2.1 准备工作：下载安装最新版的gcc编译器
安装到hadoop104虚拟机上
安装C 语言的编译环境
yum install centos-release-scl scl-utils-build
yum install -y devtoolset-8-toolchain
scl enable devtoolset-8 bash
测试gcc版本
2.2.2.2 下载redis-6.2.1.tar.gz放/opt/software目录
2.2.2.3 解压安装包
[root@hadoop104 atguigu] 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：没有那个文件
2.2.2.7 解决方案：运行make distclean
2.2.2.8 在redis-6.2.1目录下再次执行make命令（只是编译好）
2.2.2.9 跳过make test 继续执行: make install
2.2.3 安装目录：/usr/local/bin
linux编译安装的软件的脚本一般默认都在这个目录中。
查看默认安装目录：
redis-benchmark：性能测试工具，可以在自己本子运行，看看自己本子性能如何
redis-check-aof：修复有问题的AOF文件，rdb和aof后面讲
redis-check-dump：修复有问题的dump.rdb文件
redis-sentinel：Redis集群使用
redis-server：Redis服务器启动命令
redis-cli：font>客户端，操作入口
补充知识：
/bin /usr/local/bin /usr/local/bin
/sbin /usr/local/sbin /usr/local/sbin 这些目录下的脚本是可以不用配置环境变量直接执行的。
2.2.4 前台启动（不推荐）
前台启动，命令行窗口不能关闭，否则服务器停止
2.2.5 后台启动（推荐）
2.2.5.1 备份redis.conf
拷贝一份redis.conf到其他目录
[root@hadoop104 atguigu]# cp /opt/software/redis-6.2.1/redis.conf /myredis
[root@hadoop104 atguigu]# cat /myredis
2.2.5.2 后台启动设置daemonize no改成yes
修改redis.conf(247行)文件将里面的daemonize no 改成 yes，让服务在后台启动
[root@hadoop104 atguigu]# vim /opt/software/redis-6.2.1/redis.conf
2.2.5.3 Redis启动
[root@hadoop104 atguigu]# redis-server /opt/software/redis-6.2.1/redis.conf
2.2.5.4 用客户端访问：redis-cli
本地连接访问
redis-cli -p 端口号
[atguigu@hadoop104 ~]$ redis-cli -p 6379
远程连接访问
修改配置文件
服务器的端口打开后将redis的远程访问配置也打开，修改配置文件
vim /opt/software/redis-6.2.1/redis.conf
将此配置项注释，再找到protected-mode配置项
将yes改成no后进行保存配置重启redis
[root@hadoop104 atguigu] #pkill redis
远程连接
redis-cli -h 主机ip -p 端口
[root@hadoop103 /]# redis-cli -h 192.168.202.104 -p 6379
192.168.202.104:6379>
2.2.5.5 测试验证： ping
[root@hadoop103 /]# redis-cli -h 192.168.202.104 -p 6379
192.168.202.104:6379> ping
PONG
2.2.5.6 Redis关闭
关闭的是服务进程，不是客户端
**单实例关闭：**redis-cli shutdown 用本地连接客户端关闭本地服务进程
[atguigu@hadoop104 ~]$ redis-cli shutdown
[atguigu@hadoop104 ~]$ redis-cli -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>
# 连接不上了
也可以进入终端后再关闭
多实例关闭，指定主机名和端口关闭：
redis-cli -h 主机名 -p 6379 shutdown
亦可以进入终端后再关闭
2.2.6 Redis设置密码
2.2.7 Redis介绍相关知识
Redis是单线程+多路IO复用技术
多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）
串行 vs 多线程+锁（memcached） vs 单线程+多路IO复用(Redis)
多路复用和多线程提高并发能力的机制是不一样的。
多路复用是通过等待IO时处理其它请求来提升效率， 如果性能瓶颈在 I O 上 \textcolor{red}{如果性能瓶颈在 IO 上} 如果性能瓶颈在IO上，那么这个是很有效的。
用银行排队来比喻，假如每个人的业务都需要柜员处理1分钟，客户处理10分钟（填单子之类的），那 IO 多路复用就是，等客户填单子的时候继续处理下一个人的，不在那儿等着，填好单子继续处理；多线程就是开5个柜台。
两者都能提高并发能力，但IO多路复用的仅在瓶颈在IO的时候有效果。比如上面的例子改成柜员处理10分钟，客户1分钟，那即使柜员不等着继续处理下一个人的，也提升不了多少性能。如果是计算密集型的，瓶颈在CPU，那么使用多线程比较好。
（与Memcache三点不同: 支持多数据类型，支持持久化，单线程+多路IO复用）
3. 常用五大数据类型
哪里去获得redis常见数据类型操作命令http://www.redis/commands.html
3.1 Redis键(key)
keys * # 查看当前库(默认0号库)所有key (匹配：keys *1)
exists key # 判断某个key是否存在
type key # 查看你的key是什么类型
del key # 删除指定的key数据
unlink key # 根据value选择非阻塞删除 仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作。
expire key 10 # 10秒钟：为给定的key设置过期时间 可以用来做验证码
ttl key # 查看还有多少秒过期，-1表示永不过期，-2表示已过期
select 数据库号 # 切换数据库
dbsize # 查看当前数据库的key的数量
flushdb # 清空当前库
flushall # 通杀全部库
3.2 Redis字符串(String)
3.2.1 简介
String是Redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。
String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M
3.2.2 常用命令
set <key> <value> # 添加键值对
192.168.202.104:6379> set name 'ybh'
OK
192.168.202.104:6379> get name "ybh"
192.168.202.104:6379>
参数解释
-
NX：当数据库中key不存在时，可以将key-value添加数据库。如果存在，不执行任何操作。
-
XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥
-
EX：key的超时秒数
-
PX：key的超时毫秒数，与EX互斥
# 设置 姓名 23 过期时间60秒
192.168.202.104:6379> set age 23 ex 60
OK
192.168.202.104:6379> ttl age
(integer) 56
192.168.202.104:6379> ttl age
(integer) 55
192.168.202.104:6379>
get <key> # 查询对应键值
append <key> <value> # 将给定的<value> 追加到原值的末尾
strlen <key> # 获得值的长度
setnx <key> <value> # 只有在key不存在时才能设置成功设置 key 的值
incr <key> # 将 key 中储存的数字值增1 只能对数字值操作，如果为空，新增值为1
decr <key> # 将 key 中储存的数字值减1 只能对数字值操作，如果为空，新增值为-1
incrby / decrby <key> <步长> # 将 key 中储存的数字值增减。自定义步长。
原子性
所谓原子操作是指不会被线程调度机制打断的操作；
这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。
（1）在单线程中， 能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。
（2）在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。
Redis单命令的原子性主要得益于Redis的单线程。
案例：
java中的i++是否是原子操作？不不是
i=0;两个线程分别对i进行++100次,值是多少？ 范围可以从2-200
线程1 线程2
mset <key1><value1><key2><value2> ..... # 同时设置一个或多个 key-value对
mget <key1><key2><key3> ..... # 同时获取一个或多个 value
msetnx <key1><value1><key2><value2> .....
# 同时设置一个或多个 key-value 对，当且仅当所有给定key都不存在。
# 原子性，有一个失败则都失败
getrange <key><起始位置><结束位置> # 获得值的范围，类似java中的substring，前包，后包
setrange <key><起始位置><value> # 用 <value> 覆写<key>所储存的字符串值，从<起始位置>开始(索引从0开始)。
setex <key><过期时间><value> # 设置键值的同时，设置过期时间，单位秒。
getset <key><value> # 以新换旧，设置了新值同时获得旧值。
3.2.3 数据结构
String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配.
如图中所示，内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。
3.2.4 应用场景
**应用场景：**String是最常用的一种数据类型，普通的key/ value 存储都可以归为此类，即可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受Redis的定时持久化，操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外，Redis还提供了下面一些操作：
- 获取字符串长度
- 往字符串append内容
- 设置和获取字符串的某一段内容
- 设置及获取字符串的某一位（bit）
- 批量设置一系列字符串的内容
**使用场景：**常规key-value缓存应用。常规计数: 微博数, 粉丝数。
**实现方式：**String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
3.3 Redis列表(List)
3.3.1 简介
单键多值
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。
3.3.2 常用命令
lpush/rpush <key><value1><value2><value3> .... # 从左边/右边插入一个或多个值。
lpop/rpop <key> # 从左边/右边吐出一个值。值在键在，值亡键亡。
eg:
192.168.202.104:6379> lpush namelist ybh lmj cy ljh
(integer) 4
192.168.202.104:6379> lpop namelist
"ljh"
192.168.202.104:6379> lpop namelist
"cy"
192.168.202.104:6379> lpop namelist
"lmj"
192.168.202.104:6379> lpop namelist
"ybh"
192.168.202.104:6379> lpop namelist
(nil)
rpoplpush <key1><key2> # 从<key1>列表右边吐出一个值，插到<key2>列表左边。
eg:
192.168.202.104:6379> lpush list1 ybh1 ybh2 ybh3 ybh4
(integer) 4
192.168.202.104:6379> lpush list ljh1 ljh2 ljh3 ljh4
(integer) 4
192.168.202.104:6379> rpoplpush list list1
"ljh1"
192.168.202.104:6379> lpop list1
"ljh1"
lrange <key><start><stop> # 按照索引下标获得元素(从左到右)
lrange mylist 0 -1 # 0左边第一个，-1右边第一个，（0-1表示获取所有）
lindex <key><index> # 按照索引下标获得元素(从左到右)
llen <key> # 获得列表长度
linsert <key> before <value> <newvalue> # 在<value>的后面插入<newvalue>插入值
lrem <key><n><value> # 从左边删除n个value(从左到右)
lset <key><index><value> # 将列表key下标为index的值替换成value
3.3.3 数据结构
List的数据结构为快速链表quickList。
首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，也即是压缩列表。
它将所有的元素紧挨着一起存储，分配的是一块连续的内存。
当数据量比较多的时候才会改成quicklist。
因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。
Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。
3.3.4 应用场景
Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。
List 就是链表，相信略有数据结构知识的人都应该能理解其结构。使用List结构，我们可以轻松地实现最新消息排行等功能。List的另一个应用就是消息队列，可以利用List的PUSH操作，将任务存在List中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段的api，你可以直接查询，删除List中某一段的元素。
使用场景：
消息队列系统
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。
比如：将Redis用作日志收集器
实际上还是一个队列，多个端点将日志信息写入Redis，然后一个worker统一将所有日志写到磁盘。
取最新N个数据的操作
记录前N个最新登陆的用户Id列表，超出的范围可以从数据库中获得。
比如sina微博：
在Redis中我们的最新微博ID使用了常驻缓存，这是一直更新的。但是我们做了限制不能超过5000个ID，因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。
我们的系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。
3.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 常用命令
sadd <key><value1><value2> .....
# 将一个或多个member元素加入到集合key中，已经存在的member元素将被忽略
smembers <key> # 取出该集合的所有值。
sismember <key><value> # 判断集合<key>是否为含有该<value>值，有1，没有0
scard<key> # 返回该集合的元素个数。
srem <key><value1><value2> .... # 删除集合中的某个元素。
spop <key> # 随机从该集合中吐出一个值。
srandmember <key><n> # 随机从该集合中取出n个值。不会从集合中删除 。
smove <source><destination>value # 把集合中一个值从一个集合移动到另一个集合
sinter <key1><key2> # 返回两个集合的交集元素。
sunion <key1><key2> # 返回两个集合的并集元素。
sdiff <key1><key2> # 返回两个集合的差集元素(key1中的，不包含key2中的)
3.4.3 数据结构
Set数据结构是dict字典，字典是用哈希表实现的。
Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。
3.4.4 应用场景
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用Redis提供的Set数据结构，可以存储一些集合性的数据。
案例：
在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
Set是集合，是String类型的无序集合，set是通过hashtable实现的，概念和数学中的集合基本类似，可以交集，并集，差集等等，set中的元素是没有顺序的。
实现方式：
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
使用场景：
交集，并集，差集：(Set)
获取某段时间所有数据去重值
这个使用Redis的set数据结构最合适了，只需要不断地将数据往set中扔就行了，set意为集合，所以会自动排重。
3.5 Redis哈希(Hash)
3.5.1 简介
Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
类似Java里面的Map<String,Object>
举例：
用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储
主要有以下2种存储方式：
3.5.2 常用命令
hset <key><field><value> # 给<key>集合中的<field>键赋值<value>
192.168.202.104:6379> hset person1 name ybh
(integer) 1
192.168.202.104:6379> hset person1 age 24
(integer) 1
192.168.202.104:6379> hset person1 sex '男'
(integer) 1
192.168.202.104:6379> hget person1 name
"ybh"
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不存在
3.5.3 数据结构
Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable。
3.5.4 应用场景
电商购物车
1）以用户id为key
2）商品id为field
3）商品数量为value
购物车操作
添加商品 hset cart:1001 10088 1
增加数量 hincrby cart:1001 10088 1
商品总数 hlen cart:1001
删除商品 hdel cart:1001 10088
获取购物车所有商品 hgetall cart:1001
3.6 Redis有序集合Zset(sorted set)
3.6.1 简介
Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。
不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。
因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。
访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。
3.6.2 常用命令
zadd <key> <score1> <value1> <score2> <value2>…
# 将一个或多个member元素及其score值加入到有序集key当中。
192.168.202.104:6379> zadd topn 200 java 300 c++ 400 mysql 500 php
(integer) 4
zrange <key> <start> <stop> [WITHSCORES]
# 返回有序集key中，下标在<start><stop>之间的元素 0,-1表示全部查询出来 升序
# 带WITHSCORES，可以让分数一起和值返回到结果集。
192.168.202.104:6379> zrange topn 0 -1
1) "java"
2) "c++"
3) "mysql"
4) "php"
192.168.202.104:6379> zrange topn 0 -1 withscores
1) "java"
2) "200"
3) "c++"
4) "300"
5) "mysql"
6) "400"
7) "php"
8) "500"
zrangebyscore key min max [withscores] [limit offset count]
# 返回有序集key中，所有score值介于min和max之间(包括等于min或max)的成员。有序集成员按score值递增(从小到大)次序排列。
192.168.202.104:6379> zrangebyscore topn 300 500
1) "c++"
2) "mysql"
3) "php"
zrevrangebyscore key maxmin [withscores] [limit offset count]
# 同上，改为从大到小排列。
zincrby <key><increment><value> # 为元素的score加上增量
zrem <key><value> # 删除该集合下，指定值的元素
zcount <key><min><max> # 统计该集合，分数区间内的元素个数
zrank <key><value> # 返回该值在集合中的排名，从0开始。
利用这个数据结构可以实现文章排行榜
zrank topn '三国' # 返回'三国'在集合中的排名，从0开始。
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） 有序链表
要查找值为51的元素，需要从第一个元素开始依次查找、比较才能找到。共需要6次比较。
（2） 跳跃表
从第2层开始，1节点比51节点小，向后比较。
21节点比51节点小，继续向后比较，后面就是NULL了，所以从21节点向下到第1层
在第1层，41节点比51节点小，继续向后，61节点比51节点大，所以从41向下
在第0层，51节点为要查找的节点，节点被找到，共查找4次。
从此可以看出跳跃表比有序链表效率要高
3.6.5 应用场景
Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
和Set相比，Sorted Set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列，比如一个存储全班同学成绩的Sorted Set，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用Sorted Set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。
3.7 应用场景总结
1、显示最新的项目列表
下面这个语句常用来显示最新项目，随着数据多了，查询毫无疑问会越来越慢。
SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10
在Web应用中，“列出最新的回复”之类的查询非常普遍，这通常会带来可扩展性问题。这令人沮丧，因为项目本来就是按这个顺序被创建的，但要输出这个顺序却不得不进行排序操作。类似的问题就可以用Redis来解决。比如说，我们的一个Web应用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接，点击后就可以获得更多的评论。我们假设数据库中的每条评论都有一个唯一的递增的ID字段。我们可以使用分页来制作主页和评论页，使用Redis的模板，每次新评论发表时，我们会将它的ID添加到一个Redis列表：
LPUSH latestments <ID>
我们将列表裁剪为指定长度，因此Redis只需要保存最新的5000条评论：
LTRIM latestments 0 5000
每次我们需要获取最新评论的项目范围时，我们调用一个函数来完成（使用伪代码）：
FUNCTION get_latest_comments(start, num_items):
id_list = redis.lrange("latestments",start,start+num_items - 1)
IF id_list.length < num_items
id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
END
RETURN id_list
END
这里我们做的很简单。在Redis中我们的最新ID使用了常驻缓存，这是一直更新的。但是我们做了限制不能超过5000个ID，因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候，才需要去访问数据库。
我们的系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，而主页或第一个评论页是不会麻烦到硬盘上的数据库了。
2、排行榜应用，取TOP N操作
这个需求与上面需求的不同之处在于，取最新N个数据的操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，这时候就需要我们的sorted set出马了，将你要排序的值设置成sortedset的score，将具体的数据设置成相应的value，每次只需要执行一条ZADD命令即可。
另一个很普遍的需求是各种数据库的数据并非存储在内存中，因此在按得分排序以及实时更新这些几乎每秒钟都需要更新的功能上数据库的性能不够理想。典型的比如那些在线游戏的排行榜，比如一个Facebook的游戏，根据得分你通常想要：
- 列出前100名高分选手
- 列出某用户当前的全球排名
这些操作对于Redis来说小菜一碟，即使你有几百万个用户，每分钟都会有几百万个新的得分。模式是这样的，每次获得新得分时，我们用这样的代码：
ZADD leaderboard <score> <username>
你可能用userID来取代username，这取决于你是怎么设计的。得到前100名高分用户很简单：
ZREVRANGE leaderboard 0 99
用户的全球排名也相似，只需要：
ZRANK leaderboard <username>
3、删除与过滤
我们可以使用LREM来删除评论。如果删除操作非常少，另一个选择是直接跳过评论条目的入口，报告说该评论已经不存在。 有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制，你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目，但Redis却能够使用非常少的内存来处理几百万条项目。
4、按照用户投票和时间排序
排行榜的一种常见变体模式就像Reddit或Hacker News用的那样，新闻按照类似下面的公式根据得分来排序：score = points / time^alpha 。 因此用户的投票会相应的把新闻挖出来，但时间会按照一定的指数将新闻埋下去。下面是我们的模式，当然算法由你决定。模式是这样的，开始时先观察那些可能是最新的项目，例如首页上的1000条新闻都是候选者，因此我们先忽视掉其他的，这实现起来很简单。每次新的新闻贴上来后，我们将ID添加到列表中，使用LPUSH + LTRIM，确保只取出最新的1000条项目。有一项后台任务获取这个列表，并且持续的计算这1000条新闻中每条新闻的最终得分。计算结果由ZADD命令按照新的顺序填充生成列表，老新闻则被清除。这里的关键思路是排序工作是由后台任务来完成的。
5、处理过期项目
另一种常用的项目排序是按照时间排序。我们使用unix时间作为得分即可。 模式如下：
- 每次有新项目添加到我们的非Redis数据库时，我们把它加入到排序集合中。这时我们用的是时间属性，current_time和time_to_live。
- 另一项后台任务使用ZRANGE…SCORES查询排序集合，取出最新的10个项目。如果发现unix时间已经过期，则在数据库中删除条目。
6、计数
Redis是一个很好的计数器，这要感谢INCRBY和其他相似命令。我相信你曾许多次想要给数据库加上新的计数器，用来获取统计或显示新信息，但是最后却由于写入敏感而不得不放弃它们。好了，现在使用Redis就不需要再担心了。有了原子递增（atomic increment），你可以放心的加上各种计数，用GETSET重置，或者是让它们过期。例如这样操作：
INCR user:<id> EXPIRE
你可以计算出最近用户在页面间停顿不超过60秒的页面浏览量，当计数达到比如20时，就可以显示出某些条幅提示，或是其它你想显示的东西。
7、特定时间内的特定项目
另一项对于其他数据库很难，但Redis做起来却轻而易举的事就是统计在某段特点时间里有多少特定用户访问了某个特定资源。比如我想要知道某些特定的注册用户或IP地址，他们到底有多少访问了某篇文章。每次我获得一次新的页面浏览时我只需要这样做：
SADD page:day1:<page_id> <user_id>
当然你可能想用unix时间替换day1，比如time()-(time()%3600*24)等等。 想知道特定用户的数量吗？只需要使用
SCARD page:day1:<page_id>
需要测试某个特定用户是否访问了这个页面？
SISMEMBER page:day1:<page_id>
8、查找某个值所在的区间(区间无重合) ：(Sorted Set)
例如有下面两个范围，10－20和30－40
- A_start 10, A_end 20
- B_start 30, B_end 40
我们将这两个范围的起始位置存在Redis的Sorted Sets数据结构中，基本范围起始值作为score，范围名加start和end为其value值：
redis 127.0.0.1:6379> zadd ranges 10 A_start(integer) 1
redis 127.0.0.1:6379> zadd ranges 20 A_end(integer) 1
redis 127.0.0.1:6379> zadd ranges 30 B_start(integer) 1
redis 127.0.0.1:6379> zadd ranges 40 B_end(integer) 1
这样数据在插入Sorted Sets后，相当于是将这些起始位置按顺序排列好了。现在我需要查找15这个值在哪一个范围中，只需要进行如下的zrangbyscore查找：
redis 127.0.0.1:6379> zrangebyscore ranges (15 +inf LIMIT 0 11) "A_end"
这个命令的意思是在Sorted Sets中查找大于15的第一个值。（+inf在Redis中表示正无穷大，15前面的括号表示>15而非>=15）查找的结果是A_end，由于所有值是按顺序排列的，所以可以判定15是在A_start到A_end区间上，也就是说15是在A这个范围里。至此大功告成。
9、交集，并集，差集：(Set)
// book表存储book名称
set book:1:name
set book:2:name
// tag表使用集合来存储数据，因为集合擅长求交集、并集
sadd tag:ruby 1
sadd tag:ruby 2
sadd tag:web 2
sadd tag:erlang 3
// 即属于ruby又属于web的书？
inter_list = redis.sinter("tag:web", "tag:ruby") //即属于ruby，但不属于web的书？
inter_list = redis.sdiff("tag:ruby", "tag:web") //属于ruby和属于web的书的合集？
inter_list = redis.sunion("tag:ruby", "tag:web")
4. Redis配置文件介绍
一般在安装目录有redis.conf 我的安装目录在这 /opt/software/redis-6.2.1
4.1 Units单位
配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit
大小写不敏感
4.2 INCLUDES包含
类似jsp中的include，多实例的情况可以把公用的配置文件提取出来
4.3 网络相关配置
4.3.1 bind
默认情况bind=127.0.0.1只能接受本机的访问请求。
不写的情况下，无限制接受任何ip地址的访问。
生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉。如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应。
保存配置，停止服务，重启启动查看进程，不再是本机访问了。
4.3.2 protected-mode(保护模式)
将本机访问保护模式设置no
4.3.3 Port
端口号，默认 6379
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）两个值来达到想要的效果。
默认值：
4.3.5 timeout(客户端连接超时)
一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。
4.3.6 tcp-keepalive
对访问客户端的一种心跳检测，每隔n秒检测一次。
单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60。一分钟检测一次。
4.4 GENERAL通用
4.4.1 daemonize
是否为后台进程，设置为yes
守护进程，后台启动
4.4.2 pidfile
存放pid文件的位置，每个实例会产生一个不同的pid文件
4.4.3 loglevel
指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice
四个级别根据使用阶段来选择，生产环境选择notice 或者warning
4.4.4 logfile
日志文件名称
4.4.5 databases 16
设定库的数量 默认16，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
4.5 SECURITY安全
4.5.1 设置密码
默认是不需要密码的。放开这个注释就需要密码。requirepass 之后的就是密码。
访问密码的查看、设置和取消。
查看设置：
重新连接之后查看：
在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。
永久设置，需要再配置文件中进行设置。
4.6 LIMITS限制
4.6.1 maxclients最大连接数设置
-
设置redis同时可以与多少个客户端进行连接。
-
默认情况下为10000个客户端。
-
如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。
4.6.2 maxmemory最大内存容量
-
建议必须设置，否则，将内存占满，造成服务器宕机。
-
设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
-
如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
-
但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。
4.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：不进行移除。针对写操作，只是返回错误信息
# 默认值,是被注释掉的
# maxmemory-policy noeviction
4.6.4 maxmemory-samples（最大内存样本数量）
-
设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
-
一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。
5. Redis的发布和订阅
5.1 什么是发布和订阅
Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者(pub)发送消息，订阅者 (sub) 接收消息。
Redis 客户端可以订阅任意数量的频道。
5.2 Redis的发布和订阅
1、客户端可以订阅频道如下图
上图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系
当有新消息通过 publish 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
5.3 发布订阅命令行实现
-
打开一个客户端订阅channel1
SUBSCRIBE channel1 -
打开另一个客户端，给channel1发布消息hello
publish channel1 hello -
打开第一个客户端可以看到发送的消息
注：发布的消息没有持久化。在订阅前的客户端收不到hello，只能收到订阅后发布的消息。
6.Redis新数据类型
6.1 Bitmaps
6.1.1 简介
现代计算机用二进制（位） 作为信息的基础单位， 1个字节等于8位， 例如"abc"字符串是由3个字节组成， 但实际在计算机存储时将其用二进制表示， "abc"分别对应的ASCII码分别是97、 98、 99， 对应的二进制分别是01100001、 01100010和01100011，如下图
合理地使用操作位能够有效地提高内存使用率和开发效率。
Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：
（1） Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。
（2） Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。
6.1.2 命令
1.setbit
（1）格式
setbit <key> <offset> <value>设置Bitmaps中某个偏移量的值（0或1）
*offset:偏移量从0开始
（2）实例
每个独立用户是否访问过网站存放在Bitmaps中， 将访问的用户记做1， 没有访问的用户记做0， 用偏移量作为用户的id。
设置键的第offset个位的值（从0算起） ， 假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问， 那么当前Bitmaps初始化结果如图。
可以这么用：记录用户当天是否首次登录
unique:users:20230416 代表2023-04-16这天的独立访问用户的Bitmaps。
192.168.202.104:6379> setbit unique:users:20230346 1 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230346 6 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230346 11 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230346 15 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230346 19 1
注：
很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字。在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。
2.getbit
（1）格式
getbit <key> <offset>获取Bitmaps中某个偏移量的值。
获取键的第offset位的值（从0开始算）
（2）实例
获取id=8的用户是否在2023-04-16这天是否登录过， 返回0说明没有访问过：
注：因为100根本不存在，所以也是返回0
3.bitcount
统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定**额外的 start 或 end 参数，可以让计数只在特定的位上进行。**start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。
（1）格式
bitcount <key> [start end] 统计字符串从start字节到end字节比特值为1的数量
（2）实例
计算2023-04-16这天的独立访问用户数量
start和end代表起始和结束位数， 下面操作计算用户id在第1个字节到第3个字节之间的独立访问用户数， 对应的用户id是11， 15， 19。
举例： 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位置。
4.bitop
(1) 格式
bitop and(or/not/xor) <destkey> [key…]
bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。
(2)实例
2023-04-16 日访问网站的userid=1,2,5,9。
192.168.202.104:6379> setbit unique:users:20230416 1 1
(integer) 1
192.168.202.104:6379> setbit unique:users:20230416 2 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230416 5 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230416 9 1
(integer) 0
2023-04-17 日访问网站的userid=0,1,4,9。
192.168.202.104:6379> setbit unique:users:20230417 0 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230417 1 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230417 4 1
(integer) 0
192.168.202.104:6379> setbit unique:users:20230417 9 1
(integer) 0
计算出两天都访问过网站的用户数量
bitop and unique:users:and:20230416_17 unique:users:20230416unique:users:20230417
计算出任意一天都访问过网站的用户数量（例如月活跃就是类似这种） ， 可以使用or求并集
6.1.3 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 |
6.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
（1）格式
pfadd <key> < element> [element ...] 添加指定元素到 HyperLogLog 中
（2）实例
将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。
2.pfcount
（1）格式
pfcount <key> [key ...] 计算HLL的近似基数，可以计算多个HLL，比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可。
（2）实例
192.168.202.104:6379> pfadd hll1 "redis"
(integer) 1
192.168.202.104:6379> pfadd hll1 "mysql"
(integer) 1
192.168.202.104:6379> pfadd hll1 "redis"
(integer) 0
192.168.202.104:6379> pfcount hll1
(integer) 2
192.168.202.104:6379> pfadd hll2 "redis"
(integer) 1
192.168.202.104:6379> pfadd hll2 "mongodb"
(integer) 1
192.168.202.104:6379> pfcount hll1 hll2
(integer) 3 # 基数就三个
3.pfmerge
（1）格式
pfmerge <destkey> <sourcekey> [sourcekey ...] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得
（2）实例
6.3 Geospatial
6.3.1 简介
Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。
6.3.2 命令
1.geoadd
（1）格式
geoadd <key> <longitude> <latitude> <member> [longitude latitude member...] 添加地理位置（经度，纬度，名称）
（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
两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。
有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。
当坐标位置超出指定范围时，该命令将会返回一个错误。已经添加的数据，是无法再次往里面添加的。
2.geopos
（1）格式
geopos <key> <member> [member...] 获得指定地区的坐标值
（2）实例
3.geodist
（1）格式
geodist <key> <member1> <member2> [m|km|ft|mi ] 获取两个位置之间的直线距离
（2）实例
获取两个位置之间的直线距离
单位：
-
m 表示单位为米[默认值]。
-
km 表示单位为千米。
-
mi 表示单位为英里。
-
ft 表示单位为英尺。
如果用户没有显式地指定单位参数， 那么 GEODIST 默认使用米作为单位。
4.georadius
（1）格式
georadius <key> <longitude> <latitude> radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素
经度 纬度 距离 单位
（2）实例
7. Redis_Jedis_测试
7.1 Jedis所需要的jar包依赖
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.2.0</version>
</dependency>
7.2 连接Redis注意事项
禁用Linux的防火墙：Linux(CentOS7)里执行命令
systemctl stop/disable firewalld.service
redis.conf中注释掉bind 127.0.0.1 ,然后 protected-mode no
7.3 Jedis常用操作
7.3.1 创建动态的maven工程
7.3.2 创建测试程序
// 1.jedis的基本操作
private static void test1() {
// 1.创建Jedis连接对象
Jedis jedis = new Jedis("192.168.202.104",6379);
// 2.jedis基本操作 测试连接是否成功
String pong = jedis.ping();
System.out.println(pong);
// 3.关闭jedis
jedis.close();
}
7.4 测试相关API
Jedis的API其实就和redis命令行的命令差不多
7.4.1 Jedis-API: Key的相关操作
// 2. jedis 操作key
private static void test2() {
Jedis jedis = new Jedis("192.168.202.104",6379);
// 清空一下数据库
jedis.flushDB();
jedis.set("k1","v1");
jedis.set("k1","v1");
jedis.set("k1","v1");
Set<String> keys = jedis.keys("*");
keys.forEach((key)->{
System.out.println(key);
});
System.out.println(jedis.exists("k1"));
System.out.println(jedis.ttl("k1"));
System.out.println(jedis.get("k1"));
jedis.close();
}
7.4.2 Jedis-API: String
// 3. 批量设置string类型数据
private static void test3() {
Jedis jedis = new Jedis("192.168.202.104",6379);
// 批量设置string类型数据
jedis.mset("str1","v1","str2","v2","str3","v3");
System.out.println(jedis.mget("str1","str2","str3"));
}
7.4.3 Jedis-API: List
// 4. 测试list数据结构 最新的50条消息列表
private static void test4() {
Jedis jedis = new Jedis("192.168.202.104",6379);
// 用list做最新微博ID 比如最新发布的50个微博
// 微博消息key用message表示
for (int i = 0; i < 1000; i++) {
jedis.lpush("message","hello" + i);
}
// 获取最新的50个消息
List<String> message = jedis.lrange("message", 0, 50);
message.forEach(mes->{
System.out.println(mes);
});
jedis.close();
}
7.4.4 Jedis-API: set
// 5.set的应用 两个用户的好友列表 求公共好友
private static void test5() {
Jedis jedis = new Jedis("192.168.202.104",6379);
// 设置用户1001的好友
jedis.sadd("user:1001","2000","2001","2002","2003","2004","2005");
// 设置用户1002的好友
jedis.sadd("user:1002","1998","2001","2002","2010","2011","2012");
// 获取用户1001和1002的好友
Set<String> sameFriends = jedis.sinter("user:1001", "user:1002");
sameFriends.forEach(friendID->{
System.out.println(friendID);
});
jedis.close();
}
7.4.5 Jedis-API: hash
用来存储对象非常好
// 6.hash结构测试 某用户购物车 商品和对应的数量
private static void test6() {
Jedis jedis = new Jedis("192.168.202.104",6379);
// 设置用户1001购物车 某一件商品的数量
jedis.hset("cart:1001","1001","1");
jedis.hset("cart:1001","1002","1");
jedis.hset("cart:1001","1003","2");
jedis.hset("cart:1001","1004","2");
// 获取购物车所有商品ID和对应的数量
Map<String, String> goods = jedis.hgetAll("cart:1001");
goods.forEach((good,value)->{
System.out.println(good+":"+value);
});
jedis.close();
}
7.4.6 Jedis-API: zset
// 7.测试sortSet
private static void test7() {
Jedis jedis = new Jedis("192.168.202.104",6379);
// topN图书借阅次数排名 topN 借阅次数 "书名"
// topN 200 "三国演义"
// topN 150 "水浒传"
// topN 230 "红楼梦"
// topN 300 "西游记"
jedis.flushDB();
jedis.zadd("top3",200d,"三国演义");
jedis.zadd("top3",150d,"水浒传");
jedis.zadd("top3",230d,"红楼梦");
jedis.zadd("top3",300d,"西游记");
Set<String> top3 = jedis.zrange("top3", 0, -1);
// 全部升序
top3.forEach(book-> System.out.println(book));
// 获取水浒传的排名
Long zrank = jedis.zrank("top3", "水浒传");
System.out.println(zrank);
jedis.close();
}
8. Redis_Jedis验证码案例
完成一个手机验证码功能
要求：
1、输入手机号，点击发送后随机生成6位数字码，2分钟有效
2、输入验证码，点击验证，返回成功或失败
3、每个手机号每天只能输入3次
不写前端了，用测试方法模拟。
package com.ynu.redis.U2_Jedis验证码;
import org.junit.Test;
import redis.clients.jedis.Jedis;
import java.util.Random;
public class Main {
// 1、输入手机号，点击发送后随机生成6位数字码，2分钟有效
// 2、输入验证码，点击验证，返回成功或失败
// 3、每个手机号每天只能输入3次
// 1.发送验证码
@Test
public void test1() {
send("18243397305");
}
// 2.校验验证码
@Test
public void test2() {
String phoneNum = "18243397305";
checkCode("587060",phoneNum);
}
// 3.校验验证码
public boolean checkCode(String code,String phoneNum){
Jedis jedis = new Jedis("192.168.202.104",6379);
String codeKey = "verify"+phoneNum+":code";
String codeRedis = jedis.get(codeKey);
if (codeRedis==null){
throw new RuntimeException("请先发送验证码");
}
if (code.equals(codeRedis)){
System.out.println("验证码正确");
jedis.del(codeKey);
return true;
}else {
System.out.println("验证码错误！！");
}
return false;
}
// 2.发送验证码 给对应的手机号
public void send(String phoneNum){
Jedis jedis = new Jedis("192.168.202.104",6379);
// 一个手机号24小时内只能发送三次 用redis记录一共发了多少次。并且设置有效期为24小时
String phoneKey = "phone"+phoneNum+":cnt";
String count = jedis.get(phoneKey);
if (count==null){
//没有发送次数，第一次发送
//设置发送次数是1 过期时间是一天
jedis.setex(phoneKey,60*60*24,"1");
System.out.println("发送成功");
}else if (Integer.parseInt(count)<=2){
jedis.incr(phoneKey);
System.out.println("发送成功");
}else {
//发送三次，不能再发送
System.out.println("今天发送次数已经超过三次");
jedis.close();
return;
}
// 设置验证码
String codeKey = "verify"+phoneNum+":code";
String verifyCode = getVerifyCode();
jedis.setex(codeKey,60,verifyCode);
System.out.println("00000");
}
//1.生成6位数字验证码
public static String getVerifyCode(){
Random random = new Random();
String code = "";
for (int i = 0; i < 6; i++) {
code+=random.nextInt(10);
}
return code;
}
}
9. Redis与Spring Boot整合
步骤如下
1.pom.xmlRedis相关配置
<!-- redis -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<!-- spring2.X集成redis所需common-pool2-->
<dependency>
<groupId>org.apachemons</groupId>
<artifactId>commons-pool2</artifactId>
<version>2.6.0</version>
</dependency>
2.application.yml配置redis配置
# 端口号
server:
port: 8081
# 服务名称
spring:
application:
name: redis-cli
# Redis的相关配置
redis:
database: 0
host: 192.168.202.104
port: 6379
timeout: 1800000
lettuce:
pool:
max-active: 20
max-wait: -1
max-idle: 5
min-idle: 0
3.添加redis配置类
package com.ynu.redis.U3_SpringBoot集成Redis.config;
import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.annotation.PropertyAccessor;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.beans.factory.annotation.Configurable;
import org.springframework.cache.CacheManager;
import org.springframework.cache.annotation.CachingConfigurerSupport;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.RedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;
import java.time.Duration;
@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.在controller使用redisTemplate具体操作redis
对应五钟数据结构演示
opsFor
package com.ynu.redis.U3_SpringBoot集成Redis.controller;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.*;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.List;
import java.util.Set;
@RestController
@RequestMapping("/redisTest")
public class RedisTestController {
@Autowired
private RedisTemplate redisTemplate;
// 1.操作String数据类型
@GetMapping("/get")
public String testString() {
ValueOperations stringTemplate = redisTemplate.opsForValue();
//设置值到redis
stringTemplate.set("user1:name","杨炳辉");
stringTemplate.set("user1:age","24");
//从redis获取值
String name = (String) stringTemplate.get("user1:name");
String age = (String) stringTemplate.get("user1:age");
return "name: "+name + ",age: "+age;
}
// 2.操作Hash数据类型
@GetMapping("/getHash")
public String testHash() {
HashOperations hashTemplate = redisTemplate.opsForHash();
// 设置hash的值
hashTemplate.put("user1","name","杨炳辉");
hashTemplate.put("user1","age","25");
hashTemplate.put("user1","sex","男");
// 获取相应的值
String name = (String) hashTemplate.get("user1", "name");
String age = (String) hashTemplate.get("user1", "age");
String sex = (String) hashTemplate.get("user1", "sex");
return "name: "+name + ",age: "+age + ",sex:" + sex;
}
// 3.操作List数据类型
@GetMapping("/getList")
public List testList() {
//测试list
ListOperations listTemplate = redisTemplate.opsForList();
//leftPush是从左往后排
listTemplate.leftPush("list", "hello");
listTemplate.leftPush("list", "world");
listTemplate.leftPush("list", "!!!");
//遍历
//从第一元素到向后找两个元素
List list = listTemplate.range("list", 0, 2);
list.forEach(e -> System.out.println(e));
return list;
}
// 4.操作Set数据类型
@GetMapping("/getSet")
public Set testSet() {
//测试list
SetOperations setTemplate = redisTemplate.opsForSet();
// 不会重复
setTemplate.add("set","hello");
setTemplate.add("set","hello");
setTemplate.add("set","world");
setTemplate.add("set","!!!");
setTemplate.add("set","!!!");
Set set = setTemplate.members("set");
return set;
}
// 5.操作SortedSet数据类型
@GetMapping("/getSortSortedSet")
public Set testSortSortedSet() {
ZSetOperations zSetOperations = redisTemplate.opsForZSet();
zSetOperations.add("news","hello",1);
zSetOperations.add("news","world",4);
zSetOperations.add("news","good",2);
zSetOperations.add("news","bye",3);
//根据score 从小到大排序,0和3是集合的下标
Set samll = zSetOperations.range("news", 0, 3);
return samll;
}
}
10. Redis事务锁机制秒杀
10.1 Redis的事务定义
Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。
10.2 Multi、Exec、discard
从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。组队的过程中可以通过discard来放弃组队。
可以将multi理解为MySQL中的begin，将exec理解为commit，discard理解为rollback。
案例：
情况一：组队成功，提交成功
情况二：组队失败，提交失败
一般是命令写错了
情况三：组队成功，提交有成功有失败情况
一般是命令是正确的，但是操作的数据类型不对
10.3 事务的错误处理
组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。
如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。
10.4 为什么要做成事务
想想一个场景：有很多人有你的账户,同时去参加双十一抢购。必须是顺序的，不允许插队。
Redis事务的主要作用就是串联多个命令防止别的命令插队。
10.5 事务冲突的问题
10.5.1 例子
一个请求想给金额减8000
一个请求想给金额减5000
一个请求想给金额减1000
10.5.2 悲观锁
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
10.5.3 乐观锁
乐观锁(Optimistic Lock)，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
10.5.4 WATCH key [key …] 乐观锁
在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
# 先设置额一个key balance
192.168.202.104:6379> set balance 100
OK
开启客户端1监视balance
192.168.202.104:6379> watch balance
OK
# 开启事务操作
192.168.202.104:6379> multi
OK
192.168.202.104:6379(TX)> incrby balance 5
QUEUED
192.168.202.104:6379(TX)> exec # 提交之前 客户端2进行了提交操作 那么这里就会返回nil
(nil)
开启客户端2监视balance
127.0.0.1:6379> watch balance
OK
# 先进行事务操作
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby balance 5
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 157
10.5.5 unwatch
取消 WATCH 命令对所有 key 的监视。
如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。
10.6 Redis事务三特性
-
单独的隔离操作
- 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
-
没有隔离级别的概念
- 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
-
不保证原子性
- 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
11. Redis事务秒杀案例
11.1 解决计数器和人员记录的事务操作
无外乎两件事：1.商品库存减一 2.秒杀成功的人加到集合中。
package com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.controller;
import com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.Enum.RedisKeyEnum;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.BoundSetOperations;
import org.springframework.data.redis.core.BoundValueOperations;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.SetOperations;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.Optional;
/**
* @author ybh
* @date 2023.04.16 17:29
*/
@Controller
@RequestMapping("/sec")
@Slf4j
public class SecKillController {
@Autowired
private RedisTemplate redisTemplate;
@PostMapping("/doSecKill")
@ResponseBody
public boolean doSecKill(@RequestParam(value = "userId") String userId, @RequestParam(value = "goodId") String goodId){
// 因为是模拟 所以这边加上系统时间确保每个用户id不一样
userId+=System.currentTimeMillis();
// 1.数据校验
checkData(userId,goodId);
// 案例就暂时不写Service了
// 2.拼接KEY
// 2.1 库存key 使用枚举
String goodsKey = RedisKeyEnum.GOODS_STOCK_SKILL.getCode() + goodId;
// 2.2 用户key
String userKey = RedisKeyEnum.USER_STOCK_SKILL.getCode();
// 3.获取库存，如果库存null,秒杀没有开始。
log.info("秒杀商品key:{}",goodsKey);
try {
// 要指定键和值我泛型，不然会报错
BoundValueOperations<String,Integer> stockOperations = redisTemplate.boundValueOps(goodsKey);
if (null==stockOperations.get()){
log.info("秒杀还没开始");
throw new RuntimeException("秒杀还没开始");
}
// 4.判断用户是否重复秒杀操作。 已经在秒杀成功队列中,说明重复秒杀了。
BoundSetOperations<String,String> userSetOperations = redisTemplate.boundSetOps(RedisKeyEnum.USER_STOCK_SKILL.getCode());
if (Optional.ofNullable(userSetOperations.members()).isPresent() && userSetOperations.members().contains(userId)){
log.info("已经秒杀过，请勿重复秒杀");
throw new RuntimeException("");
}
// 5.库存小于1，秒杀已经结束
if (stockOperations.get()<=0){
log.info("秒杀已经结束");
throw new RuntimeException("");
}
// 6.秒杀逻辑。操作库
// 6.1 库存减一
// 6.2 添加到秒杀成功用户列表中
stockOperations.decrement();
userSetOperations.add(userId);
}catch (Exception e){
log.info("秒杀失败");
return false;
}
log.info("用户{}秒杀成功",userId);
return true;
}
private void checkData(String userId, String goodId) {
if (userId)==null){
throw new RuntimeException("用户ID不能为空");
}
if (goodId==null){
throw new RuntimeException("商品ID不能为空");
}
}
// 设置商品库存
@PostMapping("/setStock")
@ResponseBody
public boolean setGoodStock(@RequestParam(value = "goodId") String goodId,@RequestParam(value = "goodStock") Integer goodStock){
BoundValueOperations<String,Integer> stockOperations = redisTemplate.boundValueOps(RedisKeyEnum.GOODS_STOCK_SKILL + goodId);
stockOperations.set(goodStock);
return true;
}
}
package com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.Enum;
import lombok.AllArgsConstructor;
import lombok.Getter;
/**
* @author ybh
* @date 2023.04.16 18:04
*/
@Getter
@AllArgsConstructor
public enum RedisKeyEnum {
/**
* redis存储库存前缀
*/
GOODS_STOCK_SKILL("GOODS_STOCK_SKILL", "redis存储库存前缀"),
/**
* redis存储秒杀成功用户key
*/
USER_STOCK_SKILL("USER_STOCK_SKILL", "redis存储秒杀成功用户");
/**
* 编码
*/
private final String code;
/**
* 编码说明
*/
private final String desc;
}
11.2 Redis事务—秒杀并发模拟
使用工具ab模拟测试 linux工具
CentOS6 默认安装
CentOS7 需要手动安装
11.2.1 安装工具
[root@hadoop104 /] yum install httpd-tools
11.2.2 通过ab测试
# 查看命令帮助
[root@hadoop104 /]# ab --help
ab: wrong number of arguments
Usage: ab [options] [http[s]://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make at a time
-t timelimit Seconds to max. to spend on benchmarking
This implies -n 50000
-s timeout Seconds to max. wait for each response
Default is 30 seconds
-b windowsize Size of TCP send/receive buffer, in bytes
-B address Address to bind to when making outgoing connections
-p postfile File containing data to POST. Remember also to set -T
-u putfile File containing data to PUT. Remember also to set -T
-T content-type Content-type header to use for POST/PUT data, eg.
'application/x-www-form-urlencoded'
Default is 'text/plain'
-v verbosity How much troubleshooting info to print
-w Print out results in HTML tables
-i Use HEAD instead of GET
-x attributes String to insert as table attributes
-y attributes String to insert as tr attributes
-z attributes String to insert as td or th attributes
-C attribute Add cookie, eg. 'Apache=1234'. (repeatable)
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-q Do not show progress when doing more than 150 requests
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-r Don't exit on socket receive errors.
-h Display usage information (this message)
-Z ciphersuite Specify SSL/TLS cipher suite (See openssl ciphers)
-f protocol Specify SSL/TLS protocol
(SSL3, TLS1, TLS1.1, TLS1.2 or ALL)
vim postfile 模拟表单提交参数,以&符号结尾;存放当前目录。
goodId=1001&userId=2001& # 内容 在代码中修改一下userId模拟不同用户
# -n 请求数量 -c并发数量 -p 提交参数 -T 参数类型
[root@hadoop104 /]# ab -n 2000 -c 200 -k -p ~/postfile -T application/x-www-form-urlencoded http://192.168.0.43:8002/sec/doSecKill
查看日志输出和redis库
出现了什么问题？秒杀结束后依然秒杀成功。库存小于0了。
也就是所谓的超卖问题。线程不安全问题。
11.2.3 超卖问题解决
加事务-乐观锁(解决超卖),但出现遗留库存和连接超时
package com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.controller;
import com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.Enum.RedisKeyEnum;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.dao.DataAccessException;
import org.springframework.data.redis.core.*;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.List;
import java.util.Optional;
/**
* @author ybh
* @date 2023.04.16 17:29
*/
@Controller
@RequestMapping("/sec1")
@Slf4j
public class SecKillController_1 {
@Autowired
private RedisTemplate redisTemplate;
@PostMapping("/doSecKill")
@ResponseBody
public boolean doSecKill(@RequestParam(value = "userId") String userId, @RequestParam(value = "goodId") String goodId){
// 因为是模拟 所以这边加上系统时间确保每个用户id不一样
userId+=System.currentTimeMillis();
// 1.数据校验
checkData(userId,goodId);
String uid = userId;
String gid = goodId;
// 案例就暂时不写Service了
// 2.拼接KEY
// 2.1 库存key 使用枚举
String goodsKey = RedisKeyEnum.GOODS_STOCK_SKILL.getCode() + goodId;
// 2.2 用户key
String userKey = RedisKeyEnum.USER_STOCK_SKILL.getCode();
// 3.获取库存，如果库存null,秒杀没有开始。
log.info("秒杀商品key:{}",goodsKey);
SessionCallback<List<Object>> sessionCallback = new SessionCallback<List<Object>>() {
@Override
public List<Object> execute(RedisOperations operations) throws DataAccessException {
try {
// 开启锁监视商品
operations.watch(goodsKey);
// 要指定键和值我泛型，不然会报错
BoundValueOperations<String, Integer> stockOperations = redisTemplate.boundValueOps(goodsKey);
if (null == stockOperations.get()) {
log.info("秒杀还没开始");
throw new RuntimeException("秒杀还没开始");
}
// 4.判断用户是否重复秒杀操作。 已经在秒杀成功队列中,说明重复秒杀了。
BoundSetOperations<String, String> userSetOperations = redisTemplate.boundSetOps(RedisKeyEnum.USER_STOCK_SKILL.getCode());
if (Optional.ofNullable(userSetOperations.members()).isPresent() && userSetOperations.members().contains(uid)) {
log.info("已经秒杀过，请勿重复秒杀");
throw new RuntimeException("");
}
// 5.库存小于1，秒杀已经结束
if (stockOperations.get() <= 0) {
log.info("秒杀已经结束");
throw new RuntimeException("");
}
// 开启事务
redisTemplate.multi();
// 6.秒杀逻辑。操作库
// 6.1 库存减一
// 6.2 添加到秒杀成功用户列表中
operations.opsForValue().decrement(goodsKey);
operations.opsForSet().add(userKey,uid);
return operations.exec();
}catch (Exception e){
log.info("用户{}秒杀失败",uid);
return null;
}
}
};
List<Object> execute = (List<Object>) redisTemplate.execute(sessionCallback);
if (execute==null||execute.size()==0){
return false;
}else {
log.info("用户{}秒杀成功",userId);
return true;
}
}
private void checkData(String userId, String goodId) {
if (!Optional.ofNullable(userId).isPresent()){
throw new RuntimeException("用户ID不能为空");
}
if (!Optional.ofNullable(goodId).isPresent()){
throw new RuntimeException("商品ID不能为空");
}
}
}
测试命令：每次测试先检查一下ip
[root@hadoop104 /]# ab -n 2000 -c 200 -k -p ~/postfile -T application/x-www-form-urlencoded http://192.168.0.43:8002/sec1/doSecKill
11.2.4 连接池解决超时问题
SpringBoot项目只要简单配置就好了
下面是在jedis中的参数
- 链接池参数
- MaxTotal：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了MaxTotal个jedis实例，则此时pool的状态为exhausted。
- maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例；
- MaxWaitMillis：表示当borrow一个jedis实例时，最大的等待毫秒数，如果超过等待时间，则直接抛JedisConnectionException；
- testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；
11.2.5 解决库存遗留问题，LUA脚本
1. 现象演示
设置商品数量200
2000个用户去抢，并发200。但是发现抢到最后居然还有库存。
库存还有89
为什么会出现库存遗留问题？
就是因为乐观锁导致的。redis的乐观锁是通过版本机制来实现的。是线程安全的，不会造成数据异常。
A用户获得到到乐观锁，进行购买，另外的用户也获得了，但是在购买阶段发现版本号不一致，所以购买失败。
用悲观锁是可以解决这个问题，但是就完全失去了性能。
2. LUA脚本
Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。
https://www.w3cschool/lua/
3.LUA脚本在Redis中的优势
将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作，但是是不支持回滚的。
但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。
利用lua脚本淘汰用户，解决超卖问题和库存遗留问题都是可以的。
redis 2.6版本以后，通过lua脚本解决争抢问题，实际上是redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。
每个用户的操作无法插队。
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;
java代码
package com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.controller;
import com.ynu.redis.U4_Redis锁秒杀案例.T1_基本实现.Enum.RedisKeyEnum;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.dao.DataAccessException;
import org.springframework.data.redis.core.*;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import java.io.IOException;
import java.util.Arrays;
import java.util.List;
import java.util.Optional;
/**
* @author ybh
* @date 2023.04.16 17:29
*/
@Controller
@RequestMapping("/sec2")
@Slf4j
public class SecKillController_2 {
static String secKillScript ="local userid=KEYS[1];\r\n" +
"local prodid=KEYS[2];\r\n" +
"local qtkey='sk:'..prodid..\":qt\";\r\n" +
"local usersKey='sk:'..prodid..\":usr\";\r\n" +
"local userExists=redis.call(\"sismember\",usersKey,userid);\r\n" +
"if tonumber(userExists)==1 then \r\n" +
" return 2;\r\n" +
"end\r\n" +
"local num= redis.call(\"get\" ,qtkey);\r\n" +
"if tonumber(num)<=0 then \r\n" +
" return 0;\r\n" +
"else \r\n" +
" redis.call(\"decr\",qtkey);\r\n" +
" redis.call(\"sadd\",usersKey,userid);\r\n" +
"end\r\n" +
"return 1" ;
@Autowired
private RedisTemplate redisTemplate;
@PostMapping("/doSecKill")
@ResponseBody
public boolean doSecKill(@RequestParam(value = "userId") String userId, @RequestParam(value = "goodId") String goodId){
// 因为是模拟 所以这边加上系统时间确保每个用户id不一样
userId+=System.currentTimeMillis();
// 1.数据校验
checkData(userId,goodId);
// 注意不能用Integer lua不支持返回Integer类型
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<Long>(secKillScript,Long.class);
Long res = (Long) redisTemplate.execute(redisScript, Arrays.asList(userId,goodId));
String result = String.valueOf(res);
if ("0".equals(result)) {
System.err.println("已抢空！！");
}else if("1".equals( result ) ) {
System.out.println("抢购成功！！！！");
}else if("2".equals( result ) ) {
System.err.println("该用户已抢过！！");
}else{
System.err.println("抢购异常！！");
}
return true;
}
private void checkData(String userId, String goodId) {
if (!Optional.ofNullable(userId).isPresent()){
throw new RuntimeException("用户ID不能为空");
}
if (!Optional.ofNullable(goodId).isPresent()){
throw new RuntimeException("商品ID不能为空");
}
}
}
12. 分布式锁
12.1 基本概念
12.1.1 什么是分布式锁
在我们进行单机应用开发涉及并发同步的时候，我们往往采用synchronized或者ReentrantLock的方式来解决多线程间的代码同步问题。但是当我们的应用是在分布式集群工作的情况下，那么就需要一种更加高级的锁机制，来处理种跨机器的进程之间的数据同步问题，这就是分布式锁。
分布式锁，是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。
分布式锁可以理解为：控制分布式系统有序的去对共享资源进行操作，通过互斥来保证数据的一致性。
可能有同学会问，使用我们以前学习的Java中的锁机制，例如synchronized、ReentrantLock不就能解决问题了吗？为什么还要使用分布式锁？
对于简单的单体项目，即运行时程序在同一个Java虚拟机中，此时使用上面的Java的锁机制确实可以解决多线程并发问题。例如下面程序代码：
package com.ynu.redis.U5_分布式锁.T1_单机线程锁;
public class LockTest implements Runnable{
// 线程共享方法
public void get() {
System.out.println("1 线程 -->" + Thread.currentThread().getName());
System.out.println("2 线程 -->" + Thread.currentThread().getName());
System.out.println("3 线程 -->" + Thread.currentThread().getName());
}
@Override
public void run() {
get();
}
public static void main(String[] args) {
LockTest test = new LockTest(); // 创建任务
for (int i = 0; i < 10; i++) {
// 创建10个线程取执行任务
new Thread(test, "线程-" + i).start();
}
}
}
// 输出乱七八糟
1 线程 -->线程-0
2 线程 -->线程-0
3 线程 -->线程-0
1 线程 -->线程-1
1 线程 -->线程-5
2 线程 -->线程-5
3 线程 -->线程-5
1 线程 -->线程-8
2 线程 -->线程-8
1 线程 -->线程-4
3 线程 -->线程-8
2 线程 -->线程-1
1 线程 -->线程-9
2 线程 -->线程-4
2 线程 -->线程-9
3 线程 -->线程-1
1 线程 -->线程-2
2 线程 -->线程-2
3 线程 -->线程-2
1 线程 -->线程-6
3 线程 -->线程-9
1 线程 -->线程-7
2 线程 -->线程-7
3 线程 -->线程-7
1 线程 -->线程-3
2 线程 -->线程-3
3 线程 -->线程-3
3 线程 -->线程-4
2 线程 -->线程-6
3 线程 -->线程-6
加锁之后。 一个线程执行完方法之前，另一个线程根本无法进入
1 线程 -->线程-2
2 线程 -->线程-2
3 线程 -->线程-2
1 线程 -->线程-3
2 线程 -->线程-3
3 线程 -->线程-3
1 线程 -->线程-6
2 线程 -->线程-6
3 线程 -->线程-6
1 线程 -->线程-7
2 线程 -->线程-7
3 线程 -->线程-7
1 线程 -->线程-0
2 线程 -->线程-0
3 线程 -->线程-0
1 线程 -->线程-4
2 线程 -->线程-4
3 线程 -->线程-4
1 线程 -->线程-8
2 线程 -->线程-8
3 线程 -->线程-8
1 线程 -->线程-5
2 线程 -->线程-5
3 线程 -->线程-5
1 线程 -->线程-1
2 线程 -->线程-1
3 线程 -->线程-1
1 线程 -->线程-9
2 线程 -->线程-9
3 线程 -->线程-9
Process finished with exit code 0
但是在分布式环境中，程序是集群方式部署，如下图：
上面的集群部署方式依然会产生线程并发问题，因为synchronized、ReentrantLock只是jvm级别的加锁，没有办法控制其他jvm。也就是上面两个tomcat实例还是可以出现并发执行的情况。要解决分布式环境下的并发问题，则必须使用分布式锁。
分布式锁的实现方式有多种，例如：数据库实现方式、ZooKeeper实现方式、Redis实现方式等。
12.1.2 为什么要使用分布式锁
为了能够说明分布式锁的重要性，下面通过一个电商项目中减库存的案例来演示如果没有使用分布式锁会出现什么问题。代码如下：
第一步：导入坐标
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache/POM/4.0.0"
xmlns:xsi="http://www.w3/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache/POM/4.0.0 http://maven.apache/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.5.RELEASE</version>
<relativePath/>
</parent>
<groupId>com.itheima</groupId>
<artifactId>lock-test</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!--集成redis-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
<version>1.4.1.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
</dependencies>
</project>
第二步：配置application.yml文件
# 端口号
server:
port: 8080
# 服务名称
spring:
application:
name: redis-cli
# Redis的相关配置
redis:
database: 0
host: 192.168.202.104
port: 6379
timeout: 1800000
lettuce:
pool:
max-active: 20
max-wait: -1
max-idle: 5
min-idle: 0
第三步：编写Controller
package com.ynu.redis.U5_分布式锁.T2_分布式环境下的单机锁;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/stock")
public class StockController {
@Autowired
private StringRedisTemplate redisTemplate;
@RequestMapping("/sub")
public String subStock() throws InterruptedException {
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
Thread.sleep(50);
redisTemplate.opsForValue().set("stock",stock+"");
}else {
System.out.println("库存不足");
}
return "OK";
}
}
上面的代码在单机多线程的环境下就已经会出现问题了。
也就是只部署一台服务器，但是多个用户同时并发访问。
第四步：编写启动类
package com.ynu.redis;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.ComponentScan;
@SpringBootApplication
public class RedisApplication {
public static void main(String[] args) {
SpringApplication.run(RedisApplication.class);
}
}
第五步：设置redis
测试方式：使用jmeter进行压力测试，如下：
模拟10个用户，每个用户每秒发送两次请求。循环发送10次
设置访问地址和端口
注：Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。
查看控制台输出，发现已经出现了线程并发问题，如下：
由于当前程序是部署在一个Tomcat中的，即程序运行在一个jvm中，此时可以对减库存的代码进行同步处理，如下：
再次进行测试(注意恢复redis中的数据)，此时已经没有线程并发问题，控制台输出如下：
这说明如果程序运行在一个jvm中，使用synchronized即可解决线程并发问题。
下面将程序进行集群部署（如下图所示），并通过Nginx进行负载，再进行测试。
操作过程：
第一步：配置Nginx
upstream upstream_name{
server 127.0.0.1:8001;
server 127.0.0.1:8002;
}
server {
listen 8080;
server_name localhost;
location / {
proxy_pass http://upstream_name;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
注意不能有tab键，否则有乱码
第二步：修改application.yml中端口号改为8001和8002并分别启动程序
第三步：使用jemter再次测试，可以看到又出现了并发问题
可以看到不同的机器操作数据出现了并发问题。导致库存减少出错。
也就是单一的synchronized并不能解决问题。
这时候就应该用到分布式锁。
12.1.3 分布式锁应具有的特性
- 在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行
- 高可用的获取锁与释放锁
- 高性能的获取锁与释放锁
- 具备可重入特性
- 具备锁失效机制，防止死锁
- 具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败
12.2 分布式锁实现方案
12.2.1 数据库实现分布式锁
基于数据库实现分布式锁的核心思想是：在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引。想要执行某个方法，首先需要将这个方法名插入表中，成功插入则获取锁，执行完成后删除对应的行数据释放锁。此种方式就是建立在数据库唯一索引的特性基础上的。
建表语句和表结构如下：
CREATE DATABASE distributeLock;
CREATE TABLE `mylock`(
id INT PRIMARY KEY,
methodName VARCHAR(255) UNIQUE KEY
)
具体实现过程如下（在前面工程基础上进行改造）：
第一步：在pom.xml中导入maven坐标
<!-- MyBatis-Plus坐标-->
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>3.2.0</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
第二步：配置文件application.yml中配置mybatis-plus相关配置
# 端口号
server:
port: 8002
# 服务名称
spring:
application:
name: redis-cli
# Redis的相关配置
redis:
database: 0
host: 192.168.202.104
port: 6379
timeout: 1800000
lettuce:
pool:
max-active: 20
max-wait: -1
max-idle: 5
min-idle: 0
# 数据库配置
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://101.42.88.113:3306/distributeLock
username: root
password: 123456
mybatis-plus:
configuration:
map-underscore-to-camel-case: false
auto-mapping-behavior: full
#log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
mapper-locations: classpath*:mapper/**/*Mapper.xml
第三步：创建实体类
package com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity;
import com.baomidou.mybatisplus.annotation.TableName;
import java.io.Serializable;
@TableName("mylock")
public class MyLock implements Serializable {
private int id;
private String methodName;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getMethodName() {
return methodName;
}
public void setMethodName(String methodName) {
this.methodName = methodName;
}
}
第四步：创建Mapper接口
package com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.mapper;
import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity.MyLock;
import org.apache.ibatis.annotations.Mapper;
@Mapper
public interface MyLockMapper extends BaseMapper<MyLock> {
public void deleteByMethodName(String name);
}
第五步：在resources/mapper目录下创建Mapper映射文件MyLockMapper.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis//DTD Mapper 3.0//EN" "http://mybatis/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.mapper.MyLockMapper">
<delete id="deleteByMethodName" parameterType="string">
delete from mylock where methodName = #{value}
</delete>
</mapper>
第六步：改造StockController和StockService
package com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.controller;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.Service.StockService1;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/stock1")
public class StockController1 {
@Autowired
private StockService1 stockService1;
@RequestMapping("/sub")
public String subStock() throws InterruptedException {
return stockService1.subSock();
}
}
// 利用数据库唯一索引字段作为锁
package com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.Service;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity.MyLock;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.mapper.MyLockMapper;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
@Service
public class StockService1 {
@Autowired
private MyLockMapper myLockMapper;
@Autowired
private StringRedisTemplate redisTemplate;
public String subSock() throws InterruptedException {
MyLock myLock = new MyLock();
// 设置方法名称 对应数据库的方法名，必须唯一
myLock.setMethodName("stock");
try{
myLockMapper.insert(myLock); // 加锁
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
Thread.sleep(50);
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
redisTemplate.opsForValue().set("stock",stock+"");
}else {
System.out.println("库存不足");
}
// 释放锁
myLockMapper.deleteByMethodName(myLock.getMethodName());
}catch (Exception e){
System.out.println("没有获取锁，不能执行减库存操作！！！");
}
return "Success";
}
}
通过观察控制台输出可以看到，使用此种方式已经解决了线程并发问题。
注意，虽然使用数据库方式可以实现分布式锁，但是这种实现方式还存在如下一些问题：后面是解决方案
-
因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能
- 所以，数据库需要双机部署、数据同步、主备切换；
-
不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据
- 所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；
-
没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁。
- 所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；
-
不具备阻塞锁特性，获取不到锁直接返回失败。
- 所以需要优化获取逻辑，循环多次去获取。
-
在实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑。
12.2.2 ZooKeeper实现分布式锁
Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。
Zookeeper中节点分为4种类型：
1.持久节点 （PERSISTENT）
默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在
2.持久顺序节点（PERSISTENT_SEQUENTIAL）
所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号
3.临时节点（EPHEMERAL）
和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除
4.临时顺序节点（EPHEMERAL_SEQUENTIAL）
顾名思义，临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除
Zookeeper实现分布式锁的原理是基于Zookeeper的临时顺序节点，如下图：
客户端A和客户端B争抢分布式锁，其实就是在/my_lock节点下创建临时顺序节点，这个顺序节点由zk内部自行维护一个节点序号，序号最小则表示对应客户端获得锁。
Apache Curator是一个比较完善的ZooKeeper客户端框架，通过封装的一套高级API 简化了ZooKeeper的操作，其中就包括分布式锁的实现。
Curator实现分布式锁API
- 在Curator中有五种锁方案：
- InterProcessSemaphoreMutex：分布式排它锁（不可重入锁）
- InterProcessMutex：分布式可重入排它锁。底层实现起来比较麻烦。
- InterProcessReadWriteLock：分布式读写锁
- InterProcessMultiLock：将多个锁作为单个实体管理的容器
- InterProcessSemaphoreV2：共享信号量
第一步：在pom.xml中导入maven坐标
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.10</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>2.12.0</version>
</dependency>
第二步：编写配置类
package com.ynu.redis.U5_分布式锁.T4_ZK实现分布式锁.config;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.retry.ExponentialBackoffRetry;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class ZkConfig {
@Bean
public CuratorFramework curatorFramework(){
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,3);
CuratorFramework client = CuratorFrameworkFactory.builder()
.connectString("101.42.88.113:2181") // zk的地址和端口
.sessionTimeoutMs(5000)
.connectionTimeoutMs(5000)
.retryPolicy(retryPolicy)
.build();
client.start();
return client;
}
}
第三步：改造StockController和StockService
// Controller
package com.ynu.redis.U5_分布式锁.T4_ZK实现分布式锁.controller;
import com.ynu.redis.U5_分布式锁.T4_ZK实现分布式锁.service.StockService2;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/stock2")
public class StockController2 {
@Autowired
private StockService2 stockService2;
@RequestMapping("/sub")
public String subStock() throws InterruptedException {
return stockService2.subSock();
}
}
// Service
package com.ynu.redis.U5_分布式锁.T4_ZK实现分布式锁.service;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity.MyLock;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
@Service
public class StockService2 {
@Autowired
private StringRedisTemplate redisTemplate;
@Autowired
private CuratorFramework curatorFramework;
public String subSock() throws InterruptedException {
// curator获取锁 这里用分布式可重入排他锁
// 在节点/mylock下创建锁节点
InterProcessMutex mutex = new InterProcessMutex(curatorFramework,"/mylock");
MyLock myLock = new MyLock();
// 设置方法名称 对应数据库的方法名，必须唯一
myLock.setMethodName("stock");
try{
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
Thread.sleep(50);
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
redisTemplate.opsForValue().set("stock",stock+"");
}else {
System.out.println("库存不足");
}
// 释放锁
mutex.release(); // 如果服务出现宕机也不用害怕 因为创建的zk节点是临时顺序节点，一断时间后自动删除。
}catch (Exception e){
System.out.println("没有获取锁，不能执行减库存操作！！！");
}
return "Success";
}
}
通过观察控制台输出可以看到，使用此种方式已经解决了线程并发问题。
12.2.3 Redis实现分布式锁
版本一：setnx
加锁命令：set lock_key lock_value NX 因为NX表示不存在目标键才会去创建,如果不存在则不会创建。
解锁命令：del lock_key
Java程序：
Controller
package com.ynu.redis.U5_分布式锁.T5_Redis实现分布式锁.controller;
import com.ynu.redis.U5_分布式锁.T5_Redis实现分布式锁.Service.StockService3_1;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/stock3")
public class StockController3 {
@Autowired
private StockService3_1 stockService3_1;
@RequestMapping("/sub")
public String subStock() throws InterruptedException {
return stockService3_1.subSock();
}
}
Service
package com.ynu.redis.U5_分布式锁.T5_Redis实现分布式锁.Service;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity.MyLock;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
@Service
public class StockService3_1 {
@Autowired
private StringRedisTemplate redisTemplate;
@Autowired
private CuratorFramework curatorFramework;
public String subSock() throws InterruptedException {
try{
// 1.尝试加锁
// 成功会返回true 相当于set mylock Thread.currentThread().getName() NX
Boolean locked = redisTemplate.opsForValue().
setIfAbsent("mylock", Thread.currentThread().getName());
if (locked){
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
Thread.sleep(50);
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
redisTemplate.opsForValue().set("stock",stock+"");
}else {
System.out.println("库存不足");
}
// 释放锁
// 相当于 del mylock
redisTemplate.delete("mylock");
}else {
System.out.println("没有获取锁，不能执行减库存操作！！！");
}
}catch (Exception e){
System.out.println("出现异常，比如连接不上Redis");
}
return "Success";
}
}
版本二：setnx px
上面版本一的实现中存在一个问题，就是当某个线程获得锁后程序挂掉，此时还没来得及释放锁，这样后面所有的线程都无法获得锁了。为了解决这个问题可以在加锁时设置一个过期时间防止死锁。
加锁命令：set lock_key lock_value NX PX 5000
解锁命令：del lock_key
Java程序：
package com.ynu.redis.U5_分布式锁.T5_Redis实现分布式锁.Service;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity.MyLock;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;
@Service
public class StockService3_2 {
@Autowired
private StringRedisTemplate redisTemplate;
@Autowired
private CuratorFramework curatorFramework;
public String subSock() throws InterruptedException {
try{
// 1.尝试加锁
// 成功会返回true 相当于set mylock Thread.currentThread().getName() NX PX 5000
// 设置键的存活时间为5秒 就是防止锁没有释放成功的情况
Boolean locked = redisTemplate.opsForValue().
setIfAbsent("mylock", Thread.currentThread().getName(),5000, TimeUnit.MILLISECONDS);
if (locked){
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
Thread.sleep(50);
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
redisTemplate.opsForValue().set("stock",stock+"");
}else {
System.out.println("库存不足");
}
// 释放锁
// 相当于 del mylock
redisTemplate.delete("mylock");
}else {
System.out.println("没有获取锁，不能执行减库存操作！！！");
}
}catch (Exception e){
System.out.println("出现异常，比如连接不上Redis");
}
return "Success";
}
}
版本三：防止误删
针对前面版本二还有一点需要优化，就是加锁和解锁必须是同一个客户端，所以在加锁时可以设置当前线程id，在释放锁时判断是否为当前线程加的锁，如果是再释放锁即可。
什么时候锁有可能被别的释放，A服务器在处理问题的时候，时间超出了过期时间，自动释放了锁。此时B进就能进入，因为key是相同的，B设置了锁进行处理逻辑代码。此时A结束逻辑去释放锁，会错误地把B服务器上的锁释放掉。
package com.ynu.redis.U5_分布式锁.T5_Redis实现分布式锁.Service;
import com.ynu.redis.U5_分布式锁.T3_数据库实现分布式锁.entity.MyLock;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;
@Service
public class StockService3_3 {
@Autowired
private StringRedisTemplate redisTemplate;
@Autowired
private CuratorFramework curatorFramework;
public String subSock() throws InterruptedException {
try{
String threadId = Thread.currentThread().getName();
// 1.尝试加锁
// 成功会返回true 相当于set mylock Thread.currentThread().getName() NX PX 5000
// 设置键的存活时间为5秒 就是防止锁没有释放成功的情况
Boolean locked = redisTemplate.opsForValue().
setIfAbsent("mylock", threadId,5000, TimeUnit.MILLISECONDS);
if (locked){
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
Thread.sleep(50);
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
redisTemplate.opsForValue().set("stock",stock+"");
}else {
System.out.println("库存不足");
}
// 释放锁
if (threadId.equals(redisTemplate.opsForValue().get("stock")))
redisTemplate.delete("mylock");
}else {
System.out.println("没有获取锁，不能执行减库存操作！！！");
}
}catch (Exception e){
System.out.println("出现异常，比如连接不上Redis");
}
return "Success";
}
}
版本四：嵌入lua脚本
12.3 Redisson
基于上面的Redis版本三还是有缺陷
1.不可以重试，一旦没获取锁，就直接失败。
2.设置了超时时间，在超时时间内业务代码还没有执行完毕，锁就被删除掉了。这时别的线程又可以获得锁，导致代码同步问题。
—— 怎么解决，能不能续命呢?
Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。充分的利用了Redis键值数据库提供的一系列优势，基于Java实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。
Redisson已经内置提供了基于Redis的分布式锁实现，此种方式是我们推荐的分布式锁使用方式。
第一步：在pom.xml中导入redisson的maven坐标
Redisson的maven坐标如下：
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.10.1</version>
</dependency>
第二步：编写配置类
package com.ynu.redis.U5_分布式锁.T6_Redisson框架.config;
import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class RedissonConfig {
@Value("${spring.redis.host}")
private String host;
@Value("${spring.redis.port}")
private String port;
@Bean
public RedissonClient redissonClient(){
Config config = new Config();
config.useSingleServer().setAddress("redis://" + host + ":" + port);
final RedissonClient client = Redisson.create(config);
return client;
}
}
第三步：改造Controller和Service
package com.ynu.redis.U5_分布式锁.T6_Redisson框架.Service;
import org.apache.curator.framework.CuratorFramework;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;
@Service
public class StockService4 {
@Autowired
private RedissonClient redissonClient;
@Autowired
private StringRedisTemplate redisTemplate;
public String subSock() throws InterruptedException {
RLock lock = redissonClient.getLock("mylock");
try{
//尝试加锁，如果成功则程序继续执行，如果没成功则阻塞等待5秒钟
lock.lock(5000,TimeUnit.SECONDS);
int stock = Integer.parseInt(redisTemplate.opsForValue().get("stock"));
Thread.sleep(50);
if (stock > 0){
stock--;
System.out.println("库存还剩下:" + stock);
}else {
System.out.println("库存不足");
}
}catch (Exception e){
System.out.println("出现异常，比如连接不上Redis");
}finally {
// 最后解锁
lock.unlock();
}
return "Success";
}
}
13. Redis持久化之RDB
13.1 总体介绍
官网介绍：http://www.redis.io
Redis 提供了2个不同形式的持久化方式。
-
RDB（Redis DataBase）
-
AOF（Append Of File）
13.2 RDB（Redis DataBase）
12.2.1 官网介绍
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持久化流程
如果的内存中的数据量非常大的时候，rdb持久化的临时文件就会非常大，几乎是原文件的1倍，性能有所降低。如果当写操作要立刻持久化的时候，可以执行命令：save。
save是全阻塞的，bgsave是异步的。
flushall也会产生dump.rdb文件，清空所有数据库的数据，并保存在dump.rdb文件中。
shutdown也会产生dump.rdb文件，将内存中数据保存在dump.rdb文件中
12.2.6 dump.rdb文件
在redis.conf中配置文件名称，默认为dump.rdb
12.2.7 配置位置
rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下dir ./
13.2.8 RDB详细介绍
13.2.8.1 配置文件中默认的快照保存策略
save 3600 1 表示3600秒内至少有1个键发生变化。进行持久化其余同理。
我配置如下
配置完成后重新启动并且马上设置3个新的key,会发现在配置目录下生成了dump.rdb
13.2.8.2 save命令
格式：save 秒钟 写操作次数
RDB是整个内存的数据经过压缩过后的快照。RDB的使用需要配置快照触发条件。
默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。(save 60 10000)
13.2.8.3 flushall命令
执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义
13.2.8.4 SNAPSHOTTING快照
概念：某一时刻内存的所有数据。
13.2.8.5 命令save VS bgsave
**save ：**SAVE 直接调用 rdbSave函数 ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。如果数据量小，用此命令可能感觉不出有什么区别，但是当数据量很大的时候，就需要谨慎使用这个命令。
**bgsave：**Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
可以通过lastsave 命令获取最后一次成功执行快照的时间
禁用save方式
如果不想使用RDB快照, 也可以禁用, 修改配置文件即可. 不过一旦禁用了save, 那么关闭redis, 是不会把内存中的数据保存到rdb文件的, 需要注意。如果禁用了save自动保存, redis服务关闭是不会自动把内存中的数据保存到rdb文件中, 因此, 一定要有额外的手动保存机制, 才不会丢失内存中的数据
不设置save指令，或者给save传入空字符串
save "" #save 900 1
#save 300 10
#save 60 10000
13.2.8.6 stop-writes-on-bgsave-error配置
stop-writes-on-bgsave-error yes 这个配置也是非常重要的一项配置，这是**当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。**如果自己的业务有完善的监控系统，可以禁止此项配置， 否则请开启。
13.2.8.7 rdbcompression配置
对于存储到磁盘中的快照，设置是否进行压缩存储。
如果yes的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
关于压缩的配置 rdbcompression yes ，建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。
13.2.8.8 rdbchecksum 配置
数据完整性校验配置。
在存储快照后，还可以让redis使用CRC64算法来进行**数据校验。**但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能推荐yes。
13.2.8.9 rdb的备份步骤
先通过config get dir 查询rdb文件的目录
先将 *.rdb的文件拷贝到别的地方。再删除本机的*.rdb
rdb的恢复
-
关闭Redis
-
先把备份的文件拷贝到工作目录下
cp dump2.rdb dump.rdb -
启动Redis, 备份数据会直接加载，非常方便
13.2.9 优势
-
RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心，非常适用于灾难恢复适合大规模的数据恢复
-
对数据完整性和一致性要求不高更适合使用
-
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
-
与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。
13.2.10 劣势
-
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
-
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
-
不可控、丢失数据。如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你。虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要完整的保存整个数据集是一个比较繁重的工作，你通常会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据。
13.2.11 如何动态停止Save
动态停止RDB：redis-cli config set save #save后给空值，表示禁用保存策略
13.2.12 小总结
14. Redis持久化之AOF
14.1 AOF（Append Only File）
14.1.1 是什么
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
14.1.2 AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
14.1.3 AOF默认不开启
可以在redis.conf中配置文件名称，默认为 appendonly no
要开启改成yes就行了。
重启服务：
[root@hadoop104] ps -ef | grep redis
[root@hadoop104] kill -9 PID
[root@hadoop104] redis-server /opt/software/redis-6.2.1/redis.conf
AOF文件的保存路径，同RDB的路径一致，都在redis.conf所在的路径下。文件名为appendonly.aof
14.1.4 AOF和RDB同时开启，redis听谁的？
AOF和RDB同时开启，系统默认取AOF的数据**（数据不会存在丢失）**
14.1.5 AOF启动/修复/恢复
-
先通过上面步骤启动。
-
往redis中添加几条数据。
192.168.202.104:6379> set k1 v1
OK
192.168.202.104:6379> set k2 v2
OK
192.168.202.104:6379> set k3 v3
192.168.202.104:6379> set k4 v4
OK
- 把
appendonly.aof改成appendonlyf.copy
[root@hadoop104 /]mv appendonly.aof appendonly.aof.copy
- 关闭redis-server
192.168.202.104:6379> shutdown
- 把
appendonlyf.copy重新改回来appendonly.aof
[root@hadoop104 /] mv appendonly.aof.copy appendonly.aof
- 重启redis-server。发现数据还在
-
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
-
正常恢复
-
修改默认的appendonly no，改为yes
-
将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
-
恢复：重启redis然后重新加载
-
-
异常恢复（写入aof文件的时候，突然aof文件格式损坏了）
- 修改默认的appendonly no，改为yes
- 如遇到AOF文件损坏，通过
/usr/local/bin/redis-check-aof --fix appendonly.aof进行恢复 - 备份被写坏的AOF文件
- 恢复：重启redis，然后重新加载
演示：
-
先查看一下appendonly.aof
-
在最后一行瞎搞点东西。
-
启动redis。
redis-server /opt/software/redis-6.2.1/redis.conf并不能正常启动。
-
修复一下文件
redis-check-aof --fix appendonly.aof -
重启sever后，Cli可以正常连接了。
14.1.6 AOF同步频率设置
redis.conf 文件中有appendfsync这个配置。
1.appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
2.appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
3.appendfsync no
redis不主动进行同步，把同步时机交给操作系统。
14.1.7 Rewrite压缩
-
是什么：
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof手动rewrite。
举个例子：
现在有两个操作：
set a a1;
set b b1;
这两个操作可以合并成一个 set a a1 b b1; 把指令进行合并。这就是重写压缩操作。
-
重写原理，如何实现重写：
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进行重写。
-
重写流程
（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重写。
14.1.8 优点
-
备份机制更稳健，丢失数据概率更低。
-
可读的日志文本，通过操作AOF稳健，可以处理误操作。
14.1.9 缺点
-
比起RDB占用更多的磁盘空间。
-
恢复备份速度要慢。
-
每次读写都同步的话，有一定的性能压力。
-
存在个别Bug，造成不能恢复。
14.1.10 小总结
15 RDB,AOF总结(Which one)
15.1 用哪个好
官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。
15.2 官网建议
-
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
-
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾。
-
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
-
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
-
同时开启两种持久化方式
-
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
-
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？ *建议不要*，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
-
性能建议
-
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
-
如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价：一是带来了持续的IO。二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。
-
16. Redis_主从复制
16.1 是什么
主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
16.2 能干嘛
- 读写分离，性能扩展
- 容灾快速恢复
16.3 怎么玩主从复制
16.3.1 准备虚拟机安装redis
准备三台主机，由于我比较穷，准备了三台虚拟机。
| 主机ip | 角色 | |
|---|---|---|
| hadoop102 | 192.168.202.102 | master |
| hadoop103 | 192.168.202.103 | slave1 |
| hadoop104 | 192.168.202.104 | slave2 |
16.3.2 编写配置文件
分别把redis放到目录/opt/software下进行安装。
在每个主机的/opt/software/redis-6.2.1下写配置文件redis.conf：
主要是三个配置项
[root@hadoop102 redis-6.2.1]# vim /opt/software/redis-6.2.1 redis.conf
# bind 127.0.0.1 ::1 注释这一行
daemonize yes # 后台启动no改成yes
protected-mode no # 保护模式 yes改成no
16.3.3 分别启动三个机器的redis
redis-server /opt/software/redis-6.2.1/redis.conf
hadoop102:
hadoop103:
hadoop104:
16.3.4 查看三台主机运行情况
info replication
打印主从复制的相关信息：
hadoop102
hadoop103
hadoop104
16.3.5 配从(库)不配主(库)
slaveof <ip> <port>
成为某个实例的从服务器
1、在hadoop103和hadoop104上执行: slaveof 192.168.202.102 6379
2、在主机上写，在从机上可以读取数据
在从机上写数据报错
3、主机挂掉，重启就行，一切如初
4、从机重启需重设：slaveof 127.0.0.1 6379
可以将配置增加到文件中。永久生效。
slaveof 1.1.1.1 6379 #配置主的地址和端口
masterauth root #主机的密码，如果主机有设置密码 则配置 没有不配置
16.4 常用3招
16.4.1 一主二仆
切入点问题？
slave1、slave2是从头开始复制还是从切入点开始复制还是从头复制？ 从头开始复制
比如从k4进来，那之前的k1,k2,k3是否也可以复制？ 可以
从机是否可以写？set可否？ 不可
主机shutdown后情况如何？从机是上位还是原地待命？ 原地待命，不会抢着上位当主机
主机又回来了后，主机新增记录，从机还能否顺利复制？ 能
其中一台从机down后情况如何？依照原有它能跟上大部队吗？ 能
16.4.2 薪火相传
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
举例子：上面的hadoop102主机，hadoop103是它的从机，hadoop102只给103同步数据。hadoop104接入hadoop103成为103的从机，103给104同步数据
还是用 slaveof <ip> <port>命令。
某台机器中途变更转向：会清除之前的数据，重新建立拷贝最新的。
风险是一旦某个slave宕机，后面的slave都没法备份。主机挂了，从机还是从机，无法写数据了。
16.4.3 反客为主
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
用 slaveof no one 将从机变为主机。
hadoop102挂了，在hadoop103执行slaveof no one。hadoop103就变成主机了，hadoop104就是它的从机。
但是这毕竟是手动的，之后的哨兵模式就是自动的了。
16.5 复制原理
- Slave启动成功连接到master后会发送一个sync命令。
- Master接到命令启动后台的存盘进程(将数据持久化到.rdb文件中)，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。
- 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。
16.6 哨兵模式(sentinel)
16.6.1 是什么
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
16.6.2 使用步骤
- 调整为一主二仆模式，hadoop102为主，hadoop103，hadoop104为从。
- 配置哨兵服务器
正常哨兵也是要单独启动一台服务器。但是由于虚拟机开不动了，所以在hadoop103这个从机上启动哨兵。
修改sentinel.conf文件
sentinel monitor mymaster 192.168.202.102 6379 1
其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。
- 启动哨兵
执行redis-sentinel sentinel.conf
4.杀死hadoop102主机观察现象
主机从hadoop102切换到了hadoop103
(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)
哪个从机会被选举为主机呢？
当master 宕掉以后，majority 哨兵进行选举机制、进行redis 的贮备切换、
1、slave 的优先级，slave-priority 越小，slave的优先级越高。
2、若slave-priority 相同，比较replica offset ，slave 复制的数据越多，优先级越高。
3、若上面两个条件都相同，比较 run id ，run id 越小的slave 优先级越高。
原主机重启后会变为从机。
16.6.3 复制延时
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
怎么解决呢？高级篇再做介绍
16.6.4 故障恢复
优先级在redis.conf中默认：slave-priority 100，值越小优先级越高。
偏移量是指获得原主机数据最全的。
每个redis实例启动后都会随机生成一个40位的runid。
17.Redis应用问题解决
17.1.缓存穿透
17.1.1.问题描述
key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如**用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。**
17.1.2 解决方案
一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
解决方案
解决方案：
（1）**对空值缓存：**如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟
（2）设置可访问的名单（白名单）：
使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
（3）采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
（4）**进行实时监控：**当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务
17.2 缓存击穿
17.2.1 问题描述
某一热点key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
17.2.2 解决方案
key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。
解决问题：
（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长。
（2）实时调整：现场监控哪些数据热门，实时调整key的过期时长
（3）使用锁：(性能必然有所降低)
- 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
- 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key
- 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
- 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。
17.3 缓存雪崩
17.3.1 问题描述
key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。
正常访问
缓存失效瞬间
17.3.2 解决方案
缓存失效时的雪崩效应对底层系统的冲击非常可怕！
解决方案：
（1）**构建多级缓存架构：**nginx缓存 + redis缓存 +其他缓存（ehcache等）
（2）使用锁或队列：用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落 到底层存储系统上。不适用高并发情况
（3）设置过期标志更新缓存或者定时任务更新缓存：
记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。定时任务定期更新缓存(比 如使用xxl框架)。
（4）将缓存失效时间分散开：
比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很 难引发集体失效的事件。
18.Redis集群
18.1 问题
-
当Redis的容量不够，redis如何进行扩容？
-
并发写操作， redis如何分摊？
- 另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。难道时不时去修改配置文件吗？之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。维护起来简单同时省去了代理主机的两台服务器。
18.2 什么是集群
所谓的集群,就是通过增加服务器的数量,提供相同的服务,从而让服务器达到一个稳定、高效的状态。
Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
18.3 实操集群
搭建如上图所示的3台主机，3台从机的小集群。由于不能电脑启动不了6台虚拟机，所以一个虚拟机上启动两个实例，用端口号区分。
| 主机 | |
|---|---|
| hadoop102:6379 | hadoop103:6380 |
| hadoop103:6379 | hadoop104:6380 |
| hadoop104:6379 | hadoop103:6380 |
基本配置信息
开启 daemonize yes
Pid 文件名字
指定端口
Log 文件名字
Dump.rdb名字
Appendonly 关掉或者换名字
集群配置信息
cluster-enabled yes 打开集群模式
cluster-config-file nodes-6379.conf 设定节点配置文件名
cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。
完整配置hadoop102
在/opt/software/redis-6.2.1/ 创建一个myredis。
[root@hadoop102 myredis] vim redis6379.conf
port 6379
pidfile "/var/run/redis_6379.pid"
dbfilename "dump6379.rdb"
dir "/opt/software/redis-6.2.1/myredis/data" # 数据文件存储路径
logfile "/opt/software/redis-6.2.1/myredis/log/redis_err_6379.log"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
复制一份redis6380.conf
[root@hadoop102 myredis] cp redis6379.conf redis6380.conf
# 全局替换命令
%s/str1/str2/g 用str2替换文件中所有的str1
vim redis6380.conf
%s/6379/6380/g
在hadoop103和hadoop104上用同样的方法在同样的目录下创建配置文件。
启动6个redis服务
将六个节点合成一个集群
组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。会保存在前面创建的data目录中
合体：
[root@hadoop102 src] cd /opt/software/redis-6.2.1/src
[root@hadoop102 src] redis-cli --cluster create --cluster-replicas 1 192.168.202.102:6379 192.168.202.103:6380 192.168.202.103:6379 192.168.202.104:6380 192.168.202.104:6379 192.168.202.102:6380
此处不要用127.0.0.1， 请用真实IP地址
–replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组。
- 普通方式登录
可能直接进入读主机，存储数据时，会出现MOVED重定向操作。所以，应该以集群方式登录。
- -c 采用集群策略连接，设置数据会自动切换到相应的写主机
- 通过 cluster nodes 命令查看集群信息
-
redis cluster 如何分配这六个节点？
一个集群至少要有三个主节点。
选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。
18.4 什么是slots
启动集群的时候有这么一段话。
一个 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中去。
发现没，一旦插入就会进入原先插入的主机。
-
查询集群中的值
cluster keyslot user返回cust键应该去哪个槽。
cluster countkeysinslot 5474 返回5474这个槽中的键的个数。
cluster getkeysinslot 5474 10 返回5474这个槽中的10个键，没有10个返回所有的。
如果主节点下线？从节点能否自动升为主节点？
注意：15秒超时之后从节点会变成主节点。
主节点恢复后，主从关系会如何？主节点回来变成从机。
如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续？ 根据配置决定。redis.conf中的参数 cluster-require-full-coverage
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉。
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。
19.Redis6新功能
19.1 ACL
简介
Redis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。
在Redis 5版本之前，Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb ， KEYS* ， shutdown 等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 ：
（1）接入权限:用户名和密码
（2）可以执行的命令
（3）可以操作的 KEY
参考官网：https://redis.io/topics/acl
命令
1、使用acl list命令展现用户权限列表
（1）数据说明
2、使用acl cat命令
（1）查看添加权限指令类别
（2）加参数类型名可以查看类型下具体命令
3、使用acl whoami命令查看当前用户
4、使用aclsetuser命令创建和编辑用户ACL
（1）ACL规则
下面是有效ACL规则的列表。某些规则只是用于激活或删除标志，或对用户ACL执行给定更改的单个单词。其他规则是字符前缀，它们与命令或类别名称、键模式等连接在一起。
| ACL规则 | ||
|---|---|---|
| 类型 | 参数 | 说明 |
| 启动和禁用用户 | on | 激活某用户账号 |
| off | 禁用某用户账号。注意，已验证的连接仍然可以工作。如果默认用户被标记为off，则新连接将在未进行身份验证的情况下启动，并要求用户使用AUTH选项发送AUTH或HELLO，以便以某种方式进行身份验证。 | |
| 权限的添加删除 | <command> | 将指令添加到用户可以调用的指令列表中 |
| <command> | 从用户可执行指令列表移除指令 | |
| @<category> | 添加该类别中用户要调用的所有指令，有效类别为@admin、@set、@sortedset…等，通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令，包括当前存在于服务器中的命令，以及将来将通过模块加载的命令。 | |
| -@<actegory> | 从用户可调用指令中移除类别 | |
| allcommands | +@all的别名 | |
| nocommand | -@all的别名 | |
| 可操作键的添加或删除 | ~<pattern> | 添加可作为用户可操作的键的模式。例如~*允许所有的键 |
（2）通过命令创建新用户默认权限
acl setuser user1
在上面的示例中，我根本没有指定任何规则。如果用户不存在，这将使用just created的默认属性来创建用户。如果用户已经存在，则上面的命令将不执行任何操作。
（3）设置有用户名、密码、ACL权限、并启用的用户
acl setuser user2 on >password ~cached:* +get
(4)切换用户，验证权限
19.2 IO多线程
简介
Redis6终于支撑多线程了，告别单线程了吗？
IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。
原理架构
Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。整体的设计大体如下:
另外，多线程IO默认也是不开启的，需要再配置文件中配置
io-threads-do-reads yes
io-threads 4
工具支持 Cluster
之前老版Redis想要搭集群需要单独安装ruby环境，Redis 5 将 redis-trib.rb 的功能集成到 redis-cli 。另外官方 redis-benchmark 工具开始支持 cluster 模式了，通过多线程的方式对多个分片进行压测。
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一开始就是一个向编写各种系统开放的平台。
版权声明：本文标题：Redis基础 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/xitong/1729567527a1206661.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论