redis

西南方向
92 阅读50分钟

@TOC

感谢狂神的分享：B站视频地址

推荐网站：c.biancheng.net/redis/

推荐网站：RUNOOM.COM Redis教程

1. NoSql 概述

推荐文章：阿里云的这群疯子

数据库分类

  • 关系型数据库：列+行，同一个表下数据的结构是一样的。
  • 非关系型数据库：数据存储没有固定的格式，并且可以进行横向扩展。

什么是 NoSQL

Not Only SQL ：Not Only Structured Query Language

NoSQL泛指非关系型数据库。随着web2.0互联网的诞生，传统的关系型数据库很难对付web2.0时代！尤其是超大规模的高并发的社区，暴露出来很多难以克服的问题，NoSQL在当今大数据环境下发展的十分迅速，Redis是发展最快的。

Nosql 特点

  1. 方便扩展（数据之间没有关系，很好扩展！）
  2. 大数据量高性能（Redis 1秒 写8万次，读11万次。NoSQL的缓存记录级，是一种细粒度的缓存，性能会比较高！）
  3. 数据类型是多样型的！（不需要事先设计数据库，随取随用）
  4. 传统的 RDBMS 和 NoSQL
传统的 RDBMS(关系型数据库)
- 结构化组织、SQL
- 数据和关系都存在单独的表中 row col
- 操作，数据定义语言
- 严格的一致性
- 基础的事务

Nosql
- 不仅仅是数据
- 没有固定的查询语言
- 键值对存储，列存储，文档存储，图形数据库（社交关系）
- 最终一致性
- CAP定理 和 BASE（异地多活）
- 高性能，高可用，高扩展

3V + 3高

  • 大数据时代的3V ：主要是描述问题的
    • 海量 Velume
    • 多样 Variety
    • 实时 Velocity
  • 大数据时代的3高 ： 主要是对程序的要求
    • 高并发
    • 高可扩
    • 高性能 真正在公司中的实践：NoSQL + RDBMS 一起使用才是最强的。

NoSql 四大分类

  • KV 键值对
    • 新浪：Redis
    • 美团：Redis + Tair
    • 阿里、百度：Redis + Memcache
  • 文档型数据库（bson数据格式）
    • MongoDB
      • 基于分布式文件存储的数据库。C++编写，用于处理大量文档。
      • MongoDB是RDBMS和NoSQL的中间产品。MongoDB是非关系型数据库中功能最丰富、最像关系型数据库的数据库。
    • ConthDB
  • 列存储数据库
    • HBase(大数据必学)
    • 分布式文件系统
  • 图关系数据库
    • Neo4j、InfoGrid
分类Examples举例典型应用场景数据模型优点缺点
K--V键值对Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等Key 指向 Value 的键值对，通常用hash table来实现查找速度快数据无结构化，通常只被当作字符串或者二进制数据
列存储数据库Cassandra, HBase, Riak分布式的文件系统以列簇式存储，将同一列数据存在一起查找速度快，可扩展性强，更容易进行分布式扩展功能相对局限
文档型数据库CouchDB, MongoDbWeb应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）Key-Value对应的键值对，Value为结构化数据数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构查询性能不高，而且缺乏统一的查询语法。
图形(Graph)数据库Neo4J, InfoGrid, Infinite Graph社交网络，推荐系统等。专注于构建关系图谱图结构利用图结构相关算法。比如最短路径寻址，N度关系查找等很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群

2. Redis入门

2.1 概述

什么是 Redis

  • Redis（Remote Dictionary Server )，即远程字典服务。是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
  • Redis 是一个高性能的key-value数据库，与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 能干什么

  1. 内存存储、持久化，内存是断电即失的，所以需要持久化（RDB、AOF）
  2. 高效率、用于高速缓冲
  3. 发布订阅系统
  4. 地图信息分析
  5. 计时器、计数器(eg：浏览量)

特性

  1. 多样的数据类型
  2. 持久化
  3. 集群
  4. 事务

2.2 环境搭建

官网：redis.io/ 中文网：www.redis.cn/ github地址：github.com/dmajkic/red… windows版下载地址：github.com/MicrosoftAr…

windows 环境安装

下载windows版压缩包，直接解压： ![在这里插入图片描述](img-blog.csdnimg.cn/ba1c8cfefad… =500x) 测试启动与连接：

Linux 环境安装

英文官网：redis.io

Windows下使用确实简单，但Redis官方推荐使用Linux开发。官方不支持Windows版本的Redis，微软开发和维护着支持win-64的Redis版本，但是现在也没怎么维护了，Redis推荐都是在Linux服务器上搭建的。

  1. 下载安装包 ![在这里插入图片描述](img-blog.csdnimg.cn/48fa2c0ae86… =600x) 在这里插入图片描述
  2. 解压缩并安装
# 解压缩
tar redis-7.0.5.tar.gz

# 安装 C++ 环境
yum install gcc-c++

# 查看C的版本
gcc -v

# 使用make命令安装
make

# 确认安装信息
make install

# 软件的默认安装路径(类似Windows的 Program Files)
/usr/local/bin

安装好之后，进入 /usr/local/bin 目录，查看文件： 在这里插入图片描述

  1. 复制Redis配置文件，并修改为后台启动
cp /home/ide/redis-7.0.5/redis.conf /usr/local/bin/xinanConfig/

在这里插入图片描述

  1. 启动服务端和客户端，并测试连接
# -h  地址     -p 端口
redis-cli -h localhost -p 6379 (-h)

在这里插入图片描述 6. 关闭Redis服务

shutdown  关闭redis
然后到未连接状态，直接exit退出即可
然后可以再次查看进程是否存在

在这里插入图片描述

2.3 压力测试

redis-benchmark 是一个官方自带的性能测试工具，参数如下： ![redis-benchmark命令参数！](img-blog.csdnimg.cn/7c9bf89a9ff… =500x) 简单测试一下：

# 测试：100个并发连接  100000请求
redis-benchmark -h localhost -p 6379 -c 100 -n 100000
  • 以SET为例，分析测试的效果： 在这里插入图片描述

2.4 Redis基本知识

redis默认有16个数据库： 在这里插入图片描述

Redis是单线程的

官方表示，Redis是基于内存操作，CPU不是Redis性能瓶颈。Redis的瓶颈是机器的内存和网络带宽，既然可以使用单线程来实现，就使用单线程了！

