redis

最新推荐文章于 2025-05-28 16:17:51 发布

Charon246

最新推荐文章于 2025-05-28 16:17:51 发布

阅读量558

点赞数 24

文章标签： redis

本文链接：https://blog.youkuaiyun.com/qq_60511763/article/details/145642949

版权

Redis 入门到精通

1 NoSQL数据库简介

1.1 技术发展

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

1.1.1 Web1.0时代

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

1.1.2 Web2.0时代

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

1.1.3 解决CPU及内存压力

1.1.4 解决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的结构化查询存储，处理复杂的关系,需要即席查询。
（用不着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

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

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

1.4 图关系型数据库

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

1.5 数据库排名

http://db-engines.com/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://http://redis.io	http://redis.cn/

2.2.1 安装版本

6.0.6 for Linux（redis-6.0.6.tar.gz）
不用考虑在windows环境下对Redis的支持

2.2.2 安装步骤

2.2.2.1 准备工作：下载安装最新版的gcc编译器

安装C语言的编译环境

yum install centos-release-scl scl-utils-buildyum install -y devtoolset-8-toolchainscl enable devtoolset-8 bash

测试gcc版本
gcc --version
如果没有安装执行
yum install gcc

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

2.2.2.3 解压命令：tar -zxvf redis-6.0.6.tar.gz

2.2.2.4 解压完成后进入目录：cd redis-6.0.6

2.2.2.5 在redis-6.0.6目录下再次执行make命令（只是编译好）

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

2.2.2.7 解决方案：运行make distclean

2.2.2.8 在redis-6.0.6目录下再次执行make命令（只是编译好）

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

2.2.3 安装目录：/usr/local/bin

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

2.2.4 前台启动（不推荐）

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

2.2.5 后台启动（推荐）

2.2.5.1 备份redis.conf

拷贝一份redis.conf到其他目录
cd /opt/redis-6.0.6
cp redis.conf /etc/redis.conf

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

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

2.2.5.3 Redis启动

cd /usr/local/bin
redis-server /etc/redis.conf

2.2.5.4 用客户端访问：redis-cli

2.2.5.5 多个端口可以：redis-cli -p6379

2.2.5.6 测试验证： ping

2.2.5.7 Redis关闭

单实例关闭：redis-cli shutdown

也可以进入终端后再关闭

多实例关闭，指定端口关闭：redis-cli -p 6379 shutdown

2.2.6 Redis介绍相关知识

Redis是单线程+多路IO复用技术
多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）
串行 vs 多线程+锁（memcached） vs 单线程+多路IO复用(Redis)
（与Memcache三点不同: 支持多数据类型，支持持久化，单线程+多路IO复用）

3 常用五大数据类型

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

3.1 Redis键(key)

keys * 查看当前库所有key
exists key判断某个key是否存在
type key 查看你的key是什么类型
del key 删除指定的key数据
unlink key 根据value选择非阻塞删除
仅将keys从keyspace元数据中删除，真正的删除会在后续异步操作。
expire key 10 10秒钟：为给定的key设置过期时间
ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期

select 1 命令切换数据库
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>添加键值对
setnx：当数据库中key不存在时，可以将key-value添加数据库
setxx：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥
setex：key的超时秒数
setpx：key的超时毫秒数，与EX互斥

get <key>查询对应键值
append <key><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次,值是多少？

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>
用覆写所储存的字符串值，从<起始位置>开始(索引从0开始)。

setex <key><过期时间><value>
设置键值的同时，设置过期时间，单位秒。
getset <key><value>
以新换旧，设置了新值同时获得旧值。

3.2.3 数据结构

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

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

3.3.Redis列表(List)

3.3.1 简介

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

3.3.2 常用命令

lpush/rpush <key><value1><value2><value3> .... 从左边/右边插入一个或多个值。

lpop/rpop <key>从左边/右边吐出一个值。值在键在，值光键亡。

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

lrange <key><start><stop>
按照索引下标获得元素(从左到右)，例如
lrange mylist 0 -1 0为左边第一个，-1为右边第一个，（0 -1表示获取所有）

lindex <key><index>按照索引下标获得元素(从左到右)

llen <key>获得列表长度

linsert <key> before/after <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.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>判断集合是否为含有该值，有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.5 Redis哈希（Hash）

3.5.1 简介

Redis hash 是一个键值对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
类似Java里面的Map<String,Object>
用户ID为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储
主要有以下2种存储方式：

每次修改用户的某个属性需要，先反序列化改好后再序列化回去。开销较大。

用户ID数据冗余

通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题

3.5.2 常用命令

hset <key><field><value>给集合中的键赋值

hget <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.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 当中。

zrange <key><start><stop> [WITHSCORES]
返回有序集 key 中，下标在之间的元素，带WITHSCORES，可以让分数一起和值返回到结果集。

zrangebyscore key minmax [withscores] [limit offset count]
返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。

zrevrangebyscore key maxmin [withscores] [limit offset count]同上，改为从大到小排列。

zincrby <key><increment><value>为元素的score加上增量

zrem <key><value>删除该集合下，指定值的元素

zcount <key><min><max>统计该集合，分数区间内的元素个数

zrank <key><value>返回该值在集合中的排名，从0开始。

例：如何利用zset实现一个文章访问量的排行榜？

3.6.3 数据结构

SortedSet(zset)是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String, Double>，可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。
zset底层使用了两个数据结构
（1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。
（2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

3.6.4 跳跃表（跳表）

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

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

从第2层开始，1节点比51节点小，向后比较。
21节点比51节点小，继续向后比较，后面就是NULL了，所以从21节点向下到第1层
在第1层，41节点比51节点小，继续向后，61节点比51节点大，所以从41向下
在第0层，51节点为要查找的节点，节点被找到，共查找4次。
从此可以看出跳跃表比有序链表效率要高。

Redis新数据类型

Bitmaps

简介

现代计算机用二进制（位）作为信息的基础单位， 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中叫做偏移量。

命令

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:20201106代表2020-11-06这天的独立访问用户的Bitmaps

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

2、getbit
（1）格式
getbit <key><offset>获取Bitmaps中某个偏移量的值

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

（2）实例
获取id=8的用户是否在2020-11-06这天访问过，返回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)实例
计算2022-11-06这天的独立访问用户数量

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)实例
2020-11-04 日访问网站的userid=1,2,5,9。
setbit unique:users:20201104 1 1
setbit unique:users:20201104 2 1
setbit unique:users:20201104 5 1
setbit unique:users:20201104 9 1

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

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

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

Bitmaps与set对比

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

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

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

HyperLogLog

简介

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。
但像UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。
解决基数问题有很多种方案：
（1）数据存储在MySQL表中，使用distinct count计算不重复个数
（2）使用Redis提供的hash、set、bitmaps等数据结构来处理
以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。
能否能够降低一定的精度来平衡存储空间？Redis推出了HyperLogLog
Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。
但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

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

命令

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）实例

3、pfmerge
（1）格式
pfmerge <destkey><sourcekey> [sourcekey ...] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得
（2）实例

Geospatial

简介

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

命令

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）实例

事务

概述

Redis 事务的本质是一组命令的集合

事务支持一次执行多个命令，一个事务中所有命令都会被序列化。

在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

所以说：Redis 事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

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

批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行。

Redis 事务不保证原子性

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。

事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务的三个阶段

开始事务
命令入队
执行事务

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

事务的错误处理

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

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

命令

监听

watch

watch key1 key2 ...

监视一或多个 key，如果在事务执行之前，被监视的 key 被其他命令改动，则事务被打断（类似乐观锁）。

取消监听

unwatch

取消对所有 key 的监控。

标记

multi

标记一个事务块的开始，形成队列（queued）。

执行

exec

执行所有事务块（一旦执行 exec 后，之前加的监控锁都会被取消掉）。

