狂神Redis笔记
Redis笔记
一、Nosql概述
1、为什么使用Nosql
-
单机Mysql时代
90年代,一个网站的访问量一般不会太大，单个数据库完全够用。随着用户增多，网站出现以下问题
- 数据量增加到一定程度，单机数据库就放不下了
- 数据的索引（B+ Tree）,一个机器内存也存放不下
- 访问量变大后（读写混合），一台服务器承受不住。
-
Memcached(缓存) + Mysql + 垂直拆分（读写分离）
网站80%的情况都是在读，每次都要去查询数据库的话就十分的麻烦！所以说我们希望减轻数据库的压力，我们可以使用缓存来保证效率！
优化过程经历了以下几个过程：
-
优化数据库的数据结构和索引(难度大)
-
文件缓存，通过IO流获取比每次都访问数据库效率略高，但是流量爆炸式增长时候，IO流也承受不了
-
MemCache,当时最热门的技术，通过在数据库和数据库访问层之间加上一层缓存，第一次访问时查询数据库，将结果保存到缓存，后续的查询先检查缓存，若有直接拿去使用，效率显著提升。
-
-
分库分表 + 水平拆分 + Mysql集群
-
如今最近的年代
如今信息量井喷式增长，各种各样的数据出现（用户定位数据，图片数据等），大数据的背景下关系型数据库（RDBMS）无法满足大量数据要求。Nosql数据库就能轻松解决这些问题。
目前一个基本的互联网项目
为什么要用NoSQL ？
用户的个人信息，社交网络，地理位置。用户自己产生的数据，用户日志等等爆发式增长！
这时候我们就需要使用NoSQL数据库的，Nosql可以很好的处理以上的情况！
2、什么是Nosql
NoSQL = Not Only SQL（不仅仅是SQL)
Not Only Structured Query Language
关系型数据库：列+行，同一个表下数据的结构是一样的。
非关系型数据库：数据存储没有固定的格式，并且可以进行横向扩展。
NoSQL泛指非关系型数据库，随着web2.0互联网的诞生，传统的关系型数据库很难对付web2.0时代！尤其是超大规模的高并发的社区，暴露出来很多难以克服的问题，NoSQL在当今大数据环境下发展的十分迅速，Redis是发展最快的。
3、Nosql介绍
Not Only Structured Query Language
关系型数据库：列+行，同一个表下数据的结构是一样的。
非关系型数据库：数据存储没有固定的格式，并且可以进行横向扩展。
NoSQL泛指非关系型数据库，随着web2.0互联网的诞生，传统的关系型数据库很难对付web2.0时代！尤其是超大规模的高并发的社区，暴露出来很多难以克服的问题，NoSQL在当今大数据环境下发展的十分迅速，Redis是发展最快的。
4、Nosql特点
-
方便扩展（数据之间没有关系，很好扩展！）
-
大数据量高性能（Redis一秒可以写8万次，读11万次，NoSQL的缓存记录级，是一种细粒度的缓存，性能会比较高！）
-
数据类型是多样型的！（不需要事先设计数据库，随取随用）
-
传统的 RDBMS 和 NoSQ
传统的 RDBMS(关系型数据库) - 结构化组织 - SQL - 数据和关系都存在单独的表中 row col - 操作，数据定义语言 - 严格的一致性 - 基础的事务 - ...Nosql - 不仅仅是数据 - 没有固定的查询语言 - 键值对存储，列存储，文档存储，图形数据库（社交关系） - 最终一致性 - CAP定理和BASE - 高性能，高可用，高扩展 - ...了解：3V + 3高
大数据时代的3V ：主要是描述问题的
- 海量Velume
- 多样Variety
- 实时Velocity
大数据时代的3高 ： 主要是对程序的要求
- 高并发
- 高可扩
- 高性能
真正在公司中的实践：NoSQL + RDBMS 一起使用才是最强的。
5、阿里巴巴演进分析
推荐阅读：阿里云的这群疯子https://yq.aliyun.com/articles/653511
# 商品信息
- 一般存放在关系型数据库：Mysql,阿里巴巴使用的Mysql都是经过内部改动的。
# 商品描述、评论(文字居多)
- 文档型数据库：MongoDB
# 图片
- 分布式文件系统 FastDFS
- 淘宝：TFS
- Google: GFS
- Hadoop: HDFS
- 阿里云: oss
# 商品关键字 用于搜索
- 搜索引擎：solr,elasticsearch
- 阿里：Isearch 多隆
# 商品热门的波段信息
- 内存数据库：Redis，Memcache
# 商品交易，外部支付接口
- 第三方应用
6、Nosql的四大分类
KV键值对
- 新浪：Redis
- 美团：Redis + Tair
- 阿里、百度：Redis + Memcache
文档型数据库（bson数据格式）：
- MongoDB(掌握)
- 基于分布式文件存储的数据库。C++编写，用于处理大量文档。
- MongoDB是RDBMS和NoSQL的中间产品。MongoDB是非关系型数据库中功能最丰富的，NoSQL中最像关系型数据库的数据库。
- ConthDB
列存储数据库
- HBase(大数据必学)
- 分布式文件系统
图关系数据库
用于广告推荐，社交网络
- Neo4j、InfoGrid
| 分类 | Examples举例 | 典型应用场景 | 数据模型 | 优点 | 缺点 |
|---|---|---|---|---|---|
| 键值对（key-value） | Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB | 内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。 | Key 指向 Value 的键值对，通常用hash table来实现 | 查找速度快 | 数据无结构化，通常只被当作字符串或者二进制数据 |
| 列存储数据库 | Cassandra, HBase, Riak | 分布式的文件系统 | 以列簇式存储，将同一列数据存在一起 | 查找速度快，可扩展性强，更容易进行分布式扩展 | 功能相对局限 |
| 文档型数据库 | CouchDB, MongoDb | Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容） | Key-Value对应的键值对，Value为结构化数据 | 数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构 | 查询性能不高，而且缺乏统一的查询语法。 |
| 图形(Graph)数据库 | Neo4J, InfoGrid, Infinite Graph | 社交网络，推荐系统等。专注于构建关系图谱 | 图结构 | 利用图结构相关算法。比如最短路径寻址，N度关系查找等 | 很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群 |
二、Redis入门
1、概述
Redis是什么？
Redis（Remote Dictionary Server )，即远程字典服务。
是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis能该干什么？
- 内存存储、持久化，内存是断电即失的，所以需要持久化（RDB、AOF）
- 高效率、用于高速缓冲
- 发布订阅系统
- 地图信息分析
- 计时器、计数器(eg：浏览量)
- 。。。
特性
-
多样的数据类型
-
持久化
-
集群
-
事务
…
2、环境搭建
官网：https://redis.io/
推荐使用Linux服务器学习。
windows版本的Redis已经停更很久了…
3、Windows安装
https://github.com/dmajkic/redis
-
解压安装包
-
开启redis-server.exe
-
启动redis-cli.exe测试
4、Linux安装
-
下载安装包！
redis-5.0.8.tar.gz -
解压Redis的安装包！程序一般放在
/opt目录下
-
基本环境安装
yum install gcc-c++ # 然后进入redis目录下执行 make # 然后执行 make install
-
redis默认安装路径
/usr/local/bin
-
将redis的配置文件复制到 程序安装目录
/usr/local/bin/kconfig下![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hxvGQ47d-1597890996509)(狂神说 Redis.assets/image-20200813114000868.png)]](http://img.e-com-net.com/image/info8/47945f78ac5548dab5522c2bdf1bbb42.jpg)
-
redis默认不是后台启动的，需要修改配置文件！
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dDdKTUgd-1597890996510)(狂神说 Redis.assets/image-20200813114019063.png)]](http://img.e-com-net.com/image/info8/29471ea45c4a4c8fb74a1bc7e8e759ec.jpg)
-
通过制定的配置文件启动redis服务
-
redis-server hconfig/redis.conf
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jOypL57Z-1597890996511)(狂神说 Redis.assets/image-20200813114030597.png)]](http://img.e-com-net.com/image/info8/70e7fe206afc43b3a77939c999225508.jpg)
-
使用redis-cli连接指定的端口号测试，Redis的默认端口6379
redis-cli -p 6379
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LnDaISQ4-1597890996512)(狂神说 Redis.assets/image-20200813114045299.png)]](http://img.e-com-net.com/image/info8/920a4182cc8a4d3b881b044f3e8016f4.jpg)
-
查看redis进程是否开启
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9PhN1jC1-1597890996513)(狂神说 Redis.assets/image-20200813114103769.png)]](http://img.e-com-net.com/image/info8/a7c98c3c2a1345eba60d41da6407d58e.jpg)
-
关闭Redis服务
shutdown![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Y54EuOYm-1597890996514)(狂神说 Redis.assets/image-20200813114116691.png)]](http://img.e-com-net.com/image/info8/2444c19e78e94d8eab6feee17bd3e5b1.jpg)
-
再次查看进程是否存在
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-llJ5xtg3-1630594638906)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210719151803884.png)]
-
后面我们会使用单机多Redis启动集群测试
5、测试性能
**redis-benchmark：**Redis官方提供的性能测试工具，参数选项如下：
简单测试：
# 测试：100个并发连接 100000请求
redis-benchmark -h localhost -p 6379 -c 100 -n 100000
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-plMshjFg-1597890996515)(狂神说 Redis.assets/image-20200813114143365.png)]](http://img.e-com-net.com/image/info8/58ac453d7aa44393ade33cdec4a10fd4.jpg)
6、基础知识
redis默认有16个数据库
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v2S3n3Si-1597890996516)(狂神说 Redis.assets/image-20200813114158322.png)]](http://img.e-com-net.com/image/info8/a484ad84651641d2aa5fcda1a5036f6d.jpg)
默认使用的第0个;
16个数据库为：DB 0~DB 15
默认使用DB 0 ，可以使用select n切换到DB n，dbsize可以查看当前数据库的大小，与key数量相关。
127.0.0.1:6379> config get databases # 命令行查看数据库数量databases
1) "databases"
2) "16"
127.0.0.1:6379> select 8 # 切换数据库 DB 8
OK
127.0.0.1:6379[8]> dbsize # 查看数据库大小
(integer) 0
# 不同数据库之间 数据是不能互通的，并且dbsize 是根据库中key的个数。
127.0.0.1:6379> set name sakura
OK
127.0.0.1:6379> SELECT 8
OK
127.0.0.1:6379[8]> get name # db8中并不能获取db0中的键值对。
(nil)
127.0.0.1:6379[8]> DBSIZE
(integer) 0
127.0.0.1:6379[8]> SELECT 0
OK
127.0.0.1:6379> keys *
1) "counter:__rand_int__"
2) "mylist"
3) "name"
4) "key:__rand_int__"
5) "myset:__rand_int__"
127.0.0.1:6379> DBSIZE # size和key个数相关
(integer) 5
keys * ：查看当前数据库中所有的key。
flushdb：清空当前数据库中的键值对。
flushall：清空所有数据库的键值对。
Redis是单线程的，Redis是基于内存操作的。
所以Redis的性能瓶颈不是CPU,而是机器内存和网络带宽。
那么为什么Redis的速度如此快呢，性能这么高呢？
- redis是C语言写的，QPS达到10W+，完全不比同样使用key-value的Mencache差！
Redis为什么单线程还这么快？
- 误区1：高性能的服务器一定是多线程的？
- 误区2：多线程（CPU上下文会切换！）一定比单线程效率高！
核心：Redis是将所有的数据放在内存中的，所以说使用单线程去操作效率就是最高的，多线程（CPU上下文会切换：耗时的操作！），对于内存系统来说，如果没有上下文切换效率就是最高的，多次读写都是在一个CPU上的，在内存存储数据情况下，单线程就是最佳的方案。
三、五大数据类型
官方文档
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sa02ob5D-1630594638909)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210719154655565.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-34qxQrsN-1630594638911)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210719154538861.png)]
redis-key
在redis中无论什么数据类型，在数据库中都是以key-value形式保存，通过进行对Redis-key的操作，来完成对数据库中数据的操作。
下面学习的命令：
exists key：判断键是否存在del key：删除键值对move key db：将键值对移动到指定数据库expire key second：设置键值对的过期时间type key：查看value的数据类型
127.0.0.1:6379> keys * # 查看当前数据库所有key
(empty list or set)
127.0.0.1:6379> set name qinjiang # set key
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> keys *
1) "age"
2) "name"
127.0.0.1:6379> move age 1 # 将键值对移动到指定数据库
(integer) 1
127.0.0.1:6379> EXISTS age # 判断键是否存在
(integer) 0 # 不存在
127.0.0.1:6379> EXISTS name
(integer) 1 # 存在
127.0.0.1:6379> SELECT 1
OK
127.0.0.1:6379[1]> keys *
1) "age"
127.0.0.1:6379[1]> del age # 删除键值对
(integer) 1 # 删除个数
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> EXPIRE age 15 # 设置键值对的过期时间
(integer) 1 # 设置成功 开始计数
127.0.0.1:6379> ttl age # 查看key的过期剩余时间
(integer) 13
127.0.0.1:6379> ttl age
(integer) 11
127.0.0.1:6379> ttl age
(integer) 9
127.0.0.1:6379> ttl age
(integer) -2 # -2 表示key过期，-1表示key未设置过期时间
127.0.0.1:6379> get age # 过期的key 会被自动delete
(nil)
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> type name # 查看value的数据类型
string
关于TTL命令
Redis的key，通过TTL命令返回key的过期时间，一般来说有3种：
- 当前key没有设置过期时间，所以会返回-1.
- 当前key有设置过期时间，而且key已经过期，所以会返回-2.
- 当前key有设置过期时间，且key还没有过期，故会返回key的正常剩余时间.
关于重命名RENAME和RENAMENX
- RENAME key newkey修改 key 的名称
- RENAMENX key newkey仅当 newkey 不存在时，将 key 改名为 newkey 。
更多命令学习：https://www.redis.net.cn/order/
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-65EVTJjm-1630594638913)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210719155601764.png)]
1、String(字符串)
90%的java程序员使用Redis只会使用一个String类型！！！
| 命令 | 描述 |
|---|---|
| Redis Setnx 命令 | 只有在 key 不存在时设置 key 的值。 |
| Redis Getrange 命令 | 返回 key 中字符串值的子字符 |
| Redis Mset 命令 | 同时设置一个或多个 key-value 对。 |
| Redis Setex 命令 | 将值 value 关联到 key ，并将 key 的过期时间设为 seconds (以秒为单位)。 |
| Redis SET 命令 | 设置指定 key 的值 |
| Redis Get 命令 | 获取指定 key 的值。 |
| Redis Getbit 命令 | 对 key 所储存的字符串值，获取指定偏移量上的位(bit)。 |
| Redis Setbit 命令 | 对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。 |
| Redis Decr 命令 | 将 key 中储存的数字值减一。 |
| Redis Decrby 命令 | key 所储存的值减去给定的减量值（decrement） 。 |
| Redis Strlen 命令 | 返回 key 所储存的字符串值的长度。 |
| Redis Msetnx 命令 | 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。 |
| Redis Incrby 命令 | 将 key 所储存的值加上给定的增量值（increment） 。 |
| Redis Incrbyfloat 命令 | 将 key 所储存的值加上给定的浮点增量值（increment） 。 |
| Redis Setrange 命令 | 用 value 参数覆写给定 key 所储存的字符串值，从偏移量 offset 开始。 |
| Redis Psetex 命令 | 这个命令和 SETEX 命令相似，但它以毫秒为单位设置 key 的生存时间，而不是像 SETEX 命令那样，以秒为单位。 |
| Redis Append 命令 | 如果 key 已经存在并且是一个字符串， APPEND 命令将 value 追加到 key 原来的值的末尾。 |
| Redis Getset 命令 | 将给定 key 的值设为 value ，并返回 key 的旧值(old value)。 |
| Redis Mget 命令 | 获取所有(一个或多个)给定 key 的值。 |
| Redis Incr 命令 | 将 key 中储存的数字值增一。 |
##################################################
127.0.0.1:6379> set key1 v1 #设置值
OK
127.0.0.1:6379> set key2 v2
OK
127.0.0.1:6379> keys * #获得所有的key
1) "key2"
2) "key1"
3) "key"
4) "age"
127.0.0.1:6379> get key1 #获得值
"v1"
127.0.0.1:6379> append key1 "hello" #追加字符串，如果当前key不存在，就相当于set key
(integer) 7
127.0.0.1:6379> get key1
"v1hello"
127.0.0.1:6379> STRLEN key1 #获取字符串长度
(integer) 7
127.0.0.1:6379> APPEND key1 ",hcd"
(integer) 11
127.0.0.1:6379> STRLEN key1
(integer) 11
127.0.0.1:6379> get key1
"v1hello,hcd"
127.0.0.1:6379>
###################################################
# i++
# 步长 i+=
127.0.0.1:6379> set view 0 #初始浏览量为0
OK
127.0.0.1:6379> get view
"0"
127.0.0.1:6379> incr view #自增一，浏览量加一
(integer) 1
127.0.0.1:6379> incr view
(integer) 2
127.0.0.1:6379> get view
"2"
127.0.0.1:6379> decr view #自减一，浏览量减一
(integer) 1
127.0.0.1:6379> decr view
(integer) 0
127.0.0.1:6379> decr view
(integer) -1
127.0.0.1:6379> INCRBY view 10 #可设置步长，指定增量
(integer) 9
127.0.0.1:6379> INCRBY view 10
(integer) 19
127.0.0.1:6379> DECRBY view 10
(integer) 9
###################################################
# 字符串范围 range
127.0.0.1:6379> set key1 "hello,hcd"
OK
127.0.0.1:6379> get key1
"hello,hcd"
127.0.0.1:6379> GETRANGE key1 0 3 # 截取字符串[0,3]
"hell"
127.0.0.1:6379> GETRANGE key1 0 -1 #获取全部字符串，和 get key一样
"hello,hcd"
#替换
"hello,hcd"
127.0.0.1:6379> set key2 abcdefg
OK
127.0.0.1:6379> get key2
"abcdefg"
127.0.0.1:6379> SETRANGE key2 1 xx #替换指定位置的字符串
(integer) 7
127.0.0.1:6379> get key2
"axxdefg"
127.0.0.1:6379>
###################################################
# setex(set with expire) #设置过期时间
# setnx(set if not exist) #不存在设置（在分布式锁中会常常使用）
127.0.0.1:6379> setex key3 30 "hello" #设置key3的值，30秒后过期
OK
127.0.0.1:6379> ttl key3
(integer) 26
127.0.0.1:6379> get key3
"hello"
127.0.0.1:6379> setnx mykey "redis" #如果mykey 不存在，创建mykey
(integer) 1
127.0.0.1:6379> keys *
1) "mykey"
2) "key2"
3) "key1"
127.0.0.1:6379> ttl key3
(integer) -2
127.0.0.1:6379> setnx mykey "MongoDB" #如果mykey 存在，创建失败
(integer) 0
127.0.0.1:6379> get mykey
"redis"
###################################################
# mset
# mget
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> mset k1 v1 k2 v2 k3 v3 # 同时设置多个值
OK
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> mget k1 k2 k3 #同时获取多个值
1) "v1"
2) "v2"
3) "v3"
127.0.0.1:6379> msetnx k1 v1 k4 v4 #是一个原子性操作，要么一起成功，要么一起失败
(integer) 0
127.0.0.1:6379> keys *
1) "k3"
2) "k2"
3) "k1"
# 对象
set user:1{name:zs,age:3} #设置user：1 对象 值为json字符来保存一个对象！
# 这里的key是一个巧妙地设计：user:{id}:{filed},如此设计在redis中是完全ok的！
127.0.0.1:6379> mset user:1:name zs user:1:age 2
OK
127.0.0.1:6379> keys *
1) "user:1:name"
2) "user:1:age"
3) "k2"
4) "k3"
5) "k1"
127.0.0.1:6379> mget user:1:name user:1:age
1) "zs"
2) "2"
###################################################
# getset # 先get后set
127.0.0.1:6379> getset db redis # 如果不存在值，则返回nil
(nil)
127.0.0.1:6379> get db
"redis"
127.0.0.1:6379> getset db mongodb # 如果存在值，获取原来的值，并设置新的值
"redis"
127.0.0.1:6379> get db
"mongodb"
127.0.0.1:6379>
数据结构是相同的！
String类似的使用场景：value除了是字符串还可以是数字。用途举例：
- 计数器（incrby)
- 统计多单位的数量：uid:123666：follow 0
- 粉丝数
- 对象存储缓存
2、List(列表)
Redis列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
一个列表最多可以包含 232 - 1 个元素 (4294967295, 每个列表超过40亿个元素)。
首先我们列表，可以经过规则定义将其变为队列、栈、双端队列等
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VPvbIltc-1597890996518)(狂神说 Redis.assets/image-20200813114255459.png)]](http://img.e-com-net.com/image/info8/b4fd7c65b4ca4821a54d7298f7b24d54.jpg)
| 命令 | 描述 |
|---|---|
| Redis Lindex 命令 | 通过索引获取列表中的元素 |
| Redis Rpush 命令 | 在列表中添加一个或多个值 |
| Redis Lrange 命令 | 获取列表指定范围内的元素 |
| Redis Rpoplpush 命令 | 移除列表的最后一个元素，并将该元素添加到另一个列表并返回 |
| Redis Blpop 命令 | 移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。 |
| Redis Brpop 命令 | 移出并获取列表的最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。 |
| Redis Brpoplpush 命令 | 从列表中弹出一个值，将弹出的元素插入到另外一个列表中并返回它； 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。 |
| Redis Lrem 命令 | 移除列表元素 |
| Redis Llen 命令 | 获取列表长度 |
| Redis Ltrim 命令 | 对一个列表进行修剪(trim)，就是说，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除。 |
| Redis Lpop 命令 | 移出并获取列表的第一个元素 |
| Redis Lpushx 命令 | 将一个或多个值插入到已存在的列表头部 |
| Redis Linsert 命令 | 在列表的元素前或者后插入元素 |
| Redis Rpop 命令 | 移除并获取列表最后一个元素 |
| Redis Lset 命令 | 通过索引设置列表元素的值 |
| Redis Lpush 命令 | 将一个或多个值插入到列表头部 |
| Redis Rpushx 命令 | 为已存在的列表添加值 |
正如图Redis中List是可以进行双端操作的，所以命令也就分为了LXXX和RLLL两类，有时候L也表示List例如LLEN
| 命令 | 描述 |
|---|---|
LPUSH/RPUSH key value1[value2..] |
从左边/右边向列表中PUSH值(一个或者多个)。 |
LRANGE key start end |
获取list 起止元素==（索引从左往右 递增）== |
LPUSHX/RPUSHX key value |
向已存在的列名中push值（一个或者多个） |
LINSERT key BEFORE|AFTER pivot value |
在指定列表元素的前/后 插入value |
LLEN key |
查看列表长度 |
LINDEX key index |
通过索引获取列表元素 |
LSET key index value |
通过索引为元素设值 |
LPOP/RPOP key |
从最左边/最右边移除值 并返回 |
RPOPLPUSH source destination |
将列表的尾部(右)最后一个值弹出，并返回，然后加到另一个列表的头部 |
LTRIM key start end |
通过下标截取指定范围内的列表 |
LREM key count value |
List中是允许value重复的 count > 0：从头部开始搜索 然后删除指定的value 至多删除count个 count < 0：从尾部开始搜索… count = 0：删除列表中所有的指定value。 |
BLPOP/BRPOP key1[key2] timout |
移出并获取列表的第一个/最后一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。 |
BRPOPLPUSH source destination timeout |
和RPOPLPUSH功能相同，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。 |
#########################################################
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> LPUSH list one #将一个值或者多个值，插入到列表头部（左）
(integer) 1
127.0.0.1:6379> LPUSH list two
(integer) 2
127.0.0.1:6379> LPUSH list three
(integer) 3
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
127.0.0.1:6379> LRANGE list 0 1
1) "three"
2) "two"
127.0.0.1:6379> RPUSH list right #将一个值或者多个值，插入到列表头部（右）
(integer) 4
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
4) "right"
#########################################################
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
4) "right"
127.0.0.1:6379> LPOP list # 移除list的第一个元素
"three"
127.0.0.1:6379> RPOP list # 移除list的最后一个元素
"right"
127.0.0.1:6379> LRANGE list 0 -1
1) "two"
2) "one"
#########################################################
# lindex 通过下标获取值
127.0.0.1:6379> LINDEX list 1
"one"
127.0.0.1:6379> LINDEX list 0
"two"
#########################################################
# len 长度
127.0.0.1:6379> lpush list one
(integer) 1
127.0.0.1:6379> lpush list two
(integer) 2
127.0.0.1:6379> lpush list three
(integer) 3
127.0.0.1:6379> llen list
(integer) 3
#########################################################
127.0.0.1:6379> lpush list three
(integer) 4
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "three"
3) "two"
4) "one"
127.0.0.1:6379> lrem list 1 one #移除list集合指定数的value，精确匹配
(integer) 1
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "three"
3) "two"
127.0.0.1:6379> lrem list 2 three
(integer) 2
127.0.0.1:6379> LRANGE list 0 -1
1) "two"
#########################################################
# trim 修剪
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> rpush mylist "hello"
(integer) 1
127.0.0.1:6379> rpush mylist "hello1"
(integer) 2
127.0.0.1:6379> rpush mylist "hello12"
(integer) 3
127.0.0.1:6379> rpush mylist "hello123"
(integer) 4
127.0.0.1:6379> ltrim mylist 1 2 # 通过下标截取指定长度，这个list已经被改变了，截断了之神下截取的元素
OK
127.0.0.1:6379> lrange mylist 1 -1
1) "hello12"
127.0.0.1:6379> lrange mylist 0 -1
1) "hello1"
2) "hello12"
#########################################################
# 移除列表最后一个元素，将他移动到新的列表中
127.0.0.1:6379> rpush mylist "hello1"
(integer) 1
127.0.0.1:6379> rpush mylist "hello2"
(integer) 2
127.0.0.1:6379> rpoplpush mylist myotherlist
"hello2"
127.0.0.1:6379> lrange mylist 0 -1
1) "hello1"
127.0.0.1:6379> lrange myotherlist 0 -1
1) "hello2"
#########################################################
# lset 将列表中指定下标的值替换为另外一个值，更新操作
127.0.0.1:6379> exists list
(integer) 0
127.0.0.1:6379> lset list 0 item # 如果不存在列表我们去更新就会报错
(error) ERR no such key
127.0.0.1:6379> lpush list value1
(integer) 1
127.0.0.1:6379> lrange list 0 0
1) "value1"
127.0.0.1:6379> lset list 0 item # 如果存在，更新当前下标的值
OK
127.0.0.1:6379> lrange list 0 0
1) "item"
127.0.0.1:6379> lset list 1 other # 如果不存在，就会报错
(error) ERR index out of range
#########################################################
# linsert 将某个具体的value插入到列表中某个元素的前面或者后面
127.0.0.1:6379> rpush mylist hello
(integer) 1
127.0.0.1:6379> rpush mylist world
(integer) 2
127.0.0.1:6379> linsert mylist before "world" "other"
(integer) 3
127.0.0.1:6379> lrange mylist 0 -1
1) "hello"
2) "other"
3) "world"
127.0.0.1:6379> linsert mylist after world new
(integer) 4
127.0.0.1:6379> lrange mylist 0 -1
1) "hello"
2) "other"
3) "world"
4) "new"
---------------------------LPUSH---RPUSH---LRANGE--------------------------------
127.0.0.1:6379> LPUSH mylist k1 # LPUSH mylist=>{1}
(integer) 1
127.0.0.1:6379> LPUSH mylist k2 # LPUSH mylist=>{2,1}
(integer) 2
127.0.0.1:6379> RPUSH mylist k3 # RPUSH mylist=>{2,1,3}
(integer) 3
127.0.0.1:6379> get mylist # 普通的get是无法获取list值的
(error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> LRANGE mylist 0 4 # LRANGE 获取起止位置范围内的元素
1) "k2"
2) "k1"
3) "k3"
127.0.0.1:6379> LRANGE mylist 0 2
1) "k2"
2) "k1"
3) "k3"
127.0.0.1:6379> LRANGE mylist 0 1
1) "k2"
2) "k1"
127.0.0.1:6379> LRANGE mylist 0 -1 # 获取全部元素
1) "k2"
2) "k1"
3) "k3"
---------------------------LPUSHX---RPUSHX-----------------------------------
127.0.0.1:6379> LPUSHX list v1 # list不存在 LPUSHX失败
(integer) 0
127.0.0.1:6379> LPUSHX list v1 v2
(integer) 0
127.0.0.1:6379> LPUSHX mylist k4 k5 # 向mylist中 左边 PUSH k4 k5
(integer) 5
127.0.0.1:6379> LRANGE mylist 0 -1
1) "k5"
2) "k4"
3) "k2"
4) "k1"
5) "k3"
---------------------------LINSERT--LLEN--LINDEX--LSET----------------------------
127.0.0.1:6379> LINSERT mylist after k2 ins_key1 # 在k2元素后 插入ins_key1
(integer) 6
127.0.0.1:6379> LRANGE mylist 0 -1
1) "k5"
2) "k4"
3) "k2"
4) "ins_key1"
5) "k1"
6) "k3"
127.0.0.1:6379> LLEN mylist # 查看mylist的长度
(integer) 6
127.0.0.1:6379> LINDEX mylist 3 # 获取下标为3的元素
"ins_key1"
127.0.0.1:6379> LINDEX mylist 0
"k5"
127.0.0.1:6379> LSET mylist 3 k6 # 将下标3的元素 set值为k6
OK
127.0.0.1:6379> LRANGE mylist 0 -1
1) "k5"
2) "k4"
3) "k2"
4) "k6"
5) "k1"
6) "k3"
---------------------------LPOP--RPOP--------------------------
127.0.0.1:6379> LPOP mylist # 左侧(头部)弹出
"k5"
127.0.0.1:6379> RPOP mylist # 右侧(尾部)弹出
"k3"
---------------------------RPOPLPUSH--------------------------
127.0.0.1:6379> LRANGE mylist 0 -1
1) "k4"
2) "k2"
3) "k6"
4) "k1"
127.0.0.1:6379> RPOPLPUSH mylist newlist # 将mylist的最后一个值(k1)弹出，加入到newlist的头部
"k1"
127.0.0.1:6379> LRANGE newlist 0 -1
1) "k1"
127.0.0.1:6379> LRANGE mylist 0 -1
1) "k4"
2) "k2"
3) "k6"
---------------------------LTRIM--------------------------
127.0.0.1:6379> LTRIM mylist 0 1 # 截取mylist中的 0~1部分
OK
127.0.0.1:6379> LRANGE mylist 0 -1
1) "k4"
2) "k2"
# 初始 mylist: k2,k2,k2,k2,k2,k2,k4,k2,k2,k2,k2
---------------------------LREM--------------------------
127.0.0.1:6379> LREM mylist 3 k2 # 从头部开始搜索 至多删除3个 k2
(integer) 3
# 删除后：mylist: k2,k2,k2,k4,k2,k2,k2,k2
127.0.0.1:6379> LREM mylist -2 k2 #从尾部开始搜索 至多删除2个 k2
(integer) 2
# 删除后：mylist: k2,k2,k2,k4,k2,k2
---------------------------BLPOP--BRPOP--------------------------
mylist: k2,k2,k2,k4,k2,k2
newlist: k1
127.0.0.1:6379> BLPOP newlist mylist 30 # 从newlist中弹出第一个值，mylist作为候选
1) "newlist" # 弹出
2) "k1"
127.0.0.1:6379> BLPOP newlist mylist 30
1) "mylist" # 由于newlist空了 从mylist中弹出
2) "k2"
127.0.0.1:6379> BLPOP newlist 30
(30.10s) # 超时了
127.0.0.1:6379> BLPOP newlist 30 # 我们连接另一个客户端向newlist中push了test, 阻塞被解决。
1) "newlist"
2) "test"
(12.54s)
小结
- list实际上是一个链表，before Node after , left, right 都可以插入值
- 如果key不存在，则创建新的链表
- 如果key存在，新增内容
- 如果移除了所有值，空链表，也代表不存在
- 在两边插入或者改动值，效率最高！修改中间元素，效率相对较低
应用：
消息排队！消息队列（Lpush Rpop）,栈（Lpush Lpop）
3、Set(集合)
Redis的Set是string类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。
Redis 中 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。
| 命令 | 描述 |
|---|---|
SADD key member1[member2..] |
向集合中无序增加一个/多个成员 |
SCARD key |
获取集合的成员数 |
SMEMBERS key |
返回集合中所有的成员 |
SISMEMBER key member |
查询member元素是否是集合的成员,结果是无序的 |
SRANDMEMBER key [count] |
随机返回集合中count个成员，count缺省值为1 |
SPOP key [count] |
随机移除并返回集合中count个成员，count缺省值为1 |
SMOVE source destination member |
将source集合的成员member移动到destination集合 |
SREM key member1[member2..] |
移除集合中一个/多个成员 |
SDIFF key1[key2..] |
返回所有集合的差集 key1- key2 - … |
SDIFFSTORE destination key1[key2..] |
在SDIFF的基础上，将结果保存到集合中==(覆盖)==。不能保存到其他类型key噢！ |
SINTER key1 [key2..] |
返回所有集合的交集 |
SINTERSTORE destination key1[key2..] |
在SINTER的基础上，存储结果到集合中。覆盖 |
SUNION key1 [key2..] |
返回所有集合的并集 |
SUNIONSTORE destination key1 [key2..] |
在SUNION的基础上，存储结果到及和张。覆盖 |
SSCAN KEY [MATCH pattern] [COUNT count] |
在大量数据环境下，使用此命令遍历集合中元素，每次遍历部分 |
---------------SADD--SCARD--SMEMBERS--SISMEMBER--------------------
127.0.0.1:6379> SADD myset m1 m2 m3 m4 # 向myset中增加成员 m1~m4
(integer) 4
127.0.0.1:6379> SCARD myset # 获取集合的成员数目
(integer) 4
127.0.0.1:6379> smembers myset # 获取集合中所有成员
1) "m4"
2) "m3"
3) "m2"
4) "m1"
127.0.0.1:6379> SISMEMBER myset m5 # 查询m5是否是myset的成员
(integer) 0 # 不是，返回0
127.0.0.1:6379> SISMEMBER myset m2
(integer) 1 # 是，返回1
127.0.0.1:6379> SISMEMBER myset m3
(integer) 1
---------------------SRANDMEMBER--SPOP----------------------------------
127.0.0.1:6379> SRANDMEMBER myset 3 # 随机返回3个成员
1) "m2"
2) "m3"
3) "m4"
127.0.0.1:6379> SRANDMEMBER myset # 随机返回1个成员
"m3"
127.0.0.1:6379> SPOP myset 2 # 随机移除并返回2个成员
1) "m1"
2) "m4"
# 将set还原到{m1,m2,m3,m4}
---------------------SMOVE--SREM----------------------------------------
127.0.0.1:6379> SMOVE myset newset m3 # 将myset中m3成员移动到newset集合
(integer) 1
127.0.0.1:6379> SMEMBERS myset
1) "m4"
2) "m2"
3) "m1"
127.0.0.1:6379> SMEMBERS newset
1) "m3"
127.0.0.1:6379> SREM newset m3 # 从newset中移除m3元素
(integer) 1
127.0.0.1:6379> SMEMBERS newset
(empty list or set)
# 下面开始是多集合操作,多集合操作中若只有一个参数默认和自身进行运算
# setx=>{m1,m2,m4,m6}, sety=>{m2,m5,m6}, setz=>{m1,m3,m6}
-----------------------------SDIFF------------------------------------
127.0.0.1:6379> SDIFF setx sety setz # 等价于setx-sety-setz
1) "m4"
127.0.0.1:6379> SDIFF setx sety # setx - sety
1) "m4"
2) "m1"
127.0.0.1:6379> SDIFF sety setx # sety - setx
1) "m5"
-------------------------SINTER---------------------------------------
# 共同关注（交集）
127.0.0.1:6379> SINTER setx sety setz # 求 setx、sety、setx的交集
1) "m6"
127.0.0.1:6379> SINTER setx sety # 求setx sety的交集
1) "m2"
2) "m6"
-------------------------SUNION---------------------------------------
127.0.0.1:6379> SUNION setx sety setz # setx sety setz的并集
1) "m4"
2) "m6"
3) "m3"
4) "m2"
5) "m1"
6) "m5"
127.0.0.1:6379> SUNION setx sety # setx sety 并集
1) "m4"
2) "m6"
3) "m2"
4) "m1"
5) "m5"
微博：A用户将所有关注的人放在一个set集合中！将他的粉丝也放在一个集合中！
共同关注，共同爱好，二度好友，推荐好友（六度理论）
4、Hash（哈希）
Redis hash 是一个string类型的field和value的映射表，hash特别适合用于存储对象。
Set就是一种简化的Hash,只变动key,而value使用默认值填充。可以将一个Hash表作为一个对象进行存储，表中存放对象的信息。
| 命令 | 描述 |
|---|---|
HSET key field value |
将哈希表 key 中的字段 field 的值设为 value 。重复设置同一个field会覆盖,返回0 |
HMSET key field1 value1 [field2 value2..] |
同时将多个 field-value (域-值)对设置到哈希表 key 中。 |
HSETNX key field value |
只有在字段 field 不存在时，设置哈希表字段的值。 |
HGET key field value |
获取存储在哈希表中指定字段的值 |
HMGET key field1 [field2..] |
获取所有给定字段的值 |
HGETALL key |
获取在哈希表key 的所有字段和值 |
HKEYS key |
获取哈希表key中所有的字段 |
HLEN key |
获取哈希表中字段的数量 |
HVALS key |
获取哈希表中所有值 |
HDEL key field1 [field2..] |
删除哈希表key中一个/多个field字段 |
HINCRBY key field n |
为哈希表 key 中的指定字段的整数值加上增量n，并返回增量后结果 一样只适用于整数型字段 |
HINCRBYFLOAT key field n |
为哈希表 key 中的指定字段的浮点数值加上增量 n。 |
HSCAN key cursor [MATCH pattern] [COUNT count] |
迭代哈希表中的键值对。 |
------------------------HSET--HMSET--HSETNX----------------
127.0.0.1:6379> HSET studentx name sakura # 将studentx哈希表作为一个对象，设置name为sakura
(integer) 1
127.0.0.1:6379> HSET studentx name gyc # 重复设置field进行覆盖，并返回0
(integer) 0
127.0.0.1:6379> HSET studentx age 20 # 设置studentx的age为20
(integer) 1
127.0.0.1:6379> HMSET studentx sex 1 tel 15623667886 # 设置sex为1，tel为15623667886
OK
127.0.0.1:6379> HSETNX studentx name gyc # HSETNX 设置已存在的field
(integer) 0 # 失败
127.0.0.1:6379> HSETNX studentx email 12345@qq.com
(integer) 1 # 成功
----------------------HEXISTS--------------------------------
127.0.0.1:6379> HEXISTS studentx name # name字段在studentx中是否存在
(integer) 1 # 存在
127.0.0.1:6379> HEXISTS studentx addr
(integer) 0 # 不存在
-------------------HGET--HMGET--HGETALL-----------
127.0.0.1:6379> HGET studentx name # 获取studentx中name字段的value
"gyc"
127.0.0.1:6379> HMGET studentx name age tel # 获取studentx中name、age、tel字段的value
1) "gyc"
2) "20"
3) "15623667886"
127.0.0.1:6379> HGETALL studentx # 获取studentx中所有的field及其value
1) "name"
2) "gyc"
3) "age"
4) "20"
5) "sex"
6) "1"
7) "tel"
8) "15623667886"
9) "email"
10) "[email protected]"
--------------------HKEYS--HLEN--HVALS--------------
127.0.0.1:6379> HKEYS studentx # 查看studentx中所有的field
1) "name"
2) "age"
3) "sex"
4) "tel"
5) "email"
127.0.0.1:6379> HLEN studentx # 查看studentx中的字段数量
(integer) 5
127.0.0.1:6379> HVALS studentx # 查看studentx中所有的value
1) "gyc"
2) "20"
3) "1"
4) "15623667886"
5) "[email protected]"
-------------------------HDEL--------------------------
127.0.0.1:6379> HDEL studentx sex tel # 删除studentx 中的sex、tel字段
(integer) 2
127.0.0.1:6379> HKEYS studentx
1) "name"
2) "age"
3) "email"
-------------HINCRBY--HINCRBYFLOAT------------------------
127.0.0.1:6379> HINCRBY studentx age 1 # studentx的age字段数值+1
(integer) 21
127.0.0.1:6379> HINCRBY studentx name 1 # 非整数字型字段不可用
(error) ERR hash value is not an integer
127.0.0.1:6379> HINCRBYFLOAT studentx weight 0.6 # weight字段增加0.6
"90.8"
Hash变更的数据user name age，尤其是用户信息之类的，经常变动的信息！Hash更适合于对象的存储，Sring更加适合字符串存储！
5、Zset（有序集合）
不同的是每个元素都会关联一个double类型的分数（score）。
redis正是通过分数来为集合中的成员进行从小到大的排序。score相同：按字典顺序排序
有序集合的成员是唯一的,但分数(score)却可以重复。
| 命令 | 描述 |
|---|---|
ZADD key score member1 [score2 member2] |
向有序集合添加一个或多个成员，或者更新已存在成员的分数 |
ZCARD key |
获取有序集合的成员数 |
ZCOUNT key min max |
计算在有序集合中指定区间score的成员数 |
ZINCRBY key n member |
有序集合中对指定成员的分数加上增量 n |
ZSCORE key member |
返回有序集中，成员的分数值 |
ZRANK key member |
返回有序集合中指定成员的索引 |
ZRANGE key start end |
通过索引区间返回有序集合成指定区间内的成员 |
ZRANGEBYLEX key min max |
通过字典区间返回有序集合的成员 |
ZRANGEBYSCORE key min max |
通过分数返回有序集合指定区间内的成员==-inf 和 +inf分别表示最小最大值，只支持开区间()== |
ZLEXCOUNT key min max |
在有序集合中计算指定字典区间内成员数量 |
ZREM key member1 [member2..] |
移除有序集合中一个/多个成员 |
ZREMRANGEBYLEX key min max |
移除有序集合中给定的字典区间的所有成员 |
ZREMRANGEBYRANK key start stop |
移除有序集合中给定的排名区间的所有成员 |
ZREMRANGEBYSCORE key min max |
移除有序集合中给定的分数区间的所有成员 |
ZREVRANGE key start end |
返回有序集中指定区间内的成员，通过索引，分数从高到底 |
ZREVRANGEBYSCORRE key max min |
返回有序集中指定分数区间内的成员，分数从高到低排序 |
ZREVRANGEBYLEX key max min |
返回有序集中指定字典区间内的成员，按字典顺序倒序 |
ZREVRANK key member |
返回有序集合中指定成员的排名，有序集成员按分数值递减(从大到小)排序 |
ZINTERSTORE destination numkeys key1 [key2 ..] |
计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中，numkeys：表示参与运算的集合数，将score相加作为结果的score |
ZUNIONSTORE destination numkeys key1 [key2..] |
计算给定的一个或多个有序集的交集并将结果集存储在新的有序集合 key 中 |
ZSCAN key cursor [MATCH pattern\] [COUNT count] |
迭代有序集合中的元素（包括元素成员和元素分值） |
-------------------ZADD--ZCARD--ZCOUNT--------------
127.0.0.1:6379> ZADD myzset 1 m1 2 m2 3 m3 # 向有序集合myzset中添加成员m1 score=1 以及成员m2 score=2..
(integer) 2
127.0.0.1:6379> ZCARD myzset # 获取有序集合的成员数
(integer) 2
127.0.0.1:6379> ZCOUNT myzset 0 1 # 获取score在 [0,1]区间的成员数量
(integer) 1
127.0.0.1:6379> ZCOUNT myzset 0 2
(integer) 2
----------------ZINCRBY--ZSCORE--------------------------
127.0.0.1:6379> ZINCRBY myzset 5 m2 # 将成员m2的score +5
"7"
127.0.0.1:6379> ZSCORE myzset m1 # 获取成员m1的score
"1"
127.0.0.1:6379> ZSCORE myzset m2
"7"
--------------ZRANK--ZRANGE-----------------------------------
127.0.0.1:6379> ZRANK myzset m1 # 获取成员m1的索引，索引按照score排序，score相同索引值按字典顺序顺序增加
(integer) 0
127.0.0.1:6379> ZRANK myzset m2
(integer) 2
127.0.0.1:6379> ZRANGE myzset 0 1 # 获取索引在 0~1的成员
1) "m1"
2) "m3"
127.0.0.1:6379> ZRANGE myzset 0 -1 # 获取全部成员
1) "m1"
2) "m3"
3) "m2"
#testset=>{abc,add,amaze,apple,back,java,redis} score均为0
------------------ZRANGEBYLEX---------------------------------
127.0.0.1:6379> ZRANGEBYLEX testset - + # 返回所有成员
1) "abc"
2) "add"
3) "amaze"
4) "apple"
5) "back"
6) "java"
7) "redis"
127.0.0.1:6379> ZRANGEBYLEX testset - + LIMIT 0 3 # 分页 按索引显示查询结果的 0,1,2条记录
1) "abc"
2) "add"
3) "amaze"
127.0.0.1:6379> ZRANGEBYLEX testset - + LIMIT 3 3 # 显示 3,4,5条记录
1) "apple"
2) "back"
3) "java"
127.0.0.1:6379> ZRANGEBYLEX testset (- [apple # 显示 (-,apple] 区间内的成员
1) "abc"
2) "add"
3) "amaze"
4) "apple"
127.0.0.1:6379> ZRANGEBYLEX testset [apple [java # 显示 [apple,java]字典区间的成员
1) "apple"
2) "back"
3) "java"
-----------------------ZRANGEBYSCORE---------------------
127.0.0.1:6379> ZRANGEBYSCORE myzset 1 10 # 返回score在 [1,10]之间的的成员
1) "m1"
2) "m3"
3) "m2"
127.0.0.1:6379> ZRANGEBYSCORE myzset 1 5
1) "m1"
2) "m3"
--------------------ZLEXCOUNT-----------------------------
127.0.0.1:6379> ZLEXCOUNT testset - +
(integer) 7
127.0.0.1:6379> ZLEXCOUNT testset [apple [java
(integer) 3
------------------ZREM--ZREMRANGEBYLEX--ZREMRANGBYRANK--ZREMRANGEBYSCORE--------------------------------
127.0.0.1:6379> ZREM testset abc # 移除成员abc
(integer) 1
127.0.0.1:6379> ZREMRANGEBYLEX testset [apple [java # 移除字典区间[apple,java]中的所有成员
(integer) 3
127.0.0.1:6379> ZREMRANGEBYRANK testset 0 1 # 移除排名0~1的所有成员
(integer) 2
127.0.0.1:6379> ZREMRANGEBYSCORE myzset 0 3 # 移除score在 [0,3]的成员
(integer) 2
# testset=> {abc,add,apple,amaze,back,java,redis} score均为0
# myzset=> {(m1,1),(m2,2),(m3,3),(m4,4),(m7,7),(m9,9)}
----------------ZREVRANGE--ZREVRANGEBYSCORE--ZREVRANGEBYLEX-----------
127.0.0.1:6379> ZREVRANGE myzset 0 3 # 按score递减排序，然后按索引，返回结果的 0~3
1) "m9"
2) "m7"
3) "m4"
4) "m3"
127.0.0.1:6379> ZREVRANGE myzset 2 4 # 返回排序结果的 索引的2~4
1) "m4"
2) "m3"
3) "m2"
127.0.0.1:6379> ZREVRANGEBYSCORE myzset 6 2 # 按score递减顺序 返回集合中分数在[2,6]之间的成员
1) "m4"
2) "m3"
3) "m2"
127.0.0.1:6379> ZREVRANGEBYLEX testset [java (add # 按字典倒序 返回集合中(add,java]字典区间的成员
1) "java"
2) "back"
3) "apple"
4) "amaze"
-------------------------ZREVRANK------------------------------
127.0.0.1:6379> ZREVRANK myzset m7 # 按score递减顺序，返回成员m7索引
(integer) 1
127.0.0.1:6379> ZREVRANK myzset m2
(integer) 4
# mathscore=>{(xm,90),(xh,95),(xg,87)} 小明、小红、小刚的数学成绩
# enscore=>{(xm,70),(xh,93),(xg,90)} 小明、小红、小刚的英语成绩
-------------------ZINTERSTORE--ZUNIONSTORE-----------------------------------
127.0.0.1:6379> ZINTERSTORE sumscore 2 mathscore enscore # 将mathscore enscore进行合并 结果存放到sumscore
(integer) 3
127.0.0.1:6379> ZRANGE sumscore 0 -1 withscores # 合并后的score是之前集合中所有score的和
1) "xm"
2) "160"
3) "xg"
4) "177"
5) "xh"
6) "188"
127.0.0.1:6379> ZUNIONSTORE lowestscore 2 mathscore enscore AGGREGATE MIN # 取两个集合的成员score最小值作为结果的
(integer) 3
127.0.0.1:6379> ZRANGE lowestscore 0 -1 withscores
1) "xm"
2) "70"
3) "xg"
4) "87"
5) "xh"
6) "93"
应用案例：
- set排序 存储班级成绩表 工资表排序！
- 普通消息1 重要消息 2 带权重进行判断
- 排行榜应用实现，取Top N测试
四、三种特殊数据类型
1、Geospatial(地理位置)
Redis 地理位置(geo) 命令
朋友的定位，附近的人，打车距离计算
redis的Geo在redis3.2版本就推出了！可以推算地理位置信息，两地之间的举例，方圆几里的人
| 命令 | 描述 |
|---|---|
| Redis GEOHASH 命令 | 返回一个或多个位置元素的 Geohash 表示 |
| Redis GEOPOS 命令 | 从key里返回所有给定位置元素的位置（经度和纬度） |
| Redis GEODIST 命令 | 返回两个给定位置之间的距离 |
| Redis GEORADIUS 命令 | 以给定的经纬度为中心， 找出某一半径内的元素 |
| Redis GEOADD 命令 | 将指定的地理空间位置（纬度、经度、名称）添加到指定的key中 |
| Redis GEORADIUSBYMEMBER 命令 | 找出位于指定范围内的元素，中心点是由给定的位置元素决定 |
使用经纬度定位地理坐标并用一个有序集合zset保存，所以zset命令也可以使用
| 命令 | 描述 |
|---|---|
geoadd key longitud(经度) latitude(纬度) member [..] |
将具体经纬度的坐标存入一个有序集合 |
geopos key member [member..] |
获取集合中的一个/多个成员坐标 |
geodist key member1 member2 [unit] |
返回两个给定位置之间的距离。默认以米作为单位。 |
| georadius key longitude latitude radius m|km|mi|ft [WITHCOORD][WITHDIST] [WITHHASH] [COUNT count] | 以给定的经纬度为中心， 返回集合包含的位置元素当中， 与中心的距离不超过给定最大距离的所有位置元素。 |
GEORADIUSBYMEMBER key member radius... |
功能与GEORADIUS相同，只是中心位置不是具体的经纬度，而是使用结合中已有的成员作为中心点。 |
geohash key member1 [member2..] |
返回一个或多个位置元素的Geohash表示。使用Geohash位置52点整数编码。 |
有效经纬度
有效的经度从-180度到180度。
有效的纬度从-85.05112878度到85.05112878度。
两个人之间的距离！
指定单位的参数 unit 必须是以下单位的其中一个：
- m 表示单位为米。
- km 表示单位为千米。
- mi 表示单位为英里。
- ft 表示单位为英尺。
关于GEORADIUS的参数
通过
georadius就可以完成 附近的人功能withcoord:带上坐标
withdist:带上距离，单位与半径单位相同
COUNT n : 只显示前n个(按距离递增排序)
----------------georadius---------------------
127.0.0.1:6379> GEORADIUS china:city 120 30 500 km withcoord withdist # 查询经纬度(120,30)坐标500km半径内的成员
1) 1) "hangzhou"
2) "29.4151"
3) 1) "120.20000249147415"
2) "30.199999888333501"
2) 1) "shanghai"
2) "205.3611"
3) 1) "121.40000134706497"
2) "31.400000253193539"
------------geohash---------------------------
127.0.0.1:6379> geohash china:city yichang shanghai # 获取成员经纬坐标的geohash表示
1) "wmrjwbr5250"
2) "wtw6ds0y300"
Redis GEORADIUSBYMEMBER 命令 - 找出位于指定范围内的元素，中心点是由给定的位置元素决定
2、Hyperloglog(基数统计)
Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。
花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。
因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。
其底层使用string数据类型
什么是基数？
数据集中不重复的元素的个数。
应用场景：
网页的访问量（UV）：一个用户多次访问，也只能算作一个人。
传统实现，存储用户的id,然后每次进行比较。当用户变多之后这种方式及其浪费空间，而我们的目的只是计数，Hyperloglog就能帮助我们利用最小的空间完成。
| 命令 | 描述 |
|---|---|
PFADD key element1 [elememt2..] |
添加指定元素到 HyperLogLog 中 |
PFCOUNT key [key] |
返回给定 HyperLogLog 的基数估算值。 |
PFMERGE destkey sourcekey [sourcekey..] |
将多个 HyperLogLog 合并为一个 HyperLogLog |
----------PFADD--PFCOUNT---------------------
127.0.0.1:6379> PFADD myelemx a b c d e f g h i j k # 添加元素
(integer) 1
127.0.0.1:6379> type myelemx # hyperloglog底层使用String
string
127.0.0.1:6379> PFCOUNT myelemx # 估算myelemx的基数
(integer) 11
127.0.0.1:6379> PFADD myelemy i j k z m c b v p q s
(integer) 1
127.0.0.1:6379> PFCOUNT myelemy
(integer) 11
----------------PFMERGE-----------------------
127.0.0.1:6379> PFMERGE myelemz myelemx myelemy # 合并myelemx和myelemy 成为myelemz
OK
127.0.0.1:6379> PFCOUNT myelemz # 估算基数
(integer) 17
如果允许容错，那么一定可以使用Hyperloglog !
如果不允许容错，就使用set或者自己的数据类型即可 ！
3、BitMaps(位图)
使用位存储，信息状态只有 0 和 1
Bitmap是一串连续的2进制数字（0或1），每一位所在的位置为偏移(offset)，在bitmap上可执行AND,OR,XOR,NOT以及其它位操作。
应用场景
| 命令 | 描述 |
|---|---|
setbit key offset value |
为指定key的offset位设置值 |
getbit key offset |
获取offset位的值 |
bitcount key [start end] |
统计字符串被设置为1的bit数，也可以指定统计范围按字节 |
bitop operration destkey key[key..] |
对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。 |
BITPOS key bit [start] [end] |
返回字符串里面第一个被设置为1或者0的bit位。start和end只能按字节,不能按位 |
------------setbit--getbit--------------
127.0.0.1:6379> setbit sign 0 1 # 设置sign的第0位为 1
(integer) 0
127.0.0.1:6379> setbit sign 2 1 # 设置sign的第2位为 1 不设置默认 是0
(integer) 0
127.0.0.1:6379> setbit sign 3 1
(integer) 0
127.0.0.1:6379> setbit sign 5 1
(integer) 0
127.0.0.1:6379> type sign
string
127.0.0.1:6379> getbit sign 2 # 获取第2位的数值
(integer) 1
127.0.0.1:6379> getbit sign 3
(integer) 1
127.0.0.1:6379> getbit sign 4 # 未设置默认是0
(integer) 0
-----------bitcount----------------------------
127.0.0.1:6379> BITCOUNT sign # 统计sign中为1的位数
(integer) 4
统计操作：统计打卡的天数
签到统计、状态统计
bitmaps的底层
五、事务
Redis的单条命令是保证原子性的，但是redis事务不能保证原子性
Redis事务本质：一组命令的集合。
----------------- 队列 set set set 执行 -------------------
事务中每条命令都会被序列化，执行过程中按顺序执行，不允许其他命令进行干扰。
- 一次性
- 顺序性
- 排他性
Redis事务没有隔离级别的概念
Redis单条命令是保证原子性的，但是事务不保证原子性！
1、Redis事务操作过程
- 开启事务（
multi） - 命令入队
- 执行事务（
exec）
所以事务中的命令在加入时都没有被执行，直到提交时才会开始执行(Exec)一次性完成。
127.0.0.1:6379> multi # 开启事务
OK
127.0.0.1:6379> set k1 v1 # 命令入队
QUEUED
127.0.0.1:6379> set k2 v2 # ..
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> keys *
QUEUED
127.0.0.1:6379> exec # 事务执行
1) OK
2) OK
3) "v1"
4) OK
5) 1) "k3"
2) "k2"
3) "k1"
取消事务(discurd)
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> DISCARD # 放弃事务
OK
127.0.0.1:6379> EXEC
(error) ERR EXEC without MULTI # 当前未开启事务
127.0.0.1:6379> get k1 # 被放弃事务中命令并未执行
(nil)
2、事务错误
代码语法错误（编译时异常）所有的命令都不执行
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> error k1 # 这是一条语法错误命令
(error) ERR unknown command `error`, with args beginning with: `k1`, # 会报错但是不影响后续命令入队
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors. # 执行报错
127.0.0.1:6379> get k1
(nil) # 其他命令并没有被执行
代码逻辑错误 (运行时异常) **其他命令可以正常执行 ** >>> 所以不保证事务原子性
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> INCR k1 # 这条命令逻辑错误（对字符串进行增量）
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range # 运行时报错
4) "v2" # 其他命令正常执行
# 虽然中间有一条命令报错了，但是后面的指令依旧正常执行成功了。
# 所以说Redis单条指令保证原子性，但是Redis事务不能保证原子性。
3、监控
悲观锁：
- 很悲观，认为什么时候都会出现问题，无论做什么都会加锁
乐观锁：
- 很乐观，认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，在此期间是否有人修改过这个数据
- 获取version
- 更新的时候比较version
使用**watch key**监控指定数据，相当于乐观锁加锁。
正常执行
127.0.0.1:6379> set money 100 # 设置余额:100
OK
127.0.0.1:6379> set use 0 # 支出使用:0
OK
127.0.0.1:6379> watch money # 监视money (上锁)
OK
127.0.0.1:6379> multi #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功！
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> exec # 监视值没有被中途修改，事务正常执行
1) (integer) 80
2) (integer) 20
测试多线程修改值，使用watch可以当做redis的乐观锁操作（相当于getversion）
我们启动另外一个客户端模拟插队线程。
线程1：
127.0.0.1:6379> watch money # money 锁
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 10
QUEUED
127.0.0.1:6379(TX)> incrby out 10
QUEUED
127.0.0.1:6379(TX)> exec
(nil) # 此时事务并没有执行
模拟线程插队，线程2：
127.0.0.1:6379> get money
"80"
127.0.0.1:6379> set money 1000 # 修改了线程一中监视的money
OK
回到线程1，执行事务：
127.0.0.1:6379> EXEC # 执行之前，另一个线程修改了我们的值，这个时候就会导致事务执行失败
(nil) # 没有结果，说明事务执行失败
127.0.0.1:6379> get money # 线程2 修改生效
"600"
127.0.0.1:6379> get use # 线程1事务执行失败，数值没有被修改
"0"
解锁获取最新值，然后再加锁进行事务。
**unwatch**进行解锁。
注意：每次提交执行exec后都会自动释放锁，不管是否成功
六、Jedis
使用Java来操作Redis，Jedis是Redis官方推荐使用的Java连接redis的客户端。
1、什么是jedis？
jedis是Redis官方推荐的java连接开发工具，使用java操作redis中间件，在springboot中使用redisTemplate操作，但是还是要对jedis十分了解才行。
jedis 操作redis的方法就是上面写的命令。例如：
-
导入依赖
<dependency> <groupId>redis.clientsgroupId> <artifactId>jedisartifactId> <version>3.6.3version> dependency> <dependency> <groupId>com.alibabagroupId> <artifactId>fastjsonartifactId> <version>1.2.73version> dependency> -
编码测试
连接数据库
public class TestPing { public static void main(String[] args) { Jedis jedis = new Jedis("127.0.0.1", 6379); String response = jedis.ping(); System.out.println(response); // PONG } }操作命令
断开连接 ：jedis.close()
3、事务操作
public class TestTX {
public static void main(String[] args) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
jedis.flushDB();
JSONObject jsonObject = new JSONObject();
jsonObject.put("hello", "world");
jsonObject.put("name", "xhp");
String result = jsonObject.toString();
// 开启事务
Transaction multi = jedis.multi();
try {
multi.set("user1", result);
multi.set("user2", result);
int i = 1/0; //java代码执行异常，抛出异常
multi.incrBy("user1",10); //这一句命令错误，但是不会有任何异常，正确的命令还会执行
multi.set("user3", result);
//执行事务
multi.exec();
} catch (Exception e) {
//捕获异常，放弃事务
multi.discard();
e.printStackTrace();
} finally {
System.out.println(jedis.get("user1"));
System.out.println(jedis.get("user2"));
System.out.println(jedis.get("user3"));
//最终都要关闭
jedis.close();
}
}
}
七、SpringBoot整合
SpringBoot操作数据: spring-data jpa jdbc mongodb redis !
SpringData也是和SpringBoot齐名的项目!
说明:在SpringBoot2.x之后,原来使用的jedis被替换为了lettuce?
jedis :采用的直连,多个线程操作的话,是不安全的,如果想要避免不安全的,使用jedis pool 连接池!更像BIO 模式
lettuce :采用netty，实例可以再多个线程中进行共享,不存在线程不安全的情况!可以减少线程数据了,更像NIO 模式
1、导入依赖
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-redisartifactId>
dependency>
springboot 2.x后 ，原来使用的 Jedis 被 lettuce 替换。
jedis：采用的直连，多个线程操作的话，是不安全的。如果要避免不安全，使用jedis pool连接池！更像BIO模式
lettuce：采用netty，实例可以在多个线程中共享，不存在线程不安全的情况！可以减少线程数据了，更像NIO模式
我们在学习SpringBoot自动配置的原理时，整合一个组件并进行配置一定会有一个自动配置类xxxAutoConfiguration,并且在spring.factories中也一定能找到这个类的完全限定名。Redis也不例外。
那么就一定还存在一个RedisProperties类
之前我们说SpringBoot2.x后默认使用Lettuce来替换Jedis，现在我们就能来验证了。
先看Jedis:
@ConditionalOnClass注解中有两个类是默认不存在的，所以Jedis是无法生效的
然后再看Lettuce：
完美生效。
现在我们回到RedisAutoConfiguratio
只有两个简单的Bean
-
RedisTemplate
-
StringRedisTemplate
当看到xxTemplate时可以对比RestTemplat、SqlSessionTemplate,通过使用这些Template来间接操作组件。那么这俩也不会例外。分别用于操作Redis和Redis中的String数据类型。
在RedisTemplate上也有一个条件注解，说明我们是可以对其进行定制化的
说完这些，我们需要知道如何编写配置文件然后连接Redis，就需要阅读RedisProperties
这是一些基本的配置属性。
还有一些连接池相关的配置。注意使用时一定使用Lettuce的连接池。
2、编写配置文件
# 配置redis
spring.redis.host=39.99.xxx.xx
spring.redis.port=6379
3、使用RedisTemplate
@SpringBootTest
class Redis02SpringbootApplicationTests {
@Autowired
private RedisTemplate redisTemplate;
@Test
void contextLoads() {
// redisTemplate 操作不同的数据类型，api和我们的指令是一样的
// opsForValue 操作字符串 类似String
// opsForList 操作List 类似List
// opsForHah
// 除了基本的操作，我们常用的方法都可以直接通过redisTemplate操作，比如事务和基本的CRUD
// 获取连接对象
//RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();
//connection.flushDb();
//connection.flushAll();
redisTemplate.opsForValue().set("mykey","kuangshen");
System.out.println(redisTemplate.opsForValue().get("mykey"));
}
}
4、测试结果
此时我们回到Redis查看数据时候，惊奇发现全是乱码，可是程序中可以正常输出：
这时候就关系到存储对象的序列化问题，在网络中传输的对象也是一样需要序列化，否者就全是乱码。
我们转到看那个默认的RedisTemplate内部什么样子：
在最开始就能看到几个关于序列化的参数。
默认的序列化器是采用JDK序列化器
而默认的RedisTemplate中的所有序列化器都是使用这个序列化器：
后续我们定制RedisTemplate就可以对其进行修改。
RedisSerializer提供了多种序列化方案：
-
直接调用RedisSerializer的静态方法来返回序列化器，然后set
-
自己new 相应的实现类，然后set
5、定制RedisTemplate的模板：
我们创建一个Bean加入容器，就会触发RedisTemplate上的条件注解使默认的RedisTemplate失效。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1QR8wQ8g-1630594638915)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724094856057.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ze0rc6OE-1630594638916)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724095047565.png)]
我们需要自己序列化
@Configuration
public class RedisConfig {
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) throws UnknownHostException {
// 将template 泛型设置为 这样一来，只要实体类进行了序列化，我们存什么都不会有乱码的担忧了。
- 通过这样的序列化之后key就不会乱码了，但是在企业开发中一般不直接以原生的编写，将常用的操作封装为RedisUtils，自己写一些工具类来使用
- 在工具类中应该加入一些容错操作，能抛出异常
- 在公司能看到一些封装的RedisUtils
6、自定义Redis工具类
使用RedisTemplate需要频繁调用.opForxxx然后才能进行对应的操作，这样使用起来代码效率低下，工作中一般不会这样使用，而是将这些常用的公共API抽取出来封装成为一个工具类，然后直接使用工具类来间接操作Redis,不但效率高并且易用。
工具类参考博客：
https://www.cnblogs.com/zeng1994/p/03303c805731afc9aa9c60dbbd32a323.html
https://www.cnblogs.com/zhzhlong/p/11434284.html
八、Redis.conf详解
容量单位不区分大小写，G和GB有区别
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BcKgFR9T-1630594638917)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724154145788.png)]
可以使用 include 组合多个配置问题
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0x4FgwIQ-1630594638918)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724154233620.png)]
网络配置
- bind 127.0.0.1 绑定的ip
- protected-mode yes 是否保护模式
- port 6379 端口设置
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i6ESxzlk-1630594638919)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724154412485.png)]
GENERAL 通用
- loglevel notice 日志级别
- debug (a lot of information, useful for development/testing) 开发或测试时用
- verbose (many rarely useful info, but not a mess like the debug level) 一些常用的信息
- notice (moderately verbose, what you want in production probably) 生产模式使用
- warning (only very important / critical messages are logged) 只打印一些重要的 信息
- daemonize no 是否设置为守护进程，Windows中不支持该配置。默认yes
- supervised no
- pidfile /var/run/redis.pid 如果以守护进程的方式运行，就需要指定这个pid文件，不知道有什么用
logfile “” 日志文件保存路径
- databases 16 默认一共16个数据库
- always-show-logo yes 启动时是否显示logo
SNAPSHOTTING 快照，快照分rdb和aof
- save “” 持久化操作的策略
save 900 1 如果900秒内有一次key进行了更新，则持久化一次
save 300 10 如果300秒内有10 key进行了更新，则持久化一次
save 60 10000 如果60秒 内有至少10000个key进行了更新，则持久化一次。一般情况我们不会使用这几种方式，一般都是.
stop-writes-on-bgsave-error yes 如果持久化过程出现错误，是否还要继续
rdbcompression yes 是否压缩rdb文件，需要消耗一些CPU资源
rdbchecksum yes 保存rdb文件的时候，进行错误的检查校验
dir ./ rdb文件保存的目录，默认当前目录下
\dbfilename dump.rdb rdb文件的名字，默认dump
REPLICATION 主从复制，我们后面将主从复制的时候在进行讲解
SECURITY 安全
-
requirepass foobared 设置密码，也可以使用如下命令
127.0.0.1:6379>config get requirepass //获取密码 1) "requirepass" 2) "" 127.0.0.1:6379>config set requirepass 123456 //设置密码 "OK" 127.0.0.1:6379>config get requirepass 1) "requirepass" 2) "123456" 127.0.0.1:6379>ping "PONG" 127.0.0.1:6379>auth 123456 //使用密码登录 "OK"
CLIENTS 客户端配置
maxclients 10000 #最大允许一万个客户端连接
maxmemory #配置redis的最大内存容量
maxmemory-policy noeviction #内存达到上限后的回收策略
noeviction： #默认的策略，即当内存使用达到阈值的时候，所有引起申请内存的命令都会报错；
allkeys-lru：#从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰 。
#适用场景： 如果我们的应用对缓存的访问都是相对热点数据，就可以选择这个策略；
allkeys-random：#随机移除某个key。
#适合的场景：如果我们的应用对于缓存key的访问概率相等，则可以使用这个策略。
#从已经设置了过期时间的key中去选择
volatile-random：#从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
volatile-lru：#从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
volatile-ttl：#从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰；适合场景：这种策略使我们可以向Redis提示哪些key更适合被淘汰，可以自己控制 。
APPEND ONLY 模式
了解，大部分情况下rdb已经足够使用，aof是对rdb的一个补充，并且性能不高，因此使用少
appendonly no #默认不开启aof模式，如果我们要启用aof，一般情况下只需要将该项配置改为yes即可
appendfilename “appendonly.aof” aof#持久化文件的名字
appendfsync
appendfsync always #每次修改都会同步，消耗性能
appendfsync everysec #每秒执行一次同步sync，可能会丢失这一秒的数据
appendfsync no #不执行同步，速度快
no-appendfsync-on-rewrite no #保持默认即可
xxx-rewrite-xxx #重写配置（了解，一般不做修改）
#例如64M，就是说aof会一直将写操作命令追加进aof文件中，如果文件大小超过了这个64m，就会生成一个新的 文件。
九、redis持久化
面试和工作，持久化都是重点！！！即RDB和AOF
Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能。
1、RDB：Redis Databases
什么是RDB
在主从复制中，rdb就是备用的！从机上面！
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里.
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中，带持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的，这就确保了极高的性能.如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感.那RDB方式要不AOF方式更加的高效.RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB, 一般情况下不需要修改这个配置！
RDB保存的文件是，dump.rdb都是在我们的配置文件中快照中进行配置的！
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RDwle7O5-1630594638921)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724162348183.png)]
触发机制
- save 的规则满足的情况下,会自动触发rdb规则
- 执行flushall命令 , 也会触发我们的rdb 规则!
- 退出redis,也会产生rdb文件!
备份就会自动生成一个dump.rdb
如何恢复rdb文件!
-
只需要将rdb 文件放在我们redis启动目录就可以,redis启动的时候会自动检查dump.rdb恢复其中的数据!
-
查看需要存在的位置
127.0.0.1:6379> config get dir 1) "dir" 2) "/usr/local/bin" # 入伙在这个目录下存在dump.rdb 文件,启动就会自动恢复其中的数据
几乎就他自己默认的配置就可以了，但我们还是需要去学习
优点&缺点
优点:
- 适合大规模的数据恢复!
- 对数据的完整性要求不高!
缺点:
- 需要一定的时间间隔进行操作! 如果redis意外宕机了,这个最后一个修改的数据就没有了!
- fork进程的时候,会占用一定的内容空间!
2、AOF(Append Only File)
将我们的所有命令都记录下来,history , 恢复的时候就把这个文件全部在执行一遍
是什么
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件,redis 启动之初会读取改文件重新构建数据,换言之,redis重启的话就跟据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
Aof保存的是 appendonly.aof文件
append
默认是不开启的,我们需要手动进行配置! 我们只需要将appendonly 改为yes就开启了aof!
重启，redis 就可以生效了!
如果这个aof文件有错位,这时候 redis是启动不起来的,我们需要修复这个aof文件
redis 给我提供了一个工具redis-check-aof --fix
如果文件正常,重启就可以直接恢复了！
重写规则说明
aof默认就是文件的无限追加 ，文件会越来越大！
如果aof文件大于64m,太大了 ! fork一个新的进程来将我们的文件进行重写!
优点&缺点
appendonly no # 默认是不开启aof模式的, 默认是使用rdb方式持久化的,再大部分情况下,rdb完全够用!
Appendfilename "appendonly.aof" # 持久化的文件的名字
# appendfsync always # 每次修改都会sync .消耗性能
appendfsync everysec # 每秒执行一次sync,可能会丢失这1s的数据!
# appendfsync no # 不执行sync ,这个时候操作系统自己同步数据,速度最快!
#rewrite 重写
优点:
- 每一次修改都同步,文件的完整性会更好!
- 每秒同步一次,可能会丢失一秒的数据
- 从不同步,效率最高！
缺点:
- 相对于数据文件来说, aof远远大于rdb,修复的速度也比rdb慢!
- aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化！
扩展
1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
4、同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数t
集要比RDB文件保存的数据集要完整。 - RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
5、性能建议
-
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 9001这条规则。
-
如果Enable AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
-
如果不Enable AOF，仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。
十、Redis发布订阅
Redis 发布订阅(pub/sub)是一种消息通信模式: 发送者(pub)发送消息,订阅者(sub)接受消息.微博,微信,关注系统!
Redis 客户端可以订阅任意数量的频道.
订阅/发布消息图:
第一个: 消息发送者, 第二个 :频道 第三个 :消息订阅者!
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6StoNE24-1630594638921)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724172408630.png)]
下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：
当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
命令
这些命令被广泛用于构建即时通信应用,比如网络聊天室和实时广播,实时提醒
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1aAYj8vo-1630594638924)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724180848979.png)]
测试
订阅端
127.0.0.1:6379> subscribe hcd # 订阅一个频道 codeyuaiiao
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "hcd"
3) (integer) 1
# 等待读取推送
1) "message" # 消息
2) "hcd" # 接收消息的频道
3) "hello world" # 消息的具体内容
1) "message"
2) "hcd"
3) "hello yuhaijiao"
发送端:
127.0.0.1:6379> publish hcd "hello world" # 发布者发布消息到频道
(integer) 1
127.0.0.1:6379> publish hcd "hello yuhaijiao" # 发布者发布消息到频道
(integer) 1
127.0.0.1:6379>
原理
Redis是使用C实现的，通过分析Redis源码里的pubsubl.c文件，了解发布和订阅机制的底层实现，籍此加深对Redis的理解。
Redis通过PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令实现发布和订阅功能。
通过SUBSCRIBE命令订阅某频道后，redis-server 里维护了一个字典，字典的键就是一个个channel ，而字典的值则是一个链
表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE 命令的关键,就是将客户端添加到给定channel的订阅链表中。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OozDU5uo-1630594638924)(C:\Users\DELL\AppData\Roaming\Typora\typora-user-images\image-20210724181931287.png)]
通过PUBLISH命令向订阅者发送消息，redis-server 会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这
个频道的所有客户端的链表，遍历这个链表,将消息发布给所有订阅者。
Pub/Sub从字面上理解就是发布( Publish )与订阅( Subscribe) ，在Redis中，你可以设定对某-个key值进行消息发布及消息订
阅,，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这-功能最明显的用法就是用作实时消息系
统,比如普通的即时聊天，群聊等功能。
通过publish命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。
使用场景:
- 实时消息系统!
- 事实聊天! (频道当做聊天室,将信息回显给所有人即可! )
- 订阅,关注系统都是可以的!
稍微复杂的场景我们就会使用 消息中间件MQ
十一、Redis主从复制
1、概念
主从复制，是指将一台Redis服务器的数据,复制到其他的Redis服务器，前者称为主节点(master/leader)，后者称为从节点(slave/follower)；==数据的复制是单向的，只能由主节点到从节点。==Master以写为主,Slave以读为主。
默认情况下，每台Redis服务器都是主节点；
且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
主从复制的作用主要包括:
- 数据冗余：主从复制实现了数据的热备份，使持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题是，可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
- 负载均衡：在主从复制的基础上,配合读写分离，可以由主节点提供写服务(既写Redis数据是应用连接主节点,读Redis数据时应用连接从节点)，分担服务器负载;尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 高可用(集群)基石：除了上诉作用以外，主从复制还是烧饼和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只是用一台Redis是万万不能的(宕机 ，一主二从)，原因如下：
- 从结构上,单个Redis服务器会发生单点故障,并且一台服务需要处理所有的请求负载,压力较大;
- 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis 最大使用内存不应该超过20G。
- 电商网站上的商品，一般都是一次上传，无数次浏览的，说专业的就是"多读少写"。
这种场景,我们可以使用如下这种架构：
只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis !
主从复制，读写分离！80%的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！一组二从！哨兵模式
2、环境配置
只配置从库，不用配置主库！
127.0.0.1:6379> info replication #查看当前库信息
# Replication
role:master #角色 master
connected_slaves:0 #没有从机
master_failover_state:no-failover
master_replid:c5012e2e95cc4889bacfbb3691a80b35a89c6f8d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
复制3个配置文件,然后修改对应的信息
- 端口
- pid名字
- log文件名字
- dump.rdb名字
修改完毕之后,启动我们的3个redis服务器,可以通过进程信息查
3、一主二从
默认情况下, 每台Redis 服务器都是主节点 ; 我们一般情况下只用配置从机就好了!
认老大！一主（79） 二从（80,81）
slaveof 127.0.0.1 6379 # slaveof host 6379 设定谁是主机
info replication 查询信息
slaveof 主机ip 端口号 # 设置从机 slaveof 127.0.0.1 6379
如果两个都配置完了,就有两个从机了
真实的从主配置应该在配置文件中配置，这样的话是永久的,，我们这里使用的是命令，暂时的！
细节
主机可以写, 从机不能写只能读! 主机中的所有信息和数据，都会自动被从机保存。
主机写：
从机读：
测试：主机断开连接，从机依旧连接到主机的，但是没有写操作，这个时候，主机如果回来了，从机依旧可以直接直接获取到主机写的信息！
如果是使用命令行, 来配置的主从,这个时候如果重启了,就会变成主机 ! 只要变为从机, 立马就会从主机中获取值!
复制原理
-
Slave启动成功连接到master后会发送一个sync同步命令
-
Master接到命令,启动后台的存盘进程,同时手机所有接受到的用于修改数据集命令, 在后台进程完毕之后,master将传送整个数据问价难道slave,并完成一次完全同步.
-
全量复制: 二slave服务在接收到数据库文件数据后, 将其存盘并加载到内存中.
-
增量复制: Master继续将新的所有收集到的修改命令依次传给slave,完成同步.
-
但是只要是重新连接master, 一次完全同步(全量复制)将被自动执行! 我们的数据一定可以在从机中看到!
层层链路
上一个M连接下一个S!
这时候也可以完成我们的主从复制!
如果没有老大了,这个时候能不能选择一个老大出来呢? 手动!
谋朝篡位
如果主机断开了连接，我们可以使用slaveof no one 让自己变成主机！其他的节点就可以手动连接到最新的这个主节点(手动)！如果这个时候老大修复了，那就重新连接！
4、哨兵模式
(自动选举老大)
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器,这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一个推荐的方式.更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。
谋朝篡位的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动从库转换为主库
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过他送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里的哨兵有两个作用：
- 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
- 当哨兵检测到master宕机，会自动将slave切换成master，然后通过订阅模式通知其他的从服务器，修改配置文件，让他们切换主机。
然而一个烧饼进程对Redis服务器进行监控，可能会出现问题，为此我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
假设主服务器宕机，哨兵1先检测到这个结果,系统不会马上进行failover过程，仅仅是哨兵1主管的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量到大一定值时，那么哨兵之间就会进行一个投票，投票的结果由一个哨兵发起,进行failover[故障转移]操作。切换成功后,就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
测试
我们目前的状态是 一主二从
- 配置哨兵配置文件 sentinel.conf
# sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
后面的这个数字1,代表主机挂了,slave投票看让谁接替称为主机,票数最多的,就会成为主机
启动
redis-sentinel YuConfig/sentinel.conf
[root@localhost bin]# redis-sentinel YuConfig/sentinel.conf
5748:X 04 Nov 2020 15:59:17.801 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5748:X 04 Nov 2020 15:59:17.801 # Redis version=6.0.8, bits=64, commit=00000000, modified=0, pid=5748, just started
5748:X 04 Nov 2020 15:59:17.801 # Configuration loaded
5748:X 04 Nov 2020 15:59:17.803 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 6.0.8 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 5748
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
5748:X 04 Nov 2020 15:59:17.804 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
5748:X 04 Nov 2020 15:59:17.821 # Sentinel ID is f876de823361a0896cdd4c39d29dd9eb189c4c7c
5748:X 04 Nov 2020 15:59:17.821 # +monitor master myredis 127.0.0.1 6379 quorum 1
如果Master节点断开了,这个时候就会从从机中随机选择一个服务器(这里面有一个投票算法底层)
哨兵日志!
如果主机此时回来了,只能诡兵道心得主机下,当做从机,这就是哨兵模式的规则!
哨兵模式
优点:
- 哨兵集群,基于主从复制模式,所有的主从配置优点,他全有.
- 主从可以切换,故障可以转移,系统的可用性就会更好.
- 哨兵模式就是主从模式的升级,手动到自动,更加健壮.
缺点:
- Redis 不好在线寇蓉,集群容量一旦到达上限,在线扩容就十分麻烦.
- 实现哨兵模式的配置其实是很麻烦的,里面有很多选择!
哨兵模式的 全部配置
port 26379
dir /tmp
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster MySUPER--secret-0123password
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel notification-script mymaster /var/redis/notify.sh
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般运维配置
十二、*Redis缓存穿透和雪崩
在这里我们不会详细的分析解决方案的底层!
Redis 缓存的使用,极大地提升了应用程序的性能和效率,特别是数据查询方面. 但同时, 他也带来了一些问题,其中, 最重要的问题就是数据的一致性问题,从严格意义上来讲,这个问题无解. 如果对数据的一致性要求很高,那么就不能使用缓存.
另外的一些典型问题就是, 缓存穿透 , 缓存击穿和缓存雪崩.目前业界也都有比较流行的解决方案.
1、缓存穿透
概念
缓存穿透的概念很简单 , 用户想要查询一个数据, 发现redis 内存数据库中没有, 也就是缓存没有命中, 于是向持久层数据库查询 .发现也没有, 于是本次查询失败. 当用户很多的时候, 缓存都没有命中(秒杀…) , 于是都去请求持久层数据库 . 这会给持久层数据库造成很大的压力, 这时候就相当于出现了缓存穿透.
解决方案两种
1.布隆过滤器
布隆过滤器是一种数据结构 , 对所有可能查询的参数以hash形式存储, 在控制层先进行校验, 不符合则丢弃, 从而避免不了对底层存储系统的查询压力;
2.缓存空对象
当存储层不命中后 , 即使返回的空对象也将其缓存起来, 同时会设置一个过期时间, 之后再访问这个数据将会从缓存中获取,保护了后端数据源;
但是这种方法会存在两个问题:
- 如果空值能够被缓存起来, 这就意味着缓存需要更多的空间存储更多地键 , 因为这当中可能会有很多的空值的键;
- 及时对空值设置了过期时间 , 还是会存在缓存层和存储层的数据会有一段时间窗口的不一致, 这对于需要保持一致性的业务会有影响.
2、缓存击穿(量太大,缓存过期!)
概念
这里需要注意和缓存击穿的区别, 缓存击穿, 是指一个key非常热点, 在不停的扛着大并发,大并发集中对这一个点进行访问, 当这个key在失效的的瞬间, 持续的大并发就穿破缓存, 直接请求数据库, 就像在一个屏障上凿开了一个洞.
当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据, 由于魂村过期, 会同时访问数据库来查询最新数据, 并且回写缓存, 会导致数据库瞬间压力过大.
解决方案
设置热点数据永不过期
从缓存层面来看, 没有设置过期时间,所以不会出现热点key过期后产生的问题.
加互斥锁
分布式锁: 使用分布式锁,保证对于每个key 同时只有一个线程去查询后端服务, 其他线程没有获得分布式锁的权限, 因此只需要等待即可. 这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大.
3、缓存雪崩
缓存雪崩, 是指在摸一个时间段, 缓存集中过期失效. Redis宕机!
产生雪崩的原因之一, 比如马上就要到双十二零点 , 很快就会迎来一波抢购, 这波商品时间比较集中的放入了缓存,假设缓存一个小时,那么到了凌晨一点中的时候, 这批商品的缓存就都过期了. 而对这批商品的访问查询,都落到了数据库上, 对于数据库而言, 就会产生周期性的压力波峰. 于是所有的请求都会到达存储层, 存储层的调用量会暴增, 造成存储层也会挂掉的情况.
其实集中过期, 倒不是非常致命的, 比较致命的缓存雪崩, 是缓存服务器某个节点宕机或断网 . 因为自然形成的缓存雪崩, 一定是在某个时间段集中创建缓存, 这个时候 , 数据库也是可以顶住压力的. 无非就是对数据库数据库产生周期性的压力而已. 而缓存服务节点的宕机, 对数据库服务器造成的压力是不可遇见的. 很有可能瞬间就把数据库压垮的.
解决方案
redis高可用
这个思想的含义是, 既然redis有可能挂掉, 那我多增设几台redis,这样一台挂掉之后其他的还可以继续工作,其实就是搭建的集群. (异地多活!)
限流降级
这个解决方案的思想是, 在缓存失效后 , 通过枷锁或者队列来控制读数据库写缓存的线程数量. 比如对某个key只允许一个线程查询数据和写缓存, 其他线程等待.
数据预热
数据加热的含义就是在正式部署前, 我先把可能的数据预先访问一遍, 这样可能大量访问的数据就会加载到缓存中. 在即将发生大并发访问前手动触发加载不同的key , 设置不同的过期时间, 让缓存失效的时间点尽量均匀.
/var/redis/reconfig.sh # 一般运维配置
# 十二、*Redis缓存穿透和雪崩
在这里我们不会详细的分析解决方案的底层!
Redis 缓存的使用,极大地提升了应用程序的性能和效率,特别是数据查询方面. 但同时, 他也带来了一些问题,其中, 最重要的问题就是数据的一致性问题,从严格意义上来讲,这个问题无解. 如果对数据的一致性要求很高,那么就不能使用缓存.
另外的一些典型问题就是, 缓存穿透 , 缓存击穿和缓存雪崩.目前业界也都有比较流行的解决方案.
### 1、缓存穿透
> **概念**
缓存穿透的概念很简单 , 用户想要查询一个数据, 发现redis 内存数据库中没有, 也就是缓存没有命中, 于是向持久层数据库查询 .发现也没有, 于是本次查询失败. 当用户很多的时候, 缓存都没有命中(秒杀…) , 于是都去请求持久层数据库 . 这会给持久层数据库造成很大的压力, 这时候就相当于出现了缓存穿透.
> **解决方案两种**
**1.布隆过滤器**
布隆过滤器是一种数据结构 , 对所有可能查询的参数以hash形式存储, 在控制层先进行校验, 不符合则丢弃, 从而避免不了对底层存储系统的查询压力;
**2.缓存空对象**
当存储层不命中后 , 即使返回的空对象也将其缓存起来, 同时会设置一个过期时间, 之后再访问这个数据将会从缓存中获取,保护了后端数据源;
但是这种方法会存在两个问题:
1. 如果空值能够被缓存起来, 这就意味着缓存需要更多的空间存储更多地键 , 因为这当中可能会有很多的空值的键;
2. 及时对空值设置了过期时间 , 还是会存在缓存层和存储层的数据会有一段时间窗口的不一致, 这对于需要保持一致性的业务会有影响.
### 2、缓存击穿(量太大,缓存过期!)
> **概念**
这里需要注意和缓存击穿的区别, 缓存击穿, 是指一个key非常热点, 在不停的扛着大并发,大并发集中对这一个点进行访问, 当这个key在失效的的瞬间, 持续的大并发就穿破缓存, 直接请求数据库, 就像在一个屏障上凿开了一个洞.
当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据, 由于魂村过期, 会同时访问数据库来查询最新数据, 并且回写缓存, 会导致数据库瞬间压力过大.
>**解决方案**
**设置热点数据永不过期**
从缓存层面来看, 没有设置过期时间,所以不会出现热点key过期后产生的问题.
**加互斥锁**
分布式锁: 使用分布式锁,保证对于每个key 同时只有一个线程去查询后端服务, 其他线程没有获得分布式锁的权限, 因此只需要等待即可. 这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大.
### 3、缓存雪崩
缓存雪崩, 是指在摸一个时间段, 缓存集中过期失效. Redis宕机!
产生雪崩的原因之一, 比如马上就要到双十二零点 , 很快就会迎来一波抢购, 这波商品时间比较集中的放入了缓存,假设缓存一个小时,那么到了凌晨一点中的时候, 这批商品的缓存就都过期了. 而对这批商品的访问查询,都落到了数据库上, 对于数据库而言, 就会产生周期性的压力波峰. 于是所有的请求都会到达存储层, 存储层的调用量会暴增, 造成存储层也会挂掉的情况.
其实集中过期, 倒不是非常致命的, 比较致命的缓存雪崩, 是缓存服务器某个节点宕机或断网 . 因为自然形成的缓存雪崩, 一定是在某个时间段集中创建缓存, 这个时候 , 数据库也是可以顶住压力的. 无非就是对数据库数据库产生周期性的压力而已. 而缓存服务节点的宕机, 对数据库服务器造成的压力是不可遇见的. 很有可能瞬间就把数据库压垮的.
> **解决方案**
**redis高可用**
这个思想的含义是, 既然redis有可能挂掉, 那我多增设几台redis,这样一台挂掉之后其他的还可以继续工作,其实就是搭建的集群. (异地多活!)
**限流降级**
这个解决方案的思想是, 在缓存失效后 , 通过枷锁或者队列来控制读数据库写缓存的线程数量. 比如对某个key只允许一个线程查询数据和写缓存, 其他线程等待.
**数据预热**
数据加热的含义就是在正式部署前, 我先把可能的数据预先访问一遍, 这样可能大量访问的数据就会加载到缓存中. 在即将发生大并发访问前手动触发加载不同的key , 设置不同的过期时间, 让缓存失效的时间点尽量均匀.