Redis是C语言写的，官方提供的数据为100000+的QPS，完全不比同样使用key-vale的Memecache差！

Redis为什么单线程还这么快？

  1. 误区1：高性能的服务器一定是多线程的？ 答：不一定

  2. 误区2：多线程（CPU上下文会切换！）一定比单线程效率高r！ ​ 多线程有弊端，跟CPU调度有关。CPU会上下文切换，也会耗费资源。 ​ CPU速度 > 内存 > 硬盘

核心：redis是将所有的数据全部放在内存中的，所以说使用单线程去操作效率就是最高的。因为多线程CPU会上下文切换，这是一个耗时的操作！！！对于内存系统来说，如果没有上下文切换，效率就是最高的。多次读写都是在一个CPU上的，在内存情况下，这个就是最佳的方案。

​ CPU切换一般在1500~2500纳秒之间。

3. 五大数据类型

官方文档

在这里插入图片描述 Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 与范围查询， bitmaps， hyperloglogs 和 地理空间（geospatial） 索引半径查询。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动 分区（Cluster）提供高可用性（high availability）。

select 3  # 切换到第三个数据库

DBSIZE  # 查看数据库的大小

keys *  # 查看当前数据库所有的key

set key value  # 设置key

get key  # 获得value

flushdb  # 清空当前数据库的所有key

flushall  # 清空整个 Redis 数据(删除所有数据库的所有 key)

exists key  # 查看当前key是否存在

move key db  # 移动当前的key到其他数据库

expire key 10：设置10秒后 key 自动失效

ttl key  # 查看key还有多久自动过期

type key   # 查看当前key的值的数据类型

-------------------------------------------------------------
127.0.0.1:6379> set age 29
OK
127.0.0.1:6379> keys *   		# 查看数据库中的key
1) "name"
2) "age"
127.0.0.1:6379> move age 1		# 移动到1号数据库
(integer) 1
127.0.0.1:6379> exists age		# 查看当前数据库，是否还存在 age
(integer) 0
127.0.0.1:6379> select 1		# 切换到 1 号数据库
OK
127.0.0.1:6379[1]> exists age	# age存在1号数据库
(integer) 1
127.0.0.1:6379[1]> del age		# 删除 age
-------------------------------------------------------------
127.0.0.1:6379[1]> set age 29
OK
127.0.0.1:6379[1]> ttl age		# 未设置过期时间，返回 -1
(integer) -1
127.0.0.1:6379[1]> expire age 30	# 设置 age 在30s后过期
(integer) 1
127.0.0.1:6379[1]> ttl age		# 设置过期时间但未过期，返回到期时间倒计时	
(integer) 27
127.0.0.1:6379[1]> ttl age		# 设置过期时间且已过期，返回 -2
(integer) -2
127.0.0.1:6379[1]> get age		# 过期的key会被自动删除
(nil)
-------------------------------------------------------------
127.0.0.1:6379> type name		# 查看key对应value的数据类型
string

String（字符串）

命令描述举例
APPEND key value向指定的key的value后，追加字符串127.0.0.1:6379>set msg hello
127.0.0.1:6379> append msg ,world
127.0.0.1:6379> get msg
"hello,world"
DECR/INCR key将指定key的value数值进行+1/-1(仅对于数字)127.0.0.1:6379> set age 29
127.0.0.1:6379> incr age
(integer) 30
127.0.0.1:6379> decr age
(integer) 29
INCRBY/DECRBY key n按指定的步长，对数值进行加减127.0.0.1:6379> incrby age 5
(integer) 34
127.0.0.1:6379> decrby age 3
(integer) 31
INCRBYFLOAT key n为数值加上浮点型数值127.0.0.1:6379> incrbyfloat age 3.5
"34.5"
STRLEN key获取对应value值的字符串长度127.0.0.1:6379> strlen msg
(integer) 11
GETRANGE key start end按起止位置获取字符串（闭区间，起止位置都取）127.0.0.1:6379> getrange msg 1 4
"ello"
SETRANGE key offset value用指定的value 替换key中 offset开始的值127.0.0.1:6379> setrange msg 2 xxx
127.0.0.1:6379> get msg
"hexxx,world"
GETSET key value将给定 key 的值设为 value ，并返回 key 的旧值(旧值不存在则返回nil)127.0.0.1:6379> getset newmsg hello
(nil)
127.0.0.1:6379> getset newmsg world
"hello"
SETNX key value仅当key不存在时进行set127.0.0.1:6379> setnx newmsg xinan
(integer) 0
127.0.0.1:6379> setnx newsmg2 xinan
(integer) 1
SETEX key seconds valueset 键值对并设置过期时间127.0.0.1:6379> setex newmsg 10 wangxinan
127.0.0.1:6379> ttl newmsg
(integer) 7
MSET key1 value1 [key2 value2..]批量set键值对127.0.0.1:6379> mset key1 hello key2 world
MSETNX key1 value1 [key2 value2..]批量设置键值对，仅当参数中所有的key都不存在时执行127.0.0.1:6379> msetnx key1 hi key3 nihao
(integer) 0
MGET key1 [key2..]批量获取多个key保存的值127.0.0.1:6379> mget key1 key2
1) "hello"
2) "world"
PSETEX key milliseconds value和 SETEX 命令相似，但它以毫秒为单位设置 key 的生存时间psetex key3 15500 hi

List（列表）

  • Redis列表是简单的字符串列表，按照插入顺序排序。可以从列表的头部（左边）或者尾部（右边）添加、获取、删除 一个元素
  • 一个列表最多可以包含 2^32 - 1 个元素 (4294967295, 每个列表超过40亿个元素)。
  • 在redis里面，我们可以把list玩成，栈、队列、阻塞队列！
    • 一端进一端出：队列
    • 只能一端进出：栈
    • 两边都打开都能同时取：阻塞队列

在这里插入图片描述 如图Redis中List是可以进行双端操作的，所以命令也就分为了 Lxxx 和 Rxxx 两类，有时候L也表示List例如LLEN