取消

discard

取消事务，放弃事务块中的所有命令。

实践

正常执行

127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379(TX)> set k1 v1 # 命令入队
QUEUED
127.0.0.1:6379(TX)> set k2 v2 # 命令入队
QUEUED
127.0.0.1:6379(TX)> get k2 # 命令入队
QUEUED127.0.0.1:6379(TX)> set k3 v3 # 命令入队
QUEUED
127.0.0.1:6379(TX)> exec # 执行事务
1)
OK
2)
OK
3)
"v2"
4) 
OK
127.0.0.1:6379> get k1 # set命令执行成功
"v1"
127.0.0.1:6379> get k2 # set命令执行成功
"v2"

开启事务后，会出现 TX 标志，此时所有的操作不会马上有结果，而是形成队列（QUEUED），待执行事务后，会将所有命令按顺序执行。

放弃事务

127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379(TX)> set k1 v1 # 命令入队
QUEUED
127.0.0.1:6379(TX)> set k2 v2 # 命令入队
QUEUED
127.0.0.1:6379(TX)> set k3 33 # 命令入队
QUEUED
127.0.0.1:6379(TX)> discard # 取消事务
OK
127.0.0.1:6379> get k3 # set命令未执行
"v3"

事务中存在命令性错误

若在事务队列中存在命令性错误（类似于java编译性错误），则执行 exec 命令时，所有命令都不会执行。

127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379(TX)> set k1 11 # 命令入队
QUEUED
127.0.0.1:6379(TX)> getset k2 # 错误命令(error)
ERR wrong number of arguments for 'getset' command
127.0.0.1:6379(TX)> set k2 22 # 命令入队
QUEUED
127.0.0.1:6379(TX)> exec # 执行事务，报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1 # set命令未执行
"v1"
127.0.0.1:6379> get k2 # set命令未执行
"v2"

事务中存在语法性错误

若在事务队列中存在语法性错误（类似于 Java 的的运行时异常），则执行 exec 命令时，其他正确命令会被执行，错误命令抛出异常。

127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379(TX)> set k4 v4 # 命令入队
QUEUED
127.0.0.1:6379(TX)> incr k4 # 命令入队（对“v4”进行 +1 ，会报语法错误）
QUEUED
127.0.0.1:6379(TX)> set k5 v5 # 命令入队
QUEUED
127.0.0.1:6379(TX)> exec # 执行事务
1) 
OK
2) 
(error) ERR value is not an integer or out of range # 执行错误的命令会报错，其余命令正常执行
3) 
OK
127.0.0.1:6379> get k4 # set命令执行成功
"v4"
127.0.0.1:6379> get k5 # set命令执行成功
"v5"

监听

悲观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观。

每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁。

这样别人想拿到这个数据就会 block 直到它拿到锁。

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

乐观锁

乐观锁（Optimistic Lock），顾名思义，就是很乐观。

每次去拿数据的时候都认为别人不会修改，所以不会上锁。

但是在更新的时候会判断一下再此期间别人有没有去更新这个数据，可以使用版本号等机制。

乐观锁适用于多读的应用类型，这样可以提高吞吐量。

乐观锁策略：提交版本必须大于记录当前版本才能执行更新。

实践

初始化信用卡可用余额和欠额

127.0.0.1:6379>set balance 100
OK
127.0.0.1:6379> set debt 0
OK

使用 watch 监听 balance，事务期间 balance 数据未变动，事务执行成功。

127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby balance 20
QUEUED
127.0.0.1:6379(TX)> incrby debt 20
QUEUED
127.0.0.1:6379(TX)> exec
1) 
(integer) 80
2) 
(integer)20

使用 watch 监听 balance，事务期间 balance 数据变动，事务执行失败。

窗口 1：

127.0.0.1:6379> watch balanceOK
127.0.0.1:6379>multi
OK

窗口 2：

127.0.0.1:6379> get balance"80"
127.0.0.1:6379> set balance 200
OK

窗口 1：

127.0.0.1:6379(TX)> decrby balance 20QUEUED127.0.0.1:6379(TX)> incrby detb 20QUEUED127.0.0.1:6379(TX)> exec(nil)127.0.0.1:6379> get balance"200"

由于窗口 1 监听 balance 并开启事务后，窗口 2 修改了 balance 的值，导致窗口 1 的监听失败，执行事务后展示为空，且 balance 的值不是预期值。

监听失败后放弃监听，然后重来

窗口 1：

127.0.0.1:6379> unwatch
OK
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby balance 20
QUEUED
127.0.0.1:6379(TX)> incrby debt 20
QUEUED
127.0.0.1:6379(TX)> exec
1) 
(integer) 180
2) 
(integer) 40

小结

一旦执行 exec 开启事务后，无论事务是否执行成功， watch 对变量的监听都将被取消。
当事务执行失败后，需重新执行 watch 命令对变量进行监听，并开启新的事务进行操作。
watch 指令类似于乐观锁，在事务提交时，如果 watch 监控的多个 key 中任何 key 的值已经被其他客户端更改。

则使用 exec 执行事务时，事务队列将不会被执行，同时返回 (nil) 应答以通知调用者事务执行失败。

jedis

概述

Jedis 是 Redis 官方推荐的 Java 连接开发工具。

Jedis 客户端同时支持单机模式、分片模式、集群模式的访问模式：

通过构建 Jedis 类对象实现单机模式下的数据访问。
通过构建 ShardedJedis 类对象实现分片模式的数据访问。
通过构建 JedisCluster 类对象实现集群模式下的数据访问。

Jedis 客户端支持单命令和 Pipeline 方式访问 Redis 集群，通过 Pipeline 的方式能够提高集群访问的效率。

测试

新建一个普通的 Maven 项目。

导入 Jedis、slf4j-log4j12 的依赖。

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>4.2.3</version>
</dependency>
<dependency>
     <groupId>com.alibaba</groupId>
     <artifactId>fastjson</artifactId>
     <version>1.2.47</version>
</dependency>

编写测试代码

// 192.168.80.129 为服务器地址
 // 1 new jedis 对象
        Jedis jedis = new Jedis("192.168.80.129", 6379);
        jedis.auth("0414");
        System.out.println(jedis.ping());

输出结果为：

PONG

出现这个结果即代表 Java 连接 Redis 成

连接前，需要先进行检查：

redis 是否关闭了远程连接

检查 redis.conf 中的配置

如果设置了 bind 127.0.0.1 ::1 ，代表只能本地访问，需要注释掉。

如果设置了 protected-mode yes ，代表开启了保护模式，需要改为 protected-mode no，关闭保护模式。

修改配置后需要重启 Redis 服务。

防火墙是否拦截了 6379 端口

放行 6379 端口

firewall-cmd --zone=public --add-port=6379/tcp --permanent

重启防火墙

systemctl restart firewalld

基本API

验证密码

jedis.auth("");

如果没有密码则不需要验证。

连接

jedis.connect();

断开连接

jedis.disconnect();

操作 key

Jedis jedis = new Jedis("192.168.80.129", 6379);
        jedis.auth("0414");
        System.out.println("清空数据：" + jedis.flushDB());
        System.out.println("判断某个键是否存在：" + jedis.exists("username"));
        System.out.println("新增<'username','kuangshen'>的键值对：" + jedis.set("username", "kuangshen"));
        System.out.println("新增<'password','password'>的键值对：" + jedis.set("password", "password"));
        System.out.print("系统中所有的键如下：");
        Set<String> keys = jedis.keys("*");
        System.out.println(keys);
        System.out.println("删除键password:" + jedis.del("password"));
        System.out.println("判断键password是否存在：" + jedis.exists("password"));
        System.out.println("查看键username所存储的值的类型：" + jedis.type("username"));
        System.out.println("随机返回key空间的一个：" + jedis.randomKey());
        System.out.println("重命名key：" + jedis.rename("username", "name"));
        System.out.println("取出改后的name：" + jedis.get("name"));
        System.out.println("按索引查询：" + jedis.select(0));
        System.out.println("删除当前选择数据库中的所有key：" + jedis.flushDB());
        System.out.println("返回当前数据库中key的数目：" + jedis.dbSize());
        System.out.println("删除所有数据库中的所有key：" + jedis.flushAll());

