Redis

最新推荐文章于 2022-11-17 20:34:32 发布

夜不过如此

最新推荐文章于 2022-11-17 20:34:32 发布

阅读量196

点赞数

分类专栏： java 文章标签： redis

本文链接：https://blog.csdn.net/qq_43517448/article/details/111145247

版权

java 专栏收录该内容

37 篇文章 1 订阅

订阅专栏

Redis：

1.学习目标：

在这里插入图片描述

2. Redis的介绍

2.1. Redis是什么？

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）

2.2. 性能

下面是官方的bench-mark数据：

测试完成了50个并发执行100000个请求。

设置和获取的值是一个256字节字符串。

结果:读的速度是110000次/s,写的速度是81000次/s

2.3. 支持的数据类型

string 、 hash 、 list 、 set 、 sorted set

3. 关系型数据库与非关系型数据库

3.1. 关系型数据库

采用关系模型来组织数据的数据库，关系模型就是二维表格模型。一张二维表的表名就是关系，二维表中的一行就是一条记录，二维表中的一列就是一个字段。

优点

容易理解

使用方便，通用的sql语言

易于维护，丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大降低了数据冗余和数据不一致的概率

缺点

磁盘I/O是并发的瓶颈

海量数据查询效率低

横向扩展困难，无法简单的通过添加硬件和服务节点来扩展性能和负载能力，当需要对数据库进行升级和扩展时，需要停机维护和数据迁移

多表的关联查询以及复杂的数据分析类型的复杂sql查询，性能欠佳。因为要保证acid，必须按照三范式设计。

数据库

Orcale，Sql Server，MySql，DB2

3.2. 非关系型数据库

非关系型，分布式，一般不保证遵循ACID原则的数据存储系统。键值对存储，结构不固定。

优点

根据需要添加字段，不需要多表联查。仅需id取出对应的value

适用于SNS（社会化网络服务软件。比如facebook，微博）

严格上讲不是一种数据库，而是一种数据结构化存储方法的集合

缺点

只适合存储一些较为简单的数据

不合适复杂查询的数据

不合适持久存储海量数据

数据库

K-V：Redis，Memcache

文档：MongoDB

搜索：Elasticsearch，Solr

可扩展性分布式：HBase

比较：

在这里插入图片描述

4. Redis-cli操作Redis

4.1. Redis-cli连接Redis

-h :用于指定ip

-p :用于指定端口

-a :用于指定认证密码

./redis-cli -p 6379 -a root

PING命令返回PONG

指定database

SELECT 1

4.2. Redis-cli操作Redis

4.2.1. 操作String

set :添加一条String类型数据

get :获取一条String类型数据

mset :添加多条String类型数据

mget :获取多条String类型数据

4.2.2. 操作hash

hset :添加一条hash类型数据

hget :获取一条hash类型数据

hmset :添加多条hash类型数据

hmget :获取多条hash类型数据

hgetAll :获取指定所有hash类型数据

hdel :删除指定hash类型数据(一条或多条)

4.2.3. 操作list

lpush :左添加(头)list类型数据

rpush :右添加(尾)类型数据

lrange : 获取list类型数据start起始下标 end结束下标包含关系

len :获取条数

lrem :删除列表中几个指定list类型数据

4.2.4. 操作set

sadd :添加set类型数据

smembers :获取set类型数据

scard :获取条数

srem :删除数据

4.2.5. 操作sorted set

sorted set是通过分数值来进行排序的，分数值越大，越靠后。

zadd :添加sorted set类型数据

zrange :获取sorted set类型数据

zcard :获取条数

zrem :删除数据

zadd需要将Float或者Double类型分数值参数，放置在值参数之前

4.2.6. Redis中以层级关系、目录形式存储数据

4.2.7. 设置key的失效时间

Redis 有四个不同的命令可以用于设置键的生存时间(键可以存在多久)或过期时间(键什么时候会被删除) :

EXPlRE :用于将键 key 的生存时间设置为 ttl 秒。

PEXPIRE :用于将键 key 的生存时间设置为 ttl 毫秒。

EXPIREAT < timestamp> :用于将键 key 的过期时间设置为 timestamp 所指定的秒数时间戳。

PEXPIREAT < timestamp > :用于将键 key 的过期时间设置为 timestamp 所指定的毫秒数时间戳。