命令描述
LPUSH/RPUSH key value1[value2..]从 左边/右边 向列表中PUSH值(一个或者多个)。
LRANGE key start end根据索引获取list 元素 ==（索引从左往右 递增）==
LPUSHX / RPUSHX key value向 已存在的list 中push值（一个或者多个）
LINDEX key index通过索引获取列表中的元素
LINSERT key BEFORE / AFTER pivot value在 list 的第一个 pivot 元素 前或后 插入元素
LLEN key查看列表长度
LINDEX key index通过索引获取列表元素
LSET key index value通过索引为元素设值
LPOP/RPOP key从 左边/右边 移除值 并返回
BLPOP / BRPOP key1 [key2 ] timeout与LPOP/RPOP功能类似； 如果列表没有元素，会阻塞列表直到等待超时或发现可弹出元素为止
RPOPLPUSH source destination移除列表的最后一个元素，并将该元素添加到另一个列表并返回
BRPOPLPUSH source destination timeout与RPOPLPUSH功能类似；如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止
LTRIM key start end通过下标截取指定范围内的列表
LREM key count value根据 COUNT 的值，移除列表中值为 VALUE 的元素
count > 0 : 从表头开始搜索，移除count 个 value
count < 0 : 从表尾开始搜索，移除count 个 value
count = 0 ：移除列表中所有的 value
-------------------LPUSH---RPUSH---LRANGE-----------------------
127.0.0.1:6379> lpush mylist k1		# 从左侧放入
(integer) 1
127.0.0.1:6379> lpush mylist k2
(integer) 2
127.0.0.1:6379> lpush mylist k3
(integer) 3
127.0.0.1:6379> lrange mylist 0 1  # 根据起始位置，获取列表元素（get无法获取列表）
1) "k3"
2) "k2"
127.0.0.1:6379>
127.0.0.1:6379> lrange mylist 0 -1		# 获取所有元素
1) "k3"
2) "k2"
3) "k1"
127.0.0.1:6379> rpush mylist k0			# 从右侧放入元素
(integer) 4
127.0.0.1:6379> lrange mylist 0 -1		# 查看元素列表
1) "k3"
2) "k2"
3) "k1"
4) "k0"
-------------------------LPUSHX---RPUSHX------------------------
127.0.0.1:6379> lpushx newlist one
(integer) 0
127.0.0.1:6379> lrange newlist 0 -1
(empty array)
------------------LINDEX---LSET---LINSERT---LLEN--------------------
127.0.0.1:6379> lindex mylist 2		# 根据索引获取值
"k1"
127.0.0.1:6379> lset mylist 2 newK1		# 根据索引设置值	
OK
127.0.0.1:6379> lrange mylist 0 -1		# 获取列表，k1 已替换为 newK1
1) "k3"
2) "k2"
3) "newK1"
4) "k0"

127.0.0.1:6379> linsert mylist before newK1 hello	# 在newK1前插入hello
(integer) 5
127.0.0.1:6379> lrange mylist 0 -1
1) "k3"
2) "k2"
3) "hello"
4) "newK1"
5) "k0"
127.0.0.1:6379> llen mylist		# 查看 mylist 长度
(integer) 5
-------------------------LPOP---RPOP------------------------
127.0.0.1:6379> lpop mylist
"k3"
127.0.0.1:6379> rpop mylist
"k0"
---------------------------RPOPLPUSH--------------------------
127.0.0.1:6379> lrange mylist 0 -1
1) "k2"
2) "hello"
3) "newK1"
127.0.0.1:6379> rpoplpush mylist newMyList	# 将mylist最右侧一个元素，放入newMyList
"newK1"
127.0.0.1:6379> lrange mylist 0 -1
1) "k2"
2) "hello"
127.0.0.1:6379> lrange newMyList 0 -1
1) "newK1"
-----------------------------LTRIM----------------------------
127.0.0.1:6379> lrange mylist 0 -1
1) "k2"
2) "hello"
3) "world"
127.0.0.1:6379> ltrim mylist 0 1	 # 根据索引，截取保留元素
OK
127.0.0.1:6379> lrange mylist 0 -1
1) "k2"
2) "hello"
------------------------------LREM-----------------------------
# 初始 mylist: k2,k2,k2,k2,k2,k2,k4,k2,k2,k2,k2

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)

应用：

  • 消息队列（Lpush Rpop），栈（Lpush Lpop）

Hash（哈希）

  • hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，特别适合用于存储对象。
  • Redis 中每个 hash 可以存储 2^32 - 1 键值对（40多亿）。
命令描述
HSET key field value将哈希表 key 中的字段 field 的值设为 value 。重复设置同一个field会覆盖，返回0
HMSET key field1 value1 [field2 value2..]同时将多个 field-value (域-值)对设置到哈希表 key 中
HSETNX key field value只有在字段 field 不存在时，设置哈希表字段的值
HEXISTS key field查看哈希表 key 中，指定的字段是否存在
HLEN key获取哈希表中字段的数量
HGET key field value获取存储在哈希表中指定字段的值
HMGET key field1 [field2..]获取所有给定字段的值
HGETALL key获取在哈希表key 的所有字段和值
HKEYS key获取哈希表key中所有的字段
HVALS key获取哈希表中所有值
HDEL key field1 [field2..]删除哈希表key中一个/多个field字段
HINCRBY key field n为哈希表 key 中 field 的整数值加上 increment
增量可为负数，做减法操作
如果field对应的值不存在，则初始化为0
HINCRBYFLOAT key field n为 field 对应的浮点数值加上 increment
HSCAN key cursor [MATCH pattern] [COUNT count]迭代哈希表中的键值对

Set（无序集合）

  • Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，集合对象的编码可以是 intset 或者 hashtable。
  • Redis 中 Set 是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
  • 集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储40多亿个成员)。
命令描述
SADD key member1[member2..]向无序集合中增加 一个/多个 成员
SCARD key获取集合的成员数
SMEMBERS key返回集合中所有的成员
SRANDMEMBER key [count]随机返回集合中count个成员，count缺省值为1
SISMEMBER key member查询member元素是否是集合的成员，结果是无序的
SREM key member1[member2..]移除集合中一个/多个成员
SPOP key移除并返回集合中的一个随机元素
SMOVE source destination member将source集合的成员member移动到destination集合
SDIFF key1[key2..]返回第一个集合与其他集合之间的差异，也就是 key1 中独有的元素
SDIFFSTORE destination key1[key2..]在SDIFF的基础上，将结果保存到集合中(==覆盖==)。不能保存到其他类型key噢！
SINTER key1 [key2]返回给定所有集合的交集
SINTERSTORE destination key1 [key2]在SINTER的基础上，将结果保存到 destination
SUNION key1 [key2..]返回所有集合的并集
SUNIONSTORE destination key1 [key2..]在SUNION的基础上，存储结果到destination 。覆盖
SSCAN KEY cursor [MATCH pattern] [COUNT count]在大量数据环境下，使用此命令遍历集合中元素，每次遍历部分：
cursor - 游标
pattern - 匹配的模式
count - 指定从数据集里返回多少元素，默认值为 10 。