操作 String

Jedis jedis = new Jedis("192.168.80.129", 6379);
jedis.auth("0414");
jedis.flushDB();
System.out.println("===========增加数据===========");
System.out.println(jedis.set("key1", "value1"));
System.out.println(jedis.set("key2", "value2"));
System.out.println(jedis.set("key3", "value3"));
System.out.println("删除键key2:" + jedis.del("key2"));
System.out.println("获取键key2:" + jedis.get("key2"));
System.out.println("修改key1:" + jedis.set("key1", "value1Changed"));
System.out.println("获取key1的值：" + jedis.get("key1"));
System.out.println("在key3后面加入值：" + jedis.append("key3", "End"));
System.out.println("key3的值：" + jedis.get("key3"));
System.out.println("增加多个键值对：" + jedis.mset("key01", "value01", "key02", "value02", "key03", "value03"));
System.out.println("获取多个键值对：" + jedis.mget("key01", "key02", "key03"));
System.out.println("获取多个键值对：" + jedis.mget("key01", "key02", "key03", "key04"));
System.out.println("删除多个键值对：" + jedis.del("key01", "key02"));
System.out.println("获取多个键值对：" + jedis.mget("key01", "key02", "key03"));
jedis.flushDB();
System.out.println("===========新增键值对防止覆盖原先值==============");
System.out.println(jedis.setnx("key1", "value1"));
System.out.println(jedis.setnx("key2", "value2"));
System.out.println(jedis.setnx("key2", "value2-new"));
System.out.println(jedis.get("key1"));
System.out.println(jedis.get("key2"));
System.out.println("===========新增键值对并设置有效时间=============");
System.out.println(jedis.setex("key3", 2, "value3"));
System.out.println(jedis.get("key3"));
try {
    TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
    e.printStackTrace();
}
System.out.println(jedis.get("key3"));
System.out.println("===========获取原值，更新为新值==========");
System.out.println(jedis.getSet("key2", "key2GetSet"));
System.out.println(jedis.get("key2"));
System.out.println("获得key2的值的字串：" + jedis.getrange("key2", 2, 4));

操作 List

Jedis jedis = new Jedis("192.168.80.129", 6379);
jedis.auth("0414");
jedis.flushDB();
System.out.println("===========添加一个list===========");
jedis.lpush("collections", "ArrayList", "Vector", "Stack", "HashMap", "WeakHashMap", "LinkedHashMap");
jedis.lpush("collections", "HashSet");
jedis.lpush("collections", "TreeSet");
jedis.lpush("collections", "TreeMap");
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));//-1代表倒数第一个元素，-2代表倒数第二个元素,end为-1表示查询全部
System.out.println("collections区间0-3的元素：" + jedis.lrange("collections", 0, 3));
System.out.println("===============================");
// 删除列表指定的值 ，第二个参数为删除的个数（有重复时），后add进去的值先被删，类似于出栈
System.out.println("删除指定元素个数：" + jedis.lrem("collections", 2, "HashMap"));
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));
System.out.println("删除下表0-3区间之外的元素：" + jedis.ltrim("collections", 0, 3));
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));
System.out.println("collections列表出栈（左端）：" + jedis.lpop("collections"));
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));
System.out.println("collections添加元素，从列表右端，与lpush相对应：" + jedis.rpush("collections", "EnumMap"));
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));
System.out.println("collections列表出栈（右端）：" + jedis.rpop("collections"));
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));
System.out.println("修改collections指定下标1的内容：" + jedis.lset("collections", 1, "LinkedArrayList"));
System.out.println("collections的内容：" + jedis.lrange("collections", 0, -1));
System.out.println("===============================");
System.out.println("collections的长度：" + jedis.llen("collections"));
System.out.println("获取collections下标为2的元素：" + jedis.lindex("collections", 2));
System.out.println("===============================");
jedis.lpush("sortedList", "3", "6", "2", "0", "7", "4");
System.out.println("sortedList排序前：" + jedis.lrange("sortedList", 0, -1));
System.out.println(jedis.sort("sortedList"));
System.out.println("sortedList排序后：" + jedis.lrange("sortedList", 0, -1));

操作 Set

Jedis jedis = new Jedis("192.168.80.129", 6379);
jedis.auth("0414");
jedis.flushDB();
System.out.println("============向集合中添加元素（不重复）============");
System.out.println(jedis.sadd("eleSet", "e1", "e2", "e4", "e3", "e0", "e8", "e7", "e5"));
System.out.println(jedis.sadd("eleSet", "e6"));
System.out.println(jedis.sadd("eleSet", "e6"));
System.out.println("eleSet的所有元素为：" + jedis.smembers("eleSet"));
System.out.println("删除一个元素e0：" + jedis.srem("eleSet", "e0"));
System.out.println("eleSet的所有元素为：" + jedis.smembers("eleSet"));
System.out.println("删除两个元素e7和e6：" + jedis.srem("eleSet", "e7", "e6"));
System.out.println("eleSet的所有元素为：" + jedis.smembers("eleSet"));
System.out.println("随机的移除集合中的一个元素：" + jedis.spop("eleSet"));
System.out.println("随机的移除集合中的一个元素：" + jedis.spop("eleSet"));
System.out.println("eleSet的所有元素为：" + jedis.smembers("eleSet"));
System.out.println("eleSet中包含元素的个数：" + jedis.scard("eleSet"));
System.out.println("e3是否在eleSet中：" + jedis.sismember("eleSet", "e3"));
System.out.println("e1是否在eleSet中：" + jedis.sismember("eleSet", "e1"));
System.out.println("e1是否在eleSet中：" + jedis.sismember("eleSet", "e5"));
System.out.println("=================================");
System.out.println(jedis.sadd("eleSet1", "e1", "e2", "e4", "e3", "e0", "e8", "e7", "e5"));
System.out.println(jedis.sadd("eleSet2", "e1", "e2", "e4", "e3", "e0", "e8"));
//移到集合元素
System.out.println("将eleSet1中删除e1并存入eleSet3中：" + jedis.smove("eleSet1", "eleSet3", "e1"));
System.out.println("将eleSet1中删除e2并存入eleSet3中：" + jedis.smove("eleSet1", "eleSet3", "e2"));
System.out.println("eleSet1中的元素：" + jedis.smembers("eleSet1"));
System.out.println("eleSet3中的元素：" + jedis.smembers("eleSet3"));
System.out.println("============集合运算=================");
System.out.println("eleSet1中的元素：" + jedis.smembers("eleSet1"));
System.out.println("eleSet2中的元素：" + jedis.smembers("eleSet2"));
System.out.println("eleSet1和eleSet2的交集:" + jedis.sinter("eleSet1", "eleSet2"));
System.out.println("eleSet1和eleSet2的并集:" + jedis.sunion("eleSet1", "eleSet2"));
//eleSet1中有，eleSet2中没有
System.out.println("eleSet1和eleSet2的差集:" + jedis.sdiff("eleSet1", "eleSet2"));
//求交集并将交集保存到dstkey的集合
jedis.sinterstore("eleSet4", "eleSet1", "eleSet2");
System.out.println("eleSet4中的元素：" + jedis.smembers("eleSet4"));

操作 Hash