TTL :获取的值为-1说明此 key 没有设置有效期，当值为-2时证明过了有效期

4.2.8. 删除

del :用于删除数据（通用，适用于所有数据类型）

hdel :用于删除hash类型数据

5. Java操作Redis

jedis:

5.5. Java操作Redis五种数据类型

5.5.1. 连接与释放

@Autowired 
private JedisPool jedisPool; 
private Jedis jedis = null; 
//初始化jedis对象实例 
@Before 
public void initConn(){ 
    jedis = jedisPool.getResource();
}
//释放资源 
@After public void closeConn(){ 
    if (jedis!=null){ 
        jedis.close(); 
    } 
}

5.5.2. 操作String

5.5.3. 操作hash

5.5.4. 操作list

5.5.5. 操作set

5.5.6. 操作sorted set

5.5.7. Redis中以层级关系、目录形式存储数据

5.5.8. 设置key的失效时间

5.5.9. 获取所有key&事务&删除

5.5.10. 操作byte

6. Redis持久化

6.1. RDB

6.1.1. save

6.1.2. bgsave

6.1.3. 自动化

6.2. AOF

appendonly ：开启AOF，默认关闭

appendfilename ：AOF存储的文件名称

优点：

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。

缺点：

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件

7. Redis搭建主从复用

Redis支持主从复用。数据可以从主服务器向任意数量的从服务器上同步，同步使用的是发布/订阅机

制。Mater Slave的模式，从Slave向Master发起SYNC命令。

可以是1 Master 多Slave，可以分层，Slave下可以再接Slave，可扩展成树状结构。

7.1. 读写分离

7.2. 主备切换

7.2.1. 主从节点redis.conf配置

参照读写分离的相应配置

7.2.2. 哨兵sentinel.conf 哨兵配置

拷贝哨兵配置文件到指定目录

8.4. Lettuce和Jedis的区别

Jedis 是一个优秀的基于 Java 语言的 Redis 客户端，但是，其不足也很明显： Jedis 在实现上是直接连接 Redis-Server，在多个线程间共享一个 Jedis 实例时是线程不安全的，如果想要在多线程场景下使用 Jedis ，需要使用连接池，每个线程都使用自己的 Jedis 实例，当连接数量增多时，会消耗较多的物理资源。

Lettuce 则完全克服了其线程不安全的缺点： Lettuce 是基于 Netty 的连接

（StatefulRedisConnection），Lettuce 是一个可伸缩的线程安全的 Redis 客户端，支持同步、异步和响应式模式。多个线程可以共享一个连接实例，而不必担心多线程并发问题。它基于优秀 Netty NIO 框架构建，支持 Redis 的高级功能，如 Sentinel，集群，流水线，自动重新连接和 Redis 数据模型。

8.6. 自定义模板解决序列化问题

默认情况下的模板 RedisTemplate<Object, Object>，默认序列化使用的是

JdkSerializationRedisSerializer ，存储二进制字节码。这时需要自定义模板，当自定义模板后又想存储 String 字符串时，可以使StringRedisTemplate的方式，他们俩并不冲突。

序列化问题：

要把 domain object 做为 key-value 对保存在 redis 中，就必须要解决对象的序列化问题。Spring Data Redis给我们提供了一些现成的方案：

JdkSerializationRedisSerializer 使用JDK提供的序列化功能。优点是反序列化时不需要提供类型信息(class)，但缺点是序列化后的结果非常庞大，是JSON格式的5倍左右，这样就会消耗 Redis 服务器的大量内存。

Jackson2JsonRedisSerializer 使用 Jackson 库将对象序列化为JSON字符串。优点是速度快，序列化后的字符串短小精悍。但缺点也非常致命，那就是此类的构造函数中有一个类型参数，必须提供要序列化对象的类型信息(.class对象)。通过查看源代码，发现其只在反序列化过程中用到了类型信息。

GenericJackson2JsonRedisSerializer 通用型序列化，这种序列化方式不用自己手动指定对象的 Class。

8.7. 操作string

8.8. 操作hash

8.9. 操作list

8.10. 操作set

8.11. 操作sorted set

8.12. 获取所有key&删除

8.13. 设置key的失效时间

8.14. SpringDataRedis整合使用哨兵机制

9. 如何应对缓存穿透、缓存击穿、缓存雪崩问题