ZSet（有序集合）

  • ZSet 也是 string 类型元素的集合，且每个元素都会关联一个 double 类型的分数。通过 score 来从小到大排序
  • Zset 中成员是唯一的，但分数(score)却可以重复
  • 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。 集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储40多亿个成员)。
命令描述
Zadd key score member1 [score2 member2]向有序集合添加一个或多个成员，或者更新已存在成员的分数
Zcard key获取有序集合的成员总数
Zcount key min max计算 ZSet 中score在指定区间的成员个数
Zincrby key n member对指定成员的 score 增加 n（n 可以为负数）
ZScore key member返回指定成员的score
ZRANK key member返回指定成员的索引
Zrange key start end通过索引区间，返回有序集合指定区间内的成员，按分数值递增(从小到大)排序
ZRangeByLEX key min max通过字典区间，返回有序集合的成员
ZRangeByScore key min max返回指定分数区间的成员列表，==-inf +inf== 代表负无穷与正无穷
Zrangebyscore zset (1 5 ：返回 1 < score <= 5 的成员
Zrangebyscore zset (5 (10 ：则 5 < score < 10 的成员
Zinterstore destination numkeys key [key ...]计算给定的一个或多个有序集的交集，并将结果集存储在 destination 中
ZLexCount key min max计算指定字典区间内成员数量
ZRem key member1 [member2..]移除一个/多个成员
ZRemRangeByLex key min max移除给定的字典区间的所有成员
ZRemRangeByRank key start stop移除给定的排名区间，内的所有成员
ZRemRangeByScore key min max移除给定的分数区间，内的所有成员
ZRevRange key start end返回指定区间内的成员，通过索引、分数从高到底
ZRevRangeByScore key max min返回指定分数区间内的成员，分数从高到低排序
ZRevRangeByLex key max min返回指定字典区间内的成员，按字典顺序倒序
ZRevRank key member返回指定成员的排名，按分数值递减(从大到小)排序
ZInterStore destination numkeys key1 [key2 ..]计算一个或多个有序集的交集，并将结果集存储在destination 的 key 中；
numkeys：表示参与运算的集合数，将score相加作为结果的score
ZUnionStore destination numkeys key1 [key2..]计算一个或多个有序集的交集，并将结果集存储在 destination 中
ZScan key cursor [MATCH pattern\] [COUNT count]迭代有序集合中的元素（包括元素成员和元素分值）

4. 三种特殊数据类型

geospatial（地理位置）

使用经纬度定位地理坐标并用一个有序集合zset保存，所以zset命令也可以使用

命令描述
geoadd key longitud(经度) latitude(纬度) member [..]存入将具体经纬度的坐标
geopos key member [member..]获取集合中的 一个/多个 成员坐标
geodist key member1 member2 [unit]返回两个给定位置之间的距离（默认单位：米）
georadius key longitude latitude radius m根据用户给定的经纬度，获取指定范围内的地理位置集合
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个(按距离递增排序)
# getadd 添加地理位置
# 参数 key 值(纬度、经度、名称)
127.0.0.1:6379> geoadd china:city 116.40 39.90 beijing
(integer) 1
127.0.0.1:6379> geoadd china:city 121.47 31.23 shanghai 106.50 29.53 chongqing
(integer) 2
127.0.0.1:6379> geoadd china:city 120.16 30.24 hangzhou 108.96 34.26 xian 114.05 22.52 shenzhen
(integer) 3

#  获取指定地点的坐标
127.0.0.1:6379> geopos china:city beijing shanghai
1) 1) "116.39999896287918091"
   2) "39.90000009167092543"
2) 1) "121.47000163793563843"
   2) "31.22999903975783553"

# 获取两地距离
127.0.0.1:6379> geodist china:city beijing shanghai
"1067378.7564"
127.0.0.1:6379> geodist china:city beijing shanghai km
"1067.3788"
127.0.0.1:6379> 

# georadius 以给定的经纬度为中心，找出某一半径内的元素
127.0.0.1:6379> georadius china:city 110 30 500 km 	# 获取500km内的城市
1) "chongqing"
2) "xian"
127.0.0.1:6379> georadius china:city 110 30 500 km count 1	# 只获取一个
1) "chongqing"

127.0.0.1:6379> georadius china:city 110 30 500 km withcoord  # 带经纬度
1) 1) "chongqing"
   2) 1) "106.49999767541885376"
      2) "29.52999957900659211"
2) 1) "xian"
   2) 1) "108.96000176668167114"
      2) "34.25999964418929977"

# 根据元素，获取半径内的城市
127.0.0.1:6379> georadiusbymember china:city shanghai 200 Km 
1) "hangzhou"
2) "shanghai"

# Geohash 命令 - 返回一个或多个位置元素的 Geohash 表示
(距离越近，字符串越相似)
127.0.0.1:6379> geohash china:city shanghai hangzhou beijing
1) "wtw3sj5zbj0"
2) "wtmkn31bfb0"
3) "wx4fbxxfke0"

GEO 底层的实现原理：Zset！ 我们可以用Zset命令来操作Geo

# 查询所有元素
127.0.0.1:6379> zrange china:city 0 -1
1) "chongqing"
2) "xian"
3) "shenzhen"
4) "hangzhou"
5) "shanghai"
6) "beijing"
127.0.0.1:6379> zrem china:city xian	# 移除元素
(integer) 1

Hyperloglog（基数统计）

Redis HyperLogLog 是用来做基数统计的算法，优点是在元素的数量或者体积非常非常大时，计算基数所需只花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。 因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。 其底层实现是 string

  • 基数：数据集中不重复的元素的个数
  • 应用场景：网页的访问量（UV）。一个用户多次访问，也只能算作一个人。
命令描述
PFADD key element1 [elememt2..]添加指定元素到 HyperLogLog 中
PFCOUNT key [key]返回给定 HyperLogLog 的基数估算值
PFMERGE destkey sourcekey [sourcekey..]将多个 HyperLogLog 合并为一个 HyperLogLog
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
string
127.0.0.1:6379> PFCOUNT 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
127.0.0.1:6379> pfcount myelemx myelemy
(integer) 17
127.0.0.1:6379> pfmerge myelemz myelemx myelemy
OK

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 4 # 未设置默认是0
(integer) 0
-----------bitcount----------------------------
127.0.0.1:6379> BITCOUNT sign # 统计sign中为1的位数
(integer) 4

5. 事务

Redis的单条命令是保证原子性的，==但是redis事务不能保证原子性，也没有隔离级别概念。==

Redis 事务的本质：一组按顺序执行的命令的集合 事务中每条命令都会被序列化，执行过程中按顺序执行，不允许其他命令进行干扰。

  • 一次性
  • 顺序性
  • 排他性

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"
  • 放弃事务（discard）
127.0.0.1:6379> multi		# 开启事务
OK
127.0.0.1:6379> set k1 v1
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)

事务出错

代码语法错误（编译时异常）所有的命令都不执行

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事务不能保证原子性。

监控

  • 悲观锁：
    • 很悲观，认为什么时候都会出现问题，无论做什么都会加锁
  • 乐观锁：
    • 很乐观，认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，在此期间是否有人修改过这个数据
    • 获取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		# 余额减少20
QUEUED
127.0.0.1:6379> INCRBY use 20		# 支出增加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> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> 				# 此时事务并没有执行
  1. 线程二：
127.0.0.1:6379> INCRBY money 500 # 修改了线程一中监视的money
(integer) 600
  1. 回到线程一，执行事务：
127.0.0.1:6379> EXEC 	# 执行之前，线程二修改了money的值，就会导致事务执行失败
(nil) # 没有结果，说明事务执行失败

127.0.0.1:6379> get money # 线程2 修改生效
"600"
127.0.0.1:6379> get use # 线程1事务执行失败，数值没有被修改
"0"
  • 解锁获取最新值，然后再加锁进行事务。unwatch 进行解锁。

【注意】：每次提交执行exec后都会自动释放锁，不管是否成功。

6. java连接Redis

Jedis

  1. 注释掉限制本地ip访问 在这里插入图片描述
  2. 将保护模式改成 no 在这里插入图片描述3. 开启防火墙Redis端口：
# 启动防火墙：
systemctl start firewalld.service

# 添加防火墙端口
firewall-cmd --zone=public --add-port=6379/tcp --permanent

# 重启防火墙
systemctl restart firewalld.service

# 查看所有开启的端口。如果是阿里云，需要配置安全组规则
firewall-cmd --list-ports

# 重启Redis服务
redis-server xinanConfig/redis.conf

  1. 设置阿里云安全组

  2. 测试连接

public class TestPing {
    public static void main(String[] args) {
        Jedis jedis = new Jedis("39.104.xx.xxx", 6379);
        String response = jedis.ping();
        System.out.println(response); // PONG
    }
}
  1. 测试事务
public static void main(String[] args) {
    Jedis jedis = new Jedis("39.99.xxx.xx", 6379);

    JSONObject jsonObject = new JSONObject();
    jsonObject.put("hello", "world");
    jsonObject.put("name", "kuangshen");
    // 开启事务
    Transaction multi = jedis.multi();
    String result = jsonObject.toJSONString();
    // jedis.watch(result)
    try {
        multi.set("user1", result);
        multi.set("user2", result);
        // 执行事务
        multi.exec();
    }catch (Exception e){
        // 放弃事务
        multi.discard();
    } finally {
        // 关闭连接
        System.out.println(jedis.get("user1"));
        System.out.println(jedis.get("user2"));
        jedis.close();
    }
}

SpringBoot整合Redis

  1. 导入依赖
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

springboot 2.x后 ，原来使用的 Jedis 被 lettuce 替换。

jedis：采用的直连，多线程操作不安全。如果要避免不安全，使用jedis pool连接池！更像BIO模式 lettuce：采用netty，实例可以在多个线程中共享，不存在线程不安全的情况！可以减少线程数据了，更像NIO模式

根据SpringBoot自动配置的原理，整合一个组件并进行配置一定会有一个自动配置类xxxAutoConfiguration，并且在spring.factories中也一定能找到这个类的完全限定名。Redis也不例外。 在这里插入图片描述 那么就一定还存在一个RedisProperties类： 在这里插入图片描述 之前说SpringBoot2.x后默认使用Lettuce来替换Jedis，现在验证一下：

  • 先看Jedis: 在这里插入图片描述
  • 然后再看Lettuce 在这里插入图片描述
  • 再回到RedisAutoConfiguratio，只创建并返回了两个bean：
    • RedisTemplate
    • StringRedisTemplate
@AutoConfiguration
@ConditionalOnClass(RedisOperations.class)
@EnableConfigurationProperties(RedisProperties.class)
@Import({ LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class })
public class RedisAutoConfiguration {
	@Bean
	@ConditionalOnMissingBean(name = "redisTemplate")
	@ConditionalOnSingleCandidate(RedisConnectionFactory.class)
	// 默认的RedisTemplate 并没有过多的设置
	// 泛型的两个参数是<Object,Object>，后续自定义设置成<String,Object>
	public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
		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);
	}
}

当看到xxTemplate时可以对比RestTemplat、SqlSessionTemplate，通过使用这些Template来间接操作组件。这俩分别用于操作Redis 和 Redis中的String数据类型。 在RedisTemplate上也有一个条件注解@ConditionalOnMissingBean(name = "redisTemplate")，说明我们是可以对其进行定制化的

  • 阅读RedisProperties，查看可以配置的属性： 在这里插入图片描述 在这里插入图片描述
  1. 使用RedisTemplate
    • 编写配置文件
    • 测试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"));
    }
}
  1. 测试结果：
    • 可以正常设置和获取key，但在Redis客户端中key是乱码的： 在这里插入图片描述
    • 这就牵涉到序列化问题，源码中的序列化设置如下： 在这里插入图片描述 在这里插入图片描述
@Test
void testUser() throws JsonProcessingException {
    User user = new User("xinan", 29);

    // 如果设置序列化之后的对象，可以正常存储
    //String userStr = new ObjectMapper().writeValueAsString(user);
    //redisTemplate.opsForValue().set("user1",userStr);

    // 直接传输未序列化的对象，报错 SerializationException
    redisTemplate.opsForValue().set("user1",user);
    Object user1 = redisTemplate.opsForValue().get("user1");
    System.out.println(user1);
}
  1. 自定义RedisTemplate类，设置序列化方式
@Configuration
public class RedisConfig {
    @Bean
    // @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 将泛型改为 <String, Object>
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        // 连接工厂，不必修改
        template.setConnectionFactory(redisConnectionFactory);
        // --------------------- 序列化设置 ---------------------
        // key、hash的key 采用 String序列化方式
        template.setKeySerializer(RedisSerializer.string());
        template.setHashKeySerializer(RedisSerializer.string());
        // value、hash的value 采用 Jackson 序列化方式
        template.setValueSerializer(RedisSerializer.json());
        template.setHashValueSerializer(RedisSerializer.json());
        template.afterPropertiesSet();
        return template;
    }
}

自定义工具类

使用RedisTemplate需要频繁调用 .opForxxx() 然后才能进行对应的操作，这样使用起来代码效率低下，工作中将这些常用的公共API抽取出来，封装成为一个工具类，然后直接使用工具类来间接操作Redis，效率高并且易用。

7. redis.conf

  • 内存大小设置 在这里插入图片描述
  • 导入组合其他配置文件（Include） 在这里插入图片描述
  • 网络（network）
bind node1  			# 绑定的ip
protected-mode yes   	# 保护模式 默认开启
port 6379 				# 端口设置
  • 通用设置（general）
daemonize yes 		# 以守护进程的方式运行 默认no  我们需要手动修改yes ！

pidfile /var/run/redis_6379.pid 	# 如果以后台的方式运行，我们就需要指定一个pid文件

# 日志
# Specify the server verbosity level.
# This can be one of:
	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)
loglevel notice  	# 默认是 notice

logfile "" 			# 日志的文件位置名
databases 16 		# 数据库数量，默认16个
always-show-logo yes  # 是否总是显示logo  那个魔方一样的
  • 快照（SNAPSHOTTING）

持久化，在规定的时间内， 执行了多少次操作，就会持久化到文件.rdb 或 .aof redis是内存数据库，如果没有持久化，那么数据断电即失

#  save <指定时间间隔> <执行指定次数更新操作>

save 900 1  	# 如果900秒15分钟内 至少1个key修改 我们就进行持久化操作
save 300 10 	# 如果300秒5分钟内 至少10个key修改 我们就 进行持久化操作
save 60 10000 	# 如果60秒内 至少10000个key修改(高迸发) 进行持久化操作

stop-writes-on-bgsave-error yes # 持久化出错是否继续。默认 是！

rdbcompression yes 	# 是否压缩rdb文件，需要消耗cpu资源

rdbchecksum yes 	# 保存reb文件的时候，进行错误校验，错误的话修复

dbfilename dump.rdb		# 生成备份文件的名称

dir ./ 		# rdb文件保存的目录，默认当前目录下
  • 复制（REPLICATION） 在这里插入图片描述
  • 安全（SECURITY） 可以在这里设置redis密码，默认是没有密码的
# requirepass foobared  # 默认密码为空 如果需要设置123 : requirepass 123  
# 不过更多的用命令去设置密码：

node1:6379> config set requirepass "123456" # 设置密码123456
OK
node1:6379> config get requirepass  # 发现所有命令没权限了
(error) NOAUTH Authentication required.
node1:6379> ping
(error) NOAUTH Authentication required.
node1:6379> auth 123456  			# 使用密码进行登陆
OK
node1:6379> config get requirepass  # 获取redis密码
1) "requirepass"
2) "123456"
  • 客户端（CLIENTS）
maxclients 10000 # 设置能连接上redis的最大客户端的数量
maaxmemory <bytes> # redis 配置最大的内存容量
maxmemory-policy noeviction # 内存达到上限之后的处理策略
	||处理策略有以下6种
	1、volatile-lru：只对设置了过期时间的key进行LRU【默认】 
	2、allkeys-lru ： 删除lru算法的key   
	3、volatile-random：随机删除即将过期key   
	4、allkeys-random：随机删除   
	5、volatile-ttl ： 删除即将过期的   	
	6、noeviction ： 永不过期，返回错误

命令行设置内存处理策略：

node1:6379>  config set maxmemory-policy volatile-lru
  • APPEND ONLY 模式 aof 配置
appendonly no  # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof"  # 持久化的文件的名字

# appendfsync always  # 每次修改都会 sync 消耗性能
appendfsync everysec  # 每秒执行一次 sync，可能会丢失这一秒的数据
# appendfsync no      # 不执行 sync 操作系统自己同步数据，速度最快，但一般也不用。

8. 持久化

推荐博客：Redis的两种持久化RDB和AOF

RDB（Redis DataBases）

主从复制中，RDB是备用的，从机上面，不占用主机内存。（基本不使用AOF模式） ![在这里插入图片描述](img-blog.csdnimg.cn/18ece30c744… =400x) 在指定时间间隔后，将内存中的数据集快照写入数据库 ；在恢复时候，直接读取快照文件，进行数据的恢复。

  • 在进行 RDB 的时候，redis 的主线程是不会做 io 操作的，会 fork 一个子线程来完成该操作：

    1. Redis 调用forks创建子进程，同时拥有父进程和子进程；
    2. 子进程将数据集写入到一个临时 RDB 文件中；
    3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件

  • 整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

  • 在快照（SNAPSHOT）中设置rdb保存策略 在这里插入图片描述

  • 保存的dump.rdb文件如下： 在这里插入图片描述

触发机制

  • 在指定的时间间隔内，执行指定次数的写操作
  • 执行save（同步阻塞， 只管保存快照，其他的等待） 或bgsave （异步）命令
  • 执行flushall 命令，清空数据库所有数据（意义不大）。
  • 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据（意义不大）
命令savebgsave
IO类型同步异步
阻塞？是是（阻塞发生在fock()，通常非常快）
复杂度O(n)O(n)
优点不会消耗额外的内存不阻塞客户端命令
缺点阻塞客户端命令需要fock子进程，消耗内存

如何恢复rdb文件

  1. 只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据！
  2. 查看需要存在的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"  # 如果此目录下存在dump.rdb文件，启动就会自动恢复其中的数据

优缺点

  • 优点：
    • 适合大规模的数据恢复；
    • 如果业务对数据完整性和一致性要求不高，RDB是很好的选择
  • 缺点：
    • 1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
    • 2 备份时占用内存：因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍），最后再将临时文件替换之前的备份文件
    • 3 在 fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能

AOF（Append Only File）