Jedis jedis = new Jedis("192.168.80.129", 6379);
jedis.auth("0414");
jedis.flushDB();
Map<String, String> map = new HashMap<>();
map.put("key1", "value1");
map.put("key2", "value2");
map.put("key3", "value3");
map.put("key4", "value4");
// 添加名称为 hash（key）的 hash 元素
jedis.hmset("hash", map);
// 向名称为 hash 的 hash 中添加 key 为 key5，value 为 value5 元素
jedis.hset("hash", "key5", "value5");
// return Map<String,String>
System.out.println("散列hash的所有键值对为：" + jedis.hgetAll(" hash"));
// return Set<String>
System.out.println("散列hash的所有键为：" + jedis.hkeys("hash"));
// return List<String>
System.out.println("散列hash的所有值为：" + jedis.hvals("hash"));
System.out.println("将key6保存的值加上一个整数，如果key6不存在则添加key6：" + jedis.hincrBy(" hash", " key6", 6));
System.out.println("散列hash的所有键值对为：" + jedis.hgetAll("hash"));
System.out.println("将key6保存的值加上一个整数，如果key6不存在则添加key6：" + jedis.hincrBy(" hash", " key6", 3));
System.out.println("散列hash的所有键值对为：" + jedis.hgetAll("hash"));
System.out.println("删除一个或者多个键值对：" + jedis.hdel("hash", "key2"));
System.out.println("散列hash的所有键值对为：" + jedis.hgetAll("hash"));
System.out.println("散列hash中键值对的个数：" + jedis.hlen("hash"));
System.out.println("判断hash中是否存在key2：" + jedis.hexists(" hash", " key2"));
System.out.println("判断hash中是否存在key3：" + jedis.hexists(" hash", " key3"));
System.out.println("获取hash中的值：" + jedis.hmget("hash", "key3"));
System.out.println("获取hash中的值：" + jedis.hmget(" hash", " key3", " key4"));

事务

//创建客户端连接服务端，redis服务端需要被开启
Jedis jedis = new Jedis("192.168.80.129", 6379);
jedis.auth("0414");
jedis.flushDB();
JSONObject jsonObject = new JSONObject();
jsonObject.put("hello", "world");
jsonObject.put("name", "java");
//开启事务
Transaction multi = jedis.multi();
String result = jsonObject.toJSONString();
try {
    //向redis存入一条数据
    multi.set("json", result);
    //再存入一条数据
    multi.set("json2", result);
    //这里引发了异常，用0作为被除数
    int i = 100 / 0;
    //如果没有引发异常，执行进入队列的命令
    multi.exec();
} catch (Exception e) {
    e.printStackTrace();
    //如果出现异常，回滚
    multi.discard();
} finally {
    System.out.println(jedis.get("json"));
    System.out.println(jedis.get("json2"));
    //最终关闭客户端
    jedis.close();
}

整合SpringBoot

概述

SpringBoot 整合 Redis 是使用 SpringData 实现的。

SpringData 是与 SpringBoot 齐名的顶级项目，整合了对常用数据库的模板型操作。

在 SpringBoot 2.x 之后，Jedis 被 Lettuce 替代了。

Jedis

采用的直连，多个线程操作的话，是不安全的。

如果想要避免不安全，就要使用 Jedis pool 连接池解决。

这样是有一些弊端的，比如线程数量太多了，Redis 服务就比较庞大，而且它是阻塞的。

Lettuce

底层采用 Netty，实例可以在多个线程中进行共享。

不存在线程不安全的情况，可以减少线程数量。

使用

导入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

yaml 配置

spring:
  redis:
    host: 192.168.80.129
    port: 6379
    password: 0414
    jedis:
      pool:
        max-active: 8
        max-wait: -1ms
        max-idle: 500
        min-idle: 0
    lettuce:
      shutdown-timeout: 0ms

测试

@Resource
private RedisTemplate redisTemplate;
@Test
void contextLoads() {
    redisTemplate.opsForValue().set("myKey", "myValue");
    System.out.println(redisTemplate.opsForValue().get("myKey"));
}

输出为：myValue，连接成功。

源码分析

RedisAutoConfiguration

@AutoConfiguration
@ConditionalOnClass({RedisOperations.class})
@EnableConfigurationProperties({RedisProperties.class})
@Import({LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class})
public class RedisAutoConfiguration {
    public RedisAutoConfiguration() {
    }
    @Bean
    @ConditionalOnMissingBean(
        name = {"redisTemplate"}
    )
    @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 默认的 RedisTemplate 没有过多的设置，Redis 对象都是需要序列化的
        // 两个泛型都是 Object 的类型，我们使用需要强制转换，很不方便，预期是 <String, Object>
        RedisTemplate<Object, Object> template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }
    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    // 由于 String 是 Redis 最常使用的类型，所以说单独提出来了一个 Bean
    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        return new StringRedisTemplate(redisConnectionFactory);
    }
}

通过源码可以看出，SpringBoot 自动帮我们在容器中生成了一个 RedisTemplate 和一个 StringRedisTemplate。

但是，这个 RedisTemplate 的泛型是 <Object, Object>，写代码不方便，需要写好多类型转换的代码。

我们需要一个泛型为 <String, Object> 形式的 RedisTemplate。

并且，这个 RedisTemplate 没有设置数据存在 Redis 时，key 及 value 的序列化方式。

由 @ConditionalOnMissingBean 可以看出，如果 Spring 容器中有了自定义的 RedisTemplate 对象，自动配置的 RedisTemplate 不会实例化。

因此我们可以直接自己写个配置类，配置 RedisTemplate。

自定义 Redis 模板

package com.lei.config;
/**
 * @author lei
 * @verson:1.8
 *  自定义 Redis 模板
 */
@Configuration
public class RedisConfig {

    @Bean
    //@SuppressWarnings("all")告诉编译器对被注解的作用域内部警告保持静默。
    @SuppressWarnings("all")
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        //     定义泛型为 <String, Object> 的 RedisTemplate
        RedisTemplate<String, Object> template = new RedisTemplate<String, Object>();
        // 设置连接工厂
        template.setConnectionFactory(factory);
        // 定义 Json 序列化
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        // Json 转换工具
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        // 定义 String 序列化
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
        // key采用String的序列化方式
        template.setKeySerializer(stringRedisSerializer);
        // hash的key也采用String的序列化方式
        template.setHashKeySerializer(stringRedisSerializer);
        // value序列化方式采用jackson
        template.setValueSerializer(jackson2JsonRedisSerializer);
        // hash的value序列化方式采用jackson
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        template.afterPropertiesSet();
        return template;
    }

}

直接用 RedisTemplate 操作 Redis，比较繁琐。

因此直接封装好一个 RedisUtils，这样写代码更方便点。

这个 RedisUtils 交给Spring容器实例化，使用时直接注解注入

Redis 工具类

package com.lei.util;
import java.util.Collection;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.TimeUnit;
import javax.annotation.Resource;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
import org.springframework.util.CollectionUtils;

/**
 * Redis 工具类
 *
 * @author
 * @date 
 */