9.1. Key的过期淘汰机制

Redis可以对存储在Redis中的缓存数据设置过期时间，比如我们获取的短信验证码一般十分钟过期，我们这时候就需要在验证码存进Redis时添加一个key的过期时间，但是这里有一个需要格外注意的问题就是：并非key过期时间到了就一定会被Redis给删除。

9.1.1. 定期删除

Redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 Key，检查其是否过期，如果过期就删除。为什么是随机抽取而不是检查所有key？因为你如果设置的key成千上万，每100毫秒都将所有存在的key检查一遍，会给CPU带来比较大的压力。

9.1.2. 惰性删除

定期删除由于是随机抽取可能会导致很多过期 Key 到了过期时间并没有被删除。所以用户在从缓存获取数据的时候，redis会检查这个key是否过期了，如果过期就删除这个key。这时候就会在查询的时候将过期key从缓存中清除。

9.1.3. 内存淘汰机制

仅仅使用定期删除 + 惰性删除机制还是会留下一个严重的隐患：如果定期删除留下了很多已经过期的key，而且用户长时间都没有使用过这些过期key，导致过期key无法被惰性删除，从而导致过期key一直堆积在内存里，最终造成Redis内存块被消耗殆尽。那这个问题如何解决呢？这个时候Redis内存淘汰机制应运而生了。Redis内存淘汰机制提供了6种数据淘汰策略：

volatile-lru ：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。

volatile-ttl ：从已设置过期时间的数据集中挑选将要过期的数据淘汰。

volatile-random ：从已设置过期时间的数据集中任意选择数据淘汰。

allkeys-lru ：当内存不足以容纳新写入数据时移除最近最少使用的key。

allkeys-random ：从数据集中任意选择数据淘汰。

no-enviction（默认）：当内存不足以容纳新写入数据时，新写入操作会报错。

一般情况下，推荐使用 volatile-lru 策略，对于配置信息等重要数据，不应该设置过期时间，这样

Redis就永远不会淘汰这些重要数据。对于一般数据可以添加一个缓存时间，当数据失效则请求会从DB中获取并重新存入Redis中。

9.2. 缓存击穿

首先我们来看下请求是如何取到数据的：当接收到用户请求，首先先尝试从Redis缓存中获取到数据，如果缓存中能取到数据则直接返回结果，当缓存中不存在数据时从DB获取数据，如果数据库成功取到数据，则更新Redis，然后返回数据

定义：高并发的情况下，某个热门key突然过期，导致大量请求在Redis未找到缓存数据，进而全部去访问DB请求数据，引起DB压力瞬间增大。

解决方案：缓存击穿的情况下一般不容易造成DB的宕机，只是会造成对DB的周期性压力。对缓存击穿的解决方案一般可以这样：

Redis中的数据不设置过期时间，然后在缓存的对象上添加一个属性标识过期时间，每次获取到数据时，校验对象中的过期时间属性，如果数据即将过期，则异步发起一个线程主动更新缓存中的数据。但是这种方案可能会导致有些请求会拿到过期的值，就得看业务能否可以接受，如果要求数据必须是新数据，则最好的方案则为热点数据设置为永不过期，然后加一个互斥锁保证缓存的单线程写。

9.3. 缓存穿透

定义：缓存穿透是指查询缓存和DB中都不存在的数据。比如通过id查询商品信息，id一般大于0，攻击者会故意传id为-1去查询，由于缓存是不命中则从DB中获取数据，这将会导致每次缓存都不命中数据导致每个请求都访问DB，造成缓存穿透。

解决方案

利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试

采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。

提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回。

如果从数据库查询的对象为空，也放入缓存，只是设定的缓存过期时间较短，比如设置为60秒。

9.4. 缓存雪崩

定义：缓存中如果大量缓存在一段时间内集中过期了，这时候会发生大量的缓存击穿现象，所有的请

求都落在了DB上，由于查询数据量巨大，引起DB压力过大甚至导致DB宕机。

解决方案：

给缓存的失效时间，加上一个随机值，避免集体失效。如果Redis是集群部署，将热点数据均匀分

布在不同的Redis库中也能避免全部失效的问题

使用互斥锁，但是该方案吞吐量明显下降了。

设置热点数据永远不过期。

双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点

从缓存A读数据库，有则直接返回
A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。

合法，则直接返回。