将我们所有的命令都记录下来，（类似 Linux中 history），恢复的时候就把这个文件全部再执行一遍。

以日志的形式来记录每个写的操作（读操作不记录），只许追加文件但不可以改写文件。 redis启动之初会读取该文件重新构建数据。就是根据日志文件的内容，将写指令从前到后执行一次，以完成数据的恢复工作。

![在这里插入图片描述](img-blog.csdnimg.cn/f571064b161… =500x)

什么是AOF

快照功能（RDB）并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、以及未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

如果要使用AOF，需要修改配置文件：

appendonly no 	# 是否启用AOF（默认为no，如果开启设为 yes）默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用
appendfilename "appendonly.aof"		# 开启AOF后，保存的文件名称

# appendfsync always # 每次修改都会sync 消耗性能
appendfsync everysec # 每秒执行一次 sync 可能会丢失这一秒的数据
# appendfsync no # 不执行 sync ,这时候操作系统自己同步数据，速度最快

在这里插入图片描述

  • redis-check-aof ：aof文件修复工具： 如果这个aof文件有错误，这时候redis是启动不起来的，我们需要修复这个aof文件，使用工具 redis-check-aof --fix，步骤：
1.shutdown exit，	# 关闭redis服务端，退出客户端
2.删除datas/dump.rdb文件，因为里面有保存数据
3.vim appendonly.aof，肆意修改，并保存
4.尝试启动redis，登录cli的时候报错：
Could not connect to Redis at node1:6379: Connection refused

5.执行修复工具：redis-check-aof --fix ../datas/appendonly.aof

6.需要你确认，输入y，修复成功。Successfully truncated AOF
7.再次执行，如果aof文件正常，就会发现数据都恢复了

优缺点

  • 优点
    • 每一次修复都同步，文件的完整会更好
    • 每秒同步一次，可能会丢失一秒的数据
    • 从不同步，效率最高的
  • 缺点
    • 备份文件大小，aof远大于rdb，修复的速度也比rdb慢
    • Aof运行效率也要比rdb慢，所以redis默认的配置就是rdb持久化

总结

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

性能建议

  1. 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，且只要15分钟备份一次就够了（只保留 save 900 1 这条规则）。
  2. 如果 EnableAOF，好处 是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单（只load自己的AOF文件就可以了）；代价 一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
  3. 如果不Enable AOF，仅靠Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉（断电），会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构。

9. 发布订阅

  • Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。 在这里插入图片描述
  1. 下图展示了频道 channel1，以及订阅这个频道的三个客户端——client2、client5和client1之间的关系 在这里插入图片描述
  2. 当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端： 在这里插入图片描述
命令描述
SUBSCRIBE channel [channel ...]订阅给定的一个或多个频道的信息
UNSUBSCRIBE [channel [channel ...]]退订一个或多个的频道
PUBLISH channel message将信息发送到指定的频道
PUBSUB subcommand [argument [argument ...]]查看订阅与发布系统状态
PSUBSCRIBE pattern [pattern ...]订阅一个或多个，符合给定模式的频道
PUNSUBSCRIBE [pattern [pattern ...]]退订所有给定模式的频道
------------订阅端----------------------
127.0.0.1:6379> SUBSCRIBE xinan 		# 订阅xinan频道
Reading messages... (press Ctrl-C to quit) 	# 等待接收消息
1) "subscribe" # 订阅成功的消息
2) "xinan"
3) (integer) 1
1) "message" # 接收到来自sakura频道的消息 "hello world"
2) "xinan"
3) "hello world"
1) "message" # 接收到来自sakura频道的消息 "hello i am xinan"
2) "xinan"
3) "hello i am sakura"

--------------消息发布端-------------------
127.0.0.1:6379> PUBLISH sakura "hello world" # 发布消息到sakura频道
(integer) 1
127.0.0.1:6379> PUBLISH sakura "hello i am xinan" # 发布消息
(integer) 1

-----------------查看活跃的频道------------
127.0.0.1:6379> PUBSUB channels
1) "xinan"

原理

  • 每个 Redis 服务器进程，都维持着一个表示服务器状态的 redis.h/redisServer 结构， 其中 pubsub_channels 属性是一个字典， 用于保存订阅频道的信息；
  • 字典的键为被订阅的频道， 值则是一个链表， 保存了订阅这个频道的所有客户端：
  • 订阅，客户端就被链接到对应频道的链表的尾部；退订，则就是将客户端节点从链表中移除 在这里插入图片描述

缺点

  1. 如果一个客户端订阅了频道，但读取消息的速度却不够快，那么不断积压的消息，会使redis输出缓冲区的体积变得越来越大。这可能使 redis 速度变慢，甚至直接崩溃。
  2. 数据传输可靠性：如果订阅方掉线，那么他将会丢失所有在掉线期间，发布者发布的消息

应用

  1. 消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
  2. 多人在线聊天室（订阅同一个频道）

10. 主从复制

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（master / leader)，后者称为从节点(slave / follower)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

每台Redis服务器默认都是主节点。一个主节点可以有0个至多个从节点，但每个从节点只能有一个主节点

作用

  1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。
  2. 故障恢复：当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式
  3. 负载均衡：在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。
  4. 高可用基石：主从复制是哨兵、集群能够实施的基础（因此说主从复制是Redis高可用的基础）

为什么使用集群

  1. 从结构上：单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大
  2. 从容量上：单个Redis服务器内存容量有限，就算一台服务器内存为256G，也不能全部用作Redis存储内存。一般单台Redis最大使用内存不应该超过20G

集群环境配置

  • 查看当前redis的信息：info replication
127.0.0.1:6379> info replication
# Replication
role:master				# 角色（master 或 slave）
connected_slaves:0		# 连接的从机个数
master_failover_state:no-failover
master_replid:e9e8a8a9410e71f8e9d9ffb41e36f63051d3975e
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个窗口，复制3份 redis.conf文件

[root@node1 redis-3.2.8-bin]# cp redis.conf redis79.conf 
[root@node1 redis-3.2.8-bin]# cp redis.conf redis80.conf   
[root@node1 redis-3.2.8-bin]# cp redis.conf redis81.conf  

命令：vim redis79.conf
port 6379 		# 84行  端口这里不用改 本身这个文件就是79端口  
daemonize yes 	# 128行 后台运行 要yes
pidfile /var/run/redis_6379.pid 	# 150行 这里pid file 也没问题
logfile "redis6379.log" 	# 163行 logfile加上后缀6379
dbfilename dump6379.rdb 	# 236行 dump.rdb改成 dump6379.rdb 否则会重名

# 至此第一个就保存好了。
# 第二个文件对应的改成6380和6381
  • 一主二从配置 在这里插入图片描述
  • 查看主机的信息： 在这里插入图片描述
  • 上面是使用命令搭建，是暂时的，==真实开发中应该在从机的配置文件中进行配置==，这样的话是永久的。 在这里插入图片描述

使用规则

  1. 从机只能读不能写，主机可读可写但是多用于写
 127.0.0.1:6381> set name sakura # 从机6381写入失败
(error) READONLY You can't write against a read only replica.

127.0.0.1:6380> set name sakura # 从机6380写入失败
(error) READONLY You can't write against a read only replica.

127.0.0.1:6379> set name xinan
OK
127.0.0.1:6379> get name
"xinan"

  1. 当主机断电宕机后，默认情况下从机的角色不会发生变化 ，集群中只是失去了写操作；当主机恢复以后，又会连接上从机恢复原状

  2. 当从机断电宕机后，若不是使用配置文件配置的从机，再次启动后作为主机是无法获取之前主机的数据的，若此时重新配置称为从机，又可以获取到主机的所有数据。这里就要提到一个同步原理

  3. 第二条中提到，默认情况下，主机故障后，不会出现新的主机，有两种方式可以产生新的主机

    • 从机手动执行命令 slaveof no one，这样执行以后从机会独立出来成为一个主机
    • 使用哨兵模式（自动选举）

11. 哨兵模式

推荐博客：Redis哨兵（Sentinel）模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

  • 单哨兵模式： ![在这里插入图片描述](img-blog.csdnimg.cn/26564b12523… =360x)
  • 多哨兵模式： 一个哨兵进程对Redis服务器进行监控，可能会出现问题。为此，可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式 在这里插入图片描述

哨兵的作用：

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

故障切换（failover）的过程：假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线。这样对于客户端而言，一切都是透明的

复制原理

SIave成功连接master后会发送一个sync命令。Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令；在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

  • 全量复制：当slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。 主机set k1 v1，从机断开；主机set k2 v2，从机重新连接主机。全量复制，从机还可以get k2。

  • 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步 主机连接主机后，主机set k3 v3，从机可以get k3，这就是增量复制

只要slave重新连接master，一次完全同步（全量复制）将被自动执行。

测试

  1. 哨兵的核心配置
sentinel monitor mymaster 127.0.0.1 6379
  1. 启动哨兵进程
redis-sentinel xxx/sentinel.conf

在这里插入图片描述 3. 在新窗口下，关闭 6379 主机。稍等一会，哨兵开始选举新的主机： 在这里插入图片描述

  1. 如果原来的主机从新上线，也只能当新主机的从机

优缺点

  • 优点：
    • 哨兵集群，基于主从复制模式，所有主从复制的优点，它都有
    • 主从可以切换，故障可以转移，系统的可用性更好
    • 哨兵模式是主从模式的升级，手动到自动，更加健壮
  • 缺点：
    • Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦
    • 实现哨兵模式的配置其实是很麻烦的，里面有很多配置项

完整的哨兵配置

# Example sentinel.conf
 
# 哨兵sentinel实例运行的端口 默认26379
port 26379
 
# 哨兵sentinel的工作目录
dir /tmp
 
# 哨兵sentinel监控的redis主节点的 ip port 
# master-name  可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 1
 
# 当在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

12. 穿透与雪崩

缓存穿透（查不到）

概念

用户请求数据时，会先在缓存(Redis)中查找；若没找到即缓存未命中，再在数据库中进行查找。数量少可能问题不大，可是一旦大量的请求数据（例如秒杀场景）缓存都没有命中的话，就会全部转移到数据库上，造成数据库极大的压力，就有可能导致数据库崩溃。网络安全中也有人恶意使用这种手段进行攻击被称为洪水攻击。

解决方案

1、布隆过滤器

对所有可能查询的参数以Hash的形式存储，以便快速确定是否存在这个值，在控制层先进行拦截校验，校验不通过直接打回，减轻了存储系统的压力。 ![在这里插入图片描述](img-blog.csdnimg.cn/7162bf4a4ec… =300x) 2、缓存空对象 一次请求若在缓存和数据库中都没找到，就在缓存中放一个空对象，同时会设置一个过期时间。之后再访问这个数据将会从缓存中获取，保护了后端数据源 ![在这里插入图片描述](img-blog.csdnimg.cn/61e1e45fbf9… =300x)

  • 但是这种方法存在2个问题：
    • 1、存储空对象也需要空间，大量的空对象会耗费一定的空间，存储效率并不高。解决这个缺陷的方式就是设置较短过期时间
    • 2、即使对空值设置了过期时间，还是会存在 缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（访问量大，缓存过期）

概念

  • 相较于缓存穿透，缓存击穿的目的性更强。一个非常热点的存在的key，在缓存过期的一刻，持续大并发的访问就穿破缓存，直接访问DB。造成瞬时DB请求量大、压力骤增。
  • 这就是缓存被击穿，只是针对其中某个key的缓存不可用而导致击穿，但是其他的key依然可以使用缓存响应。
  • 例如：微博热搜，服务器宕机(60秒过期，60.1秒回复，这0.1秒的间隔 ==> 瞬间全部砸在mysql服务器上)

解决方案

1、设置热点数据永不过期

这样就不会出现热点数据过期的情况，但是当Redis内存空间满的时候也会清理部分数据，而且此种方案会占用空间，一旦热点数据多了起来，就会占用部分空间。

2、加互斥锁(分布式锁)

在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。保证同时刻只有一个线程访问。这样对锁的要求就十分高。

缓存雪崩

概念

大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。或者Redis宕机(停电了)！ ![在这里插入图片描述](img-blog.csdnimg.cn/d89a8168092… =500x) 其实集中过期，倒不是非常致命。比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的，无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

双十一：停掉一些服务（比如第二天才能退货退款），来保证主要的服务可用！

解决方案

redis高可用 既然 redis有可能挂掉，那我多增设几台 redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活！）

限流降级 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程査询数据和写缓存，其他线程等待。

数据预热 就是在正式部署之前，先把可能的数据先预先访问一遍。这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前，手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

avatar
文章
阅读
粉丝