@Component
public class RedisUtil {
    @Resource
    private RedisTemplate<String, Object> redisTemplate;
    // =============================Common 基础============================
    /**
     * 指定缓存失效时间
     *
     * @param key  键
     * @param time 时间(秒)
     */
    public boolean expire(String key, long time) {
        try {
            if (time > 0) {
                redisTemplate.expire(key, time, TimeUnit.SECONDS);
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 根据key 获取过期时间
     *
     * @param key 键 不能为null
     * @return 时间(秒) 返回0代表为永久有效
     */
    public long getExpire(String key) {
        // 如果返回值为 null，则返回 0L
        return redisTemplate.getExpire(key, TimeUnit.SECONDS);
    }
    /**
     * 判断key是否存在
     *
     * @param key 键
     * @return true 存在 false不存在
     */
    public boolean hasKey(String key) {
        try {
            return Boolean.TRUE.equals(redisTemplate.hasKey(key));
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 删除缓存
     *
     * @param key 可以传一个值 或多个
     */
    @SuppressWarnings("unchecked")
    public void del(String... key) {
        if (key != null && key.length > 0) {
            if (key.length == 1) {
                redisTemplate.delete(key[0]);
            } else {
                redisTemplate.delete((Collection<String>) CollectionUtils.arrayToList(key));
            }
        }
    }
    // ============================String 字符串=============================
    /**
     * 普通缓存获取
     *
     * @param key 键
     * @return 值
     */
    public Object get(String key) {
        return key == null ? null : redisTemplate.opsForValue().get(key);
    }
    /**
     * 普通缓存放入
     *
     * @param key   键
     * @param value 值
     * @return true成功 false失败
     */
    public boolean set(String key, Object value) {
        try {
            redisTemplate.opsForValue().set(key, value);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 普通缓存放入并设置时间
     *
     * @param key   键
     * @param value 值
     * @param time  时间(秒) time要大于0 如果time小于等于0 将设置无限期
     * @return true成功 false 失败
     */
    public boolean set(String key, Object value, long time) {
        try {
            if (time > 0) {
                redisTemplate.opsForValue().set(key, value, time,
                        TimeUnit.SECONDS);
            } else {
                set(key, value);
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 递增
     *
     * @param key   键
     * @param delta 要增加几(大于0)
     */
    public long incr(String key, long delta) {
        if (delta < 0) {
            throw new RuntimeException("递增因子必须大于0");
        }
        return redisTemplate.opsForValue().increment(key, delta);
    }
    /**
     * 递减
     *
     * @param key   键
     * @param delta 要减少几(小于0)
     */
    public long decr(String key, long delta) {
        if (delta < 0) {
            throw new RuntimeException("递减因子必须大于0");
        }
        return redisTemplate.opsForValue().increment(key, -delta);
    }
    // ===============================List 列表=================================
    /**
     * 获取list缓存的内容
     *
     * @param key   键
     * @param start 开始
     * @param end   结束 0 到 -1代表所有值
     */
    public List<Object> lGet(String key, long start, long end) {
        try {
            return redisTemplate.opsForList().range(key, start, end);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
    /**
     * 获取list缓存的长度
     *
     * @param key 键
     */
    public long lGetListSize(String key) {
        try {
            return redisTemplate.opsForList().size(key);
        } catch (Exception e) {
            e.printStackTrace();
            return 0;
        }
    }
    /**
     * 通过索引 获取list中的值
     *
     * @param key   键
     * @param index 索引 index>=0时， 0 表头，1 第二个元素，依次类推；index<0
     *              时，-1，表尾，-2倒数第二个元素，依次类推
     */
    public Object lGetIndex(String key, long index) {
        try {
            return redisTemplate.opsForList().index(key, index);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
    /**
     * 将list放入缓存
     *
     * @param key   键
     * @param value 值
     */
    public boolean lSet(String key, Object value) {
        try {
            redisTemplate.opsForList().rightPush(key, value);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 将list放入缓存
     *
     * @param key   键
     * @param value 值
     * @param time  时间(秒)
     */
    public boolean lSet(String key, Object value, long time) {
        try {
            redisTemplate.opsForList().rightPush(key, value);
            if (time > 0) {
                expire(key, time);
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 将list放入缓存
     *
     * @param key   键
     * @param value 值
     * @return 赋值结果
     */
    public boolean lSet(String key, List<Object> value) {
        try {
            redisTemplate.opsForList().rightPushAll(key, value);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 将list放入缓存
     *
     * @param key   键
     * @param value 值
     * @param time  时间(秒)
     * @return 赋值结果
     */
    public boolean lSet(String key, List<Object> value, long time) {
        try {
            redisTemplate.opsForList().rightPushAll(key, value);
            if (time > 0) {
                expire(key, time);
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 根据索引修改list中的某条数据
     *
     * @param key   键
     * @param index 索引
     * @param value 值
     * @return 赋值结果
     */
    public boolean lUpdateIndex(String key, long index, Object value) {
        try {
            redisTemplate.opsForList().set(key, index, value);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 移除N个值为value
     *
     * @param key   键
     * @param count 移除多少个
     * @param value 值
     * @return 移除的个数
     */
    public long lRemove(String key, long count, Object value) {
        try {
            return redisTemplate.opsForList().remove(key, count, value);
        } catch (Exception e) {
            e.printStackTrace();
            return 0;
        }
    }
    // ============================Set 集合=============================
    /**
     * 根据key获取Set中的所有值
     *
     * @param key 键
     */
    public Set<Object> sGet(String key) {
        try {
            return redisTemplate.opsForSet().members(key);
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
    /**
     * 根据value从一个set中查询,是否存在
     *
     * @param key   键
     * @param value 值
     * @return true 存在 false不存在
     */
    public boolean sHasKey(String key, Object value) {
        try {
            return redisTemplate.opsForSet().isMember(key, value);
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 将数据放入set缓存
     *
     * @param key    键
     * @param values 值 可以是多个
     * @return 成功个数
     */
    public long sSet(String key, Object... values) {
        try {
            return redisTemplate.opsForSet().add(key, values);
        } catch (Exception e) {
            e.printStackTrace();
            return 0;
        }
    }
    /**
     * 将set数据放入缓存
     *
     * @param key    键
     * @param time   时间(秒)
     * @param values 值 可以是多个
     * @return 成功个数
     */
    public long sSetAndTime(String key, long time, Object... values) {
        try {
            Long count = redisTemplate.opsForSet().add(key, values);
            if (time > 0) {
                expire(key, time);
            }
            return count;
        } catch (Exception e) {
            e.printStackTrace();
            return 0;
        }
    }
    /**
     * 获取set缓存的长度
     *
     * @param key 键
     */
    public long sGetSetSize(String key) {
        try {
            return redisTemplate.opsForSet().size(key);
        } catch (Exception e) {
            e.printStackTrace();
            return 0;
        }
    }
    /**
     * 移除值为value的
     *
     * @param key    键
     * @param values 值 可以是多个
     * @return 移除的个数
     */
    public long setRemove(String key, Object... values) {
        try {
            return redisTemplate.opsForSet().remove(key, values);
        } catch (Exception e) {
            e.printStackTrace();
            return 0;
        }
    }
    // ================================Hash 哈希=================================
    /**
     * HashGet
     *
     * @param key  键 不能为null
     * @param item 项 不能为null
     */
    public Object hget(String key, String item) {
        return redisTemplate.opsForHash().get(key, item);
    }
    /**
     * 获取hashKey对应的所有键值
     *
     * @param key 键
     * @return 对应的多个键值
     */
    public Map<Object, Object> hmget(String key) {
        return redisTemplate.opsForHash().entries(key);
    }
    /**
     * HashSet
     *
     * @param key 键
     * @param map 对应多个键值
     */
    public boolean hmset(String key, Map<String, Object> map) {
        try {
            redisTemplate.opsForHash().putAll(key, map);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * HashSet 并设置时间
     *
     * @param key  键
     * @param map  对应多个键值
     * @param time 时间(秒)
     * @return true成功 false失败
     */
    public boolean hmset(String key, Map<String, Object> map, long time) {
        try {
            redisTemplate.opsForHash().putAll(key, map);
            if (time > 0) {
                expire(key, time);
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 向一张hash表中放入数据,如果不存在将创建
     *
     * @param key   键
     * @param item  项
     * @param value 值
     * @return true 成功 false失败
     */
    public boolean hset(String key, String item, Object value) {
        try {
            redisTemplate.opsForHash().put(key, item, value);
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 向一张hash表中放入数据,如果不存在将创建
     *
     * @param key   键
     * @param item  项
     * @param value 值
     * @param time  时间(秒) 注意:如果已存在的hash表有时间,这里将会替换原有的时间
     * @return true 成功 false失败
     */
    public boolean hset(String key, String item, Object value, long time) {
        try {
            redisTemplate.opsForHash().put(key, item, value);
            if (time > 0) {
                expire(key, time);
            }
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
    /**
     * 删除hash表中的值
     *
     * @param key  键 不能为null
     * @param item 项 可以使多个 不能为null
     */
    public void hdel(String key, Object... item) {
        redisTemplate.opsForHash().delete(key, item);
    }
    /**
     * 判断hash表中是否有该项的值
     *
     * @param key  键 不能为null
     * @param item 项 不能为null
     * @return true 存在 false不存在
     */
    public boolean hHasKey(String key, String item) {
        return redisTemplate.opsForHash().hasKey(key, item);
    }
    /**
     * hash递增 如果不存在,就会创建一个 并把新增后的值返回
     *
     * @param key  键
     * @param item 项
     * @param by   要增加几(大于0)
     */
    public double hincr(String key, String item, double by) {
        return redisTemplate.opsForHash().increment(key, item, by);
    }
    /**
     * hash递减
     *
     * @param key  键
     * @param item 项
     * @param by   要减少记(小于0)
     */
    public double hdecr(String key, String item, double by) {
        return redisTemplate.opsForHash().increment(key, item, -by);
    }
}

Redis配置文件介绍

Units单位

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

INCLUDES包含

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

网络相关配置

bind

默认情况bind=127.0.0.1只能接受本机的访问请求
不写的情况下，无限制接受任何ip地址的访问
生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉
如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

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

protected-mode

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

Port

端口号，默认 6379

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）两个值来达到想要的效果

timeout

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

tcp-keepalive

对访问客户端的一种心跳检测，每个n秒检测一次。
单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

GENERAL通用

daemonize

是否为后台进程，设置为yes
守护进程，后台启动

pidfile

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

loglevel

指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice
四个级别根据使用阶段来选择，生产环境选择notice 或者warning

logfile

日志文件名称

databases 16

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

SECURITY安全

设置密码

访问密码的查看、设置和取消
在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。
永久设置，需要再配置文件中进行设置。

LIMITS限制

maxclients

设置redis同时可以与多少个客户端进行连接。
默认情况下为10000个客户端。
如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

maxmemory

建议必须设置，否则，将内存占满，造成服务器宕机
设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。

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

设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。
一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。

持久化

概述

Redis 是内存数据库，即数据存储在内存。

如果不将内存中的数据保存到磁盘，一旦服务器进程退出，服务器中的数据也会消失。

这样会造成巨大的损失，所以 Redis 提供了持久化功能。

RDB

RDB，即 Redis DataBase

在指定的时间间隔内将内存中的数据集快照写入磁盘。

也就是 Snapshot 快照，恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化。

会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。

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

复制

Fork 的作用是复制一个与当前进程一样的进程。

新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一致。

这是一个全新的进程，并作为原进程的子进程。

RDB 保存的是 dump.rdb 文件：

[root@sail redis]# ls00-RELEASENOTES  BUGS     CONTRIBUTING  deps      INSTALL   MANIFESTO  redis.conf  runtest-cluster    runtest-sentinel  src    TLS.mdbin              CONDUCT  COPYING       dump.rdb  Makefile  README.md  runtest     runtest-moduleapi  sentinel.conf     tests  utils

配置

配置文件 redis.conf 中的快照配置

################################ SNAPSHOTTING  ################################
# Save the DB to disk.
#
# save <seconds> <changes>
#
# Redis will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save ""
#
# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 key changed
#   * After 300 seconds (5 minutes) if at least 100 keys changed
#   * After 60 seconds if at least 10000 keys changed
#
# You can set these explicitly by uncommenting the three following lines.
#
# save 3600 1
# save 300 100
# save 60 10000
# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes
# Compress string objects using LZF when dump .rdb databases?
# By default compression is enabled as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes
# Enables or disables full sanitation checks for ziplist and listpack etc when
# loading an RDB or RESTORE payload. This reduces the chances of a assertion or
# crash later on while processing commands.
# Options:
#   no         - Never perform full sanitation
#   yes        - Always perform full sanitation
#   clients    - Perform full sanitation only for user connections.
#                Excludes: RDB files, RESTORE commands received from the master
#                connection, and client connections which have the
#                skip-sanitize-payload ACL flag.
# The default should be 'clients' but since it currently affects cluster
# resharding via MIGRATE, it is temporarily set to 'no' by default.
#
# sanitize-dump-payload no
# The filename where to dump the DB
dbfilename dump.rdb
# Remove RDB files used by replication in instances without persistence
# enabled. By default this option is disabled, however there are environments
# where for regulations or other security concerns, RDB files persisted on
# disk by masters in order to feed replicas, or stored on disk by replicas
# in order to load them for the initial synchronization, should be deleted
# ASAP. Note that this option ONLY WORKS in instances that have both AOF
# and RDB persistence disabled, otherwise is completely ignored.
#
# An alternative (and sometimes better) way to obtain the same effect is
# to use diskless replication on both master and replicas instances. However
# in the case of replicas, diskless is not always an option.
rdb-del-sync-files no
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

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

save

save 3600 1
save 300 100
save 60 10000

默认：

1 分钟内改了 1 万次
5 分钟内改了 10 次
15 分钟内改了 1 次

如果想禁用 RDB 持久化的策略，只要不设置任何 save 指令，或者给 save 传入一个空字符串参数也可以。

若要修改完毕需要立马生效，可以手动使用 save 命令，立马生效。

stop-writes-on-bgsave-error

如果配置为 no，表示你不在乎数据不一致或者有其他的手段发现和控制，默认为 yes。

rbdcompression

对于存储到磁盘中的快照，可以设置是否进行压缩存储。

如果是的话，redis 会采用 LZF 算法进行压缩，如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能。

rdbchecksum

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

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

默认为 yes。

触发

配置文件中默认的快照配置，建议多用一台机子作为备份，复制一份 dump.rdb。
保存配置：
- save：只管保存，其他不管，全部阻塞。
- bgsave：Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。
- lastsave：获取最后一次成功执行快照的时间。
执行 flushall 命令，也会产生 dump.rdb 文件，但里面是空的，无意义。
退出的时候也会产生 dump.rdb 文件。

恢复

将备份文件 dump.rdb 移动到 redis 安装目录并启动服务即可。

本地数据库存放目录：

127.0.0.1:6379>config get dir
1) 
"dir"
2)"/usr/local/redis"

优缺点

优点

适合大规模的数据恢复。
对数据完整性和一致性要求不高时适用。

缺点

在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。
Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑。

小结

AOF

AOF，即 Append Only File

以日志的形式来记录每个写操作，将 Redis 执行过的所有指令记录下来（读操作不记录）。

只许追加文件，但不可以改写文件，Redis 启动之初会读取该文件重新构建数据。

换言之，Redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

配置

AOF 保存的是 appendonly.aof 文件：

# 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种方式在许多应用中已经足够用了
appendonly no 
# appendfilename AOF 文件名称
appendfilename "appendonly.aof" 
# appendfsync aof持久化策略的配置：
#     no：不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#     always：每次写入都执行fsync，以保证数据同步到磁盘。
#     everysec：每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec 
# 重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性
No-appendfsync-on-rewrite 
# 设置重写的基准值
Auto-aof-rewrite-min-size 
# 设置重写的基准值
Auto-aof-rewrite-percentage

恢复

正常恢复

启动：修改配置。修改默认的 appendonly no，改为 yes。
复制：将有数据的 aof 文件复制一份保存到对应目录（config get dir）。
恢复：重启 redis 然后重新加载。

异常恢复

启动：修改配置。修改默认的 appendonly no，改为 yes。
破坏：故意破坏 appendonly.aof 文件（写一些非 Redis 命令）。
修复：redis-check-aof --fix appendonly.aof 进行修复。
恢复：重启 redis 然后重新加载。

重写

AOF 采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制。

当AOF文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩。

只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof。

重写原理

AOF 文件持续增长而过大时，会 Fork 出一条新进程来将文件重写（也是先写临时文件最后再 rename）。

遍历新进程的内存中数据，每条记录有一条的 set 语句。

重写 aof 文件的操作，并没有读取旧的 aof 文件，这点和快照有点类似。

触发机制

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

优缺点

优点

appendfsync always：每次修改同步。同步持久化，每次发生数据变更会被立即记录到磁盘。性能较差，但数据完整性比较好。
appendfsync everysec：每秒同步。异步操作，每秒记录，如果一秒内宕机，有数据丢失。
appendfsync no：不同步。从不同步。

缺点

相同数据集的数据而言，AOF 文件要远大于 RDB 文件，恢复速度慢于 RDB。
AOF 运行效率要慢于 RDB，每秒同步策略效率较好，不同步效率和 RDB 相同。

小结

总结

RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储。
AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AO F命令以 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% 大小重写可以改到适当的数值。
- 如果不开启 AOF ，仅靠 Master-Slave Repllcation（主从复制）实现高可用性也可以，能省掉一大笔IO，也减少了 rewrite 时带来的系统波动。代价是如果 Master/Slave 同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB 文件，载入较新的那个（微博就是这种架构）。

Redis的发布和订阅

Redis 发布订阅（pub / sub）是一种消息通信模式

发送者（pub）发送消息，订阅者（sub）接收消息。

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

订阅/发布消息图：

频道和订阅频道的客户端之间的关系：

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

命令

这些命令被广泛用于构建即时通信应用，比如网络聊天室（chat room）和实时广播、实时提醒等。

发布订阅命令行实现

窗口 1，订阅频道：

127.0.0.1:6379> subscribe redisChat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1
#等待读取推送信息

窗口 2，发送端频道发布消息：

127.0.0.1:6379> publish redisChat "Hello,Redis" #发布消息
(integer) 2
127.0.0.1:6379> publish redisChat "Hello,World"
(integer) 2

窗口 1 会收到发布的消息：

1) "message" #消息
2) "redisChat" #频道
3) "Hello,Redis" #消息具体内容
1) "message"
2) "redisChat"
3) "Hello,World"

原理

Redis 是使用 C 实现的，通过分析 Redis 源码里的 pubsub.c 文件，可以了解发布和订阅机制的底层实现。
Redis 通过 publish 、subscribe 和 psubscribe 等命令实现发布和订阅功能。
通过 subscribe 命令订阅某频道后，redis-server 里维护了一个字典，字典的键就是一个个 channel。
而字典的值则是一个链表，链表中保存了所有订阅这个 channel 的客户端。
subscribe 命令的关键，就是将客户端添加到给定 channel 的订阅链表中。
通过 publish 命令向订阅者发送消息，redis-server 会使用给定的频道作为键，在它所维护的 channel 字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。
pub / sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在 Redis 中，你可以设定对某一个 key 值进行消息发布及消息订阅，当一个 key 值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。
这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

主从复制

概述

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器

前者称为主节点（master / leader），后者称为从节点（slave / follower）。

数据的复制是单向的，只能由主节点到从节点。

Master 以写为主，Slave 以读为主。

一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

默认情况下，每台 Redis 服务器都是主节点。

作用

数据冗余

主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

故障恢复

当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。这也是一种服务的冗余。

负载均衡

在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载。

尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。

高可用

主从复制是哨兵和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础。

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

结构上：单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。
容量上：单个 Redis 服务器内存容量有限，一般来说，单台 Redis 最大使用内存不应该超过 20G。

应用

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是多读少写。

对于这种场景，我们可以使用如下这种架构：

环境配置

命令方式

指定主库（配从库不配主库）

slaveof 主库IP 主库端口

这种方式每次与主库断开后，都需要重新连接，非常不方便，不推荐。

配置文件方式

拷贝多个 redis.conf 文件

标准的配置是一主三从，受限于内存大小，这里演示一主二从，所以拷贝 3 份配置文件演示。

[root@sail redis]# cp redis.conf redis6379.conf
[root@sail redis]# cp redis.conf redis6380.conf
[root@sail redis]# cp redis.conf redis6381.conf

修改配置文件

修改 redis6379.conf

daemonize yespidfile /var/run/redisdaemonize yes
pidfile /var/run/redis_6379.pid
logfile "6379.log"
dbfilename dump6379.rdb_6379.pidlogfile "6379.log"dbfilename dump6379.rdb

修改 redis6380.conf

daemonize yes
pidfile /var/run/redis_6380.pid
logfile "6380.log"
dbfilename dump6380.rdb

修改 redis6381.conf

daemonize yes
pidfile /var/run/redis_6381.pid
logfile "6381.log"
dbfilename dump6381.rdb

一主二从

启动服务

[root@sail redis]# redis-server redis6379.conf
[root@sail redis]# redis-server redis6380.conf
[root@sail redis]# redis-server redis6381.conf

查看启动的服务

[root@sail redis]# ps -ef|grep redis
root      8066  6267  0 21:40 pts/3    00:00:00 redis-cli -p 6380
root      8388     1  0 21:46 ?        00:00:00 redis-server 127.0.0.1:6380
root      8397     1  0 21:46 ?        00:00:00 redis-server 127.0.0.1:6381
root      8417  6213  0 21:47 pts/0    00:00:00 grep --color=auto redis
root     11953     1  0 Mar15 ?        02:02:44 ./bin/redis-server *:6379

查看主从复制信息

info replication

默认三个都是 master，都是主机。

配置为一个 master 两个 slave

slaveof 地址端口号

slaveof 192.168.80.129 6379

也可以通过配置文件直接指定主机，这样比较方便，也便于维护。

主机赋值，从机取值

从机只能读不能写，这样就实现了读写分离。

主机断开

主机断开以后从机依然是从机，且正常工作。

主机恢复

主机恢复以后赋的值从机依然能够读取到，这样可以保证高可用。

从机断开

从机断开后，主机赋了新值，从机启动后无法获取到新值，原因是从机启动后又默认为主机了。

如果想启动即为从机，可以按照前面说的配置 replicaof 进行设置。

层层链路

从机也可以被其他从机当作主机，可以有效减轻主机的写压力。

6381 指定 6380 作为主机，6380 依然是从机，只是有了从机节点。

这样 6379 赋的值只需要复制到 6380，6380 再复制到 6381，这样就有效的减轻主机的写压力。

谋朝篡位

slaveof no one

主机断开后，从机如果想要当主机，可以使用 slaveof no one 进行“谋朝篡位”，从而变成主机。

但此时其他节点还是很“忠心”，依然认定之前的主机为主机，这样变成的主机是没有从机的，是个“孤家寡人”。

主机如果恢复，可以“平息叛乱”，之前的从机依旧认定它为主机。

改朝换代

前面的操作在实际场景中并不适用，因为我们希望的是主机断开后有从机作为主机，依旧实现主从复制。

所以在从机“谋朝篡位”后，还需要让剩余的从机“认主”，让他们都“归顺”于新的主机。

这样原来的主机恢复后就变成了“孤家寡人”。

以上的配置十分繁琐，任何一个环节出错都可能导致失败。

哨兵模式

概述

主从切换技术的操作是：当主机宕机后，需要手动把一台从机切换为主机。

这就需要人工干预，费事费力，还会造成一段时间内服务不可用。

这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

Redis 从 2.8 开始正式提供了 Sentinel（哨兵） 架构来解决这个问题。

它是“谋朝篡位”的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从机转换为主机。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行。

其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

这里的哨兵有两个作用：

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

然而一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。

各个哨兵之间还会进行监控，这样就形成了多哨兵模式：

假设主机宕机，哨兵 1 先检测到这个结果，系统并不会马上进行 failover（故障转移）过程，仅仅是哨兵 1 主观的认为主机不可用，这个现象称为主观下线。

当后面的哨兵也检测到主机不可用，并且数量达到一定值时，哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。

切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从机实现切换主机，这个过程称为客观下线。

使用

配置

受限于内存大小，这里只演示一个哨兵进程监测一个主机的情况。

在 redis 目录下新建 myconfig 目录，并创建文件 sentinel.conf

文件名必须为 sentinel.conf

[root@sail redis]# mkdir myconfig
[root@sail redis]# cd myconfig/
[root@sail myconfig]# vim sentinel.conf

编写配置

sentinel monitor myredis 127.0.0.1                                     6379 1

末尾的 1 代表选票达到多少时选举成功。

启动

redis-sentinel myconfig/sentinel.conf

[root@sail redis]# redis-sentinel myconfig/sentinel.conf 
16728:X 08 Jun 2022 22:23:38.464 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
16728:X 08 Jun 2022 22:23:38.464 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=16728, just started
16728:X 08 Jun 2022 22:23:38.464 # Configuration loaded
16728:X 08 Jun 2022 22:23:38.465 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.6 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 16728
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               
16728:X 08 Jun 2022 22:23:38.466 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
16728:X 08 Jun 2022 22:23:38.469 # Sentinel ID is a7ebdd5f7260485b8f6108169d96910b747e3c8f
16728:X 08 Jun 2022 22:23:38.469 # +monitor master myredis 127.0.0.1 6379 quorum 1
16728:X 08 Jun 2022 22:23:38.469 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379

主机断开

主机断开后，哨兵进程会监测到，然后发起选举，调用选举算法，最后选举 6380 为新的主机，6381 也认定其为主机。

主机恢复

之前断开的主机恢复后，哨兵进程也会检测到，但此时并不会将其再设为主机，而是设为新的主机的从机。

优缺点

优点

哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。

主从可以切换，故障可以转移，系统可用性更好。

哨兵模式是主从模式的升级，系统更健壮，可用性更高。

缺点

Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

实现哨兵模式的配置也不简单，甚至可以说有些繁琐。

完整配置

前面自定义的 sentinel.conf 只配置了一项，再来看下完整的配置内容：

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

LUA脚本

Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。
这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。
https://www.w3cschool.cn/lua/

LUA脚本在Redis中的优势

将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作。
但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。
利用lua脚本淘汰用户，解决超卖问题。
redis 2.6版本以后，通过lua脚本解决争抢问题，实际上是redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。

缓存穿透缓存击穿缓存雪崩

使用缓存的问题

Redis 缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。

但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。

如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。

缓存穿透（查不到）

概念

这里先介绍下日常使用缓存的逻辑：

查询一个数据，先到缓存中查询。

如果缓存中存在，则返回。

如果缓存中不存在，则到数据库查询。

如果数据库中存在，则返回数据，且存到缓存。

如果数据库中不存在，则返回空值。

缓存穿透

缓存穿透出现的情况就是数据库和缓存中都没有。

这样缓存就不能拦截，数据库中查不到值也就不能存到缓存。

这样每次这样查询都会到数据库，相当于直达了，即穿透。

这样会给数据库造成很大的压力。

解决方案

布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以 hash 形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

但是这种方法会存在两个问题：

如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键。
即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（量太大了，缓存过期0）

概念

缓存击穿，是指一个 key 非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问。

当这个 key 在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

当某个 key 在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据。

由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。

加互斥锁

分布式锁：使用分布式锁，保证对于每个 key 同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只能等待。

这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

概念

缓存雪崩，是指在某一个时间段，缓存集中过期失效。

产生雪崩的原因之一，比如马上就要到双十一零点，很快就会迎来一波抢购。

这波商品时间比较集中的放入了缓存，假设缓存一个小时。

那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。

而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实集中过期，倒不是非常致命。

比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。

因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存。

这个时候，数据库也是可以顶住压力的，无非就是对数据库产生周期性的压力而已。

而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

解决方案

搭建集群

实现 Redis 的高可用，既然一台服务有可能挂掉，那就多增设几台服务。

这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

限流降级

在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。

比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待。

数据预热

数据加热的含义就是在正式部署之前，先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。

from-ip>

目前总是 “failover”，是 “leader” 或者 “observer” 中的一个。

参数 from-ip，from-port，to-ip，to-port是用来和旧的 master 和新的 master (即旧的 slave)通信的

这个脚本应该是通用的，能被多次调用，不是针对性的。

sentinel client-reconfig-script

sentinel client-reconfig-script mymaster /var/redis/reconfig.sh


#  LUA脚本

[外链图片转存中...(img-bWoD7vj6-1739544030776)]
Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。
这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。
https://www.w3cschool.cn/lua/

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

将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
**LUA脚本是类似redis事务**，有一定的原子性，**不会被其他命令插队**，**可以完成一些redis事务性的操作**。
**但是注意redis的lua脚本功能**，**只有在Redis 2.6以上的版本才可以使用**。
**利用lua脚本淘汰用户，解决超卖问题**。
redis 2.6版本以后，通过lua脚本解决**争抢问题**，实际上是**redis 利用其单线程的特性**，**用任务队列的方式解决多任务并发问题**。
[外链图片转存中...(img-78wpUmnz-1739544030776)]





# 缓存穿透 缓存击穿 缓存雪崩

## 使用缓存的问题

Redis 缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。

但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。

如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些典型问题就是，**缓存穿透**、**缓存雪崩**和**缓存击穿**。目前，业界也都有比较流行的解决方案。

## 缓存穿透（查不到）

### 概念

这里先介绍下日常使用缓存的逻辑：

查询一个数据，先到缓存中查询。

如果缓存中存在，则返回。

如果缓存中不存在，则到数据库查询。

如果数据库中存在，则返回数据，且存到缓存。

如果数据库中不存在，则返回空值。

> 缓存穿透

**缓存穿透**出现的情况就是数据库和缓存中都没有。

这样缓存就不能拦截，数据库中查不到值也就不能存到缓存。

这样每次这样查询都会到数据库，相当于直达了，即**穿透**。

这样会给数据库造成很大的压力。

### 解决方案

#### 布隆过滤器

**布隆过滤器**是一种数据结构，对所有可能查询的参数以 hash 形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

[外链图片转存中...(img-ujbYYtxD-1739544030776)]

#### 缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

[外链图片转存中...(img-IAncvCG5-1739544030776)]

但是这种方法会存在两个问题：

- 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键。
- 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

## 缓存击穿（量太大了， 缓存过期0）

### 概念

**缓存击穿**，是指一个 key 非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问。

当这个 key 在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

当某个 key 在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据。

由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。

### 解决方案

#### 设置热点数据永不过期

从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。

#### 加互斥锁

分布式锁：使用分布式锁，保证对于每个 key 同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只能等待。

这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

## 缓存雪崩

### 概念

**缓存雪崩**，是指在某一个时间段，缓存集中过期失效。

产生雪崩的原因之一，比如马上就要到双十一零点，很快就会迎来一波抢购。

这波商品时间比较集中的放入了缓存，假设缓存一个小时。

那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。

而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

[外链图片转存中...(img-tAx6lX6l-1739544030776)]

其实集中过期，倒不是非常致命。

比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。

因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存。

这个时候，数据库也是可以顶住压力的，无非就是对数据库产生周期性的压力而已。

而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

### 解决方案

#### 搭建集群

实现 Redis 的高可用，既然一台服务有可能挂掉，那就多增设几台服务。

这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

#### 限流降级

在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。

比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待。

#### 数据预热

数据加热的含义就是在正式部署之前，先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。

在即将发生大并发访问前手动触发加载缓存不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀。