SpringBoot+Redis

windows 下启动redis服务

redis-server.exe redis.windows.conf

为什么要使用缓存

缓存是在内存中存储的数据备份，当数据没有发生本质变化时
就可以直接从内存中查询数据，而不用去数据库查询(在磁盘中)
CPU读取内存的速度要比读取磁盘快，可以提高效率

什么是Redis

（这不就是总结下redis的定义和特点嘛）Redis是C语言开发的一个开源的（遵从BSD协议）高性能键值对（key-value）的内存数据库，可以用作数据库、缓存、消息中间件等。它是一种NoSQL（not-only sql，泛指非关系型数据库）的数据库。
我顿了一下，接着说：Redis作为一个内存数据库。1、性能优秀，数据在内存中，读写速度非常快，支持并发10W QPS；2、单进程单线程，是线程安全的，采用IO多路复用机制；3、丰富的数据类型，支持字符串（string）、散列（hash）、列表（list）、集合（set）、有序集合（sorted set）等；4、支持数据持久化。可以将内存中数据保存在磁盘中，重启时加载；5、主从复制，哨兵，高可用；6、可以用作分布式锁；7、可以作为消息中间件使用，支持发布订阅

1.在springboot项目的pom.xml

文件里加入redis的jar依赖

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

2.目录结构：redis用到的类

一些自己新建的控制类，配置类，工具类

3.在application.yml中配置redis参数

application在项目目录中的位置

https://www.jianshu.com/p/5596c3a4978d

缓存处理方式应该是

1.先从缓存中拿数据，如果有，直接返回。
2.如果拿到的为空，则数据库查询，然后将查询结果存到缓存中。
由此实现方式应该如下：

下面展示一些 内联代码片。

// A code block
var foo = 'bar';

// An highlighted block
private String baseKey = "category";
 
public CmfCategories selectByPrimaryKey(Long id) {
//1. 先从缓存中取
CmfCategories cmfCategories = redisUtils.get(baseKey + id, CmfCategories.class);
if (cmfCategories == null) { //如果取值为空
//2. 从数据中查询
cmfCategories = cmfCategoriesMapper.selectByPrimaryKey(id);
//3. 将查询结果存入缓存
redisUtils.set(baseKey + id, cmfCategories, DEFAULT_EXPIRE * 7);
}
return cmfCategories;
}

这种方式是没错的，但就是实现起来，每个接口都要做一遍重复的操作，下面演示一种简洁的使用注解实现方式：

@Cacheable(value = "newsCategory", key = "'newsCategory:'+#id", unless = "#result==null")
public CmfCategories selectByPrimaryKey(Long id) {
　　return cmfCategoriesMapper.selectByPrimaryKey(id);
}

高并发

1.QPS即每秒查询率，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

分区

分区可以让redis管理更大的内存
因为分区是在多个redis实例上存储数据，即在多台计算机上处理数据，不止内存变大，运行速度也会变快。

分区的不足
redis的一些特性在分区方面表现的不是很好：

涉及多个key的操作通常是不被支持的。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
涉及多个key的redis事务不能使用。

Redis数据类型

1、String
常用命令：
除了get、set、incr、decr mget等操作外，Redis还提供了下面一些操作：
获取字符串长度
往字符串append内容
设置和获取字符串的某一段内容
设置及获取字符串的某一位（bit）
批量设置一系列字符串的内容

应用场景：
String是最常用的一种数据类型，普通的key/value存储都可以归为此类，value其实不仅是String，
也可以是数字：比如想知道什么时候封锁一个IP地址(访问超过几次)。INCRBY命令让这些变得很容易，通过原子递增保持计数。

实现方式：
m,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
例如微博数、粉丝数等

2.Hash
常用命令：
hget,hset,hgetall 等。
应用场景：
我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：
用户ID，为查找的key，
存储的value用户对象包含姓名name，年龄age，生日birthday 等信息，
如果用普通的key/value结构来存储，主要有以下2种存储方式：
第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，
如：set u001 “李三,18,20010101”
这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。
第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，
如：mset user:001:name "李三 "user:001:age18 user:001:birthday “20010101”
虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。
那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，
并提供了直接存取这个Map成员的接口，
如：hmset user:001 name “李三” age 18 birthday “20010101”
也就是说，Key仍然是用户ID,value是一个Map，这个Map的key是成员的属性名，value是属性值，
这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过
key(用户ID) + field(属性标签) 操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。

      这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。

实现方式：
上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

3.List
常用命令：
lpush,rpush,lpop,rpop,lrange,BLPOP(阻塞版)等。

应用场景：
Redis list的应用场景非常多，也是Redis最重要的数据结构之一。
我们可以轻松地实现最新消息排行等功能。
Lists的另一个应用就是消息队列，可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。

实现方式：
Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

RPOPLPUSH source destination

命令 RPOPLPUSH 在一个原子时间内，执行以下两个动作：
将列表 source 中的最后一个元素(尾元素)弹出，并返回给客户端。
将 source 弹出的元素插入到列表 destination ，作为 destination 列表的的头元素。
如果 source 和 destination 相同，则列表中的表尾元素被移动到表头，并返回该元素，可以把这种特殊情况视作列表的旋转(rotation)操作。
一个典型的例子就是服务器的监控程序：它们需要在尽可能短的时间内，并行地检查一组网站，确保它们的可访问性。
redis.lpush "downstream_ips", "192.168.0.10"
redis.lpush "downstream_ips", "192.168.0.11"
redis.lpush "downstream_ips", "192.168.0.12"
redis.lpush "downstream_ips", "192.168.0.13"
Then:
next_ip = redis.rpoplpush "downstream_ips", "downstream_ips"

BLPOP

假设现在有 job 、 command 和 request 三个列表，其中 job 不存在， command 和 request 都持有非空列表。考虑以下命令：
BLPOP job command request 30 #阻塞30秒，0的话就是无限期阻塞,job列表为空,被跳过,紧接着command 列表的第一个元素被弹出。

1. “command” # 弹出元素所属的列表
2. “update system…” # 弹出元素所属的值
   为什么要阻塞版本的pop呢，主要是为了避免轮询。举个简单的例子如果我们用list来实现一个工作队列。执行任务的thread可以调用阻塞版本的pop去获取任务这样就可以避免轮询去检查是否有任务存在。当任务来时候工作线程可以立即返回，也可以避免轮询带来的延迟。

Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。
4、Set

常用命令：
sadd,srem,spop,sdiff ,smembers,sunion 等。

应用场景：
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
比如在微博应用中，每个人的好友存在一个集合（set）中，这样求两个人的共同好友的操作，可能就只需要用求交集命令即可。
Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实

实现方式：
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

案例：在微博中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

5、Sorted set

常用命令：
zadd,zrange,zrem,zcard等

使用场景：
以某个条件为权重，比如按顶的次数排序.
ZREVRANGE命令可以用来按照得分来获取前100名的用户，ZRANK可以用来获取用户排名，非常直接而且操作容易。
Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。
比如:twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
比如:全班同学成绩的SortedSets，value可以是同学的学号，而score就可以是其考试得分，这样数据插入集合的，就已经进行了天然的排序。
另外还可以用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

需要精准设定过期时间的应用
比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的过期数据，你完全可以把Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。

实现方式：
Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单
应用场景：排行榜

分布式锁

这里的问题是：Java 提供的原生锁机制在多机部署场景下失效了，这是因为两台机器加的锁不是同一个锁（两个锁在不同的 JVM 里面）

分布式锁的思路是：在整个系统提供一个全局、唯一的获取锁的“东西”，然后每个系统在需要加锁时，都去问这个“东西”拿到一把锁，这样不同的系统拿到的就可以认为是同一把锁。

应用场景

Redis——解决超卖问题

redis来使数据库的压力变小，读取数据的速度更快

数据一致性的话使用先更新数据库，再更新缓存的方式
这样的话数据库更新失败回滚的时候影响会比较小

2.先更新DB再删除缓存（使用场景多）

结论：产生脏数据的概率较小，但是会出现一致性的问题；若更新操作的时候，同时进行查询操作，若hit，则查询得到的数据是旧的数据。但是不会影响后面的查询。（代价较小）

（ 一个是查询操作，一个是更新操作的并发，首先，没有了删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题，后续的查询操作一直都在取老的数据。）

该设计模式产生脏数据的可能情况：

一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。

该情况出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

Redis实际操作

h获取食堂中的菜品id和对应的菜品信息

先用一个key为dishList,value为菜品id列表的键值对存储菜品列表
获得菜品列表之后，通过列表里的每一个菜品id在redis中获取菜的信息，
如果对应的id没有，则去数据库中获取

修改菜品时，删除对应菜品id的缓存

redis持久化

Redis持久化备份数据的方式有两种：RDB(Redis DataBase) 、 AOF(Append Only File).

于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。

什么是RDB
在指定时间间隔内，将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中，来达到恢复数据的。

如何持久化
Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写进一个临时文件中，等到持久化过程结束了，再用这个临时文件替换上次持久化好的文件。在这个过程中，只有子进程来负责IO操作，主进程仍然处理客户端的请求，这就确保了极高的性能。

AOF优缺点
优点
AOF有着多种持久化策略：
appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

appendfsync no:不同步。

AOF文件是一个只进行追加操作的日志文件，对文件写入不需要进行seek，即使在追加的过程中，写入了不完整的命令（例如：磁盘已满），可以使用redis-check-aof工具可以修复这种问题

Redis可以在AOF文件变得过大时，会自动地在后台对AOF进行重写：重写后的新的AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建AOF文件的过程中，会继续将命令追加到现有的AOF文件中，即使在重写的过程中发生宕机，现有的AOF文件也不会丢失。一旦新AOF文件创建完毕，Redis就会从旧的AOF文件切换到新的AOF文件，并对新的AOF文件进行追加操作。

AOF文件有序地保存了对数据库执行的所有写入操作。这些写入操作一Redis协议的格式保存，易于对文件进行分析；例如，如果不小心执行了FLUSHALL命令，但只要AOF文件未被重写，通过停止服务器，移除AOF文件末尾的FLUSHALL命令，重启服务器就能达到FLUSHALL执行之前的状态。

缺点
对于相同的数据集来说，AOF文件要比RDB文件大。
根据所使用的持久化策略来说，AOF的速度要慢与RDB。一般情况下，每秒同步策略效果较好。不使用同步策略的情况下，AOF与RDB速度一样快。
RDB与AOF如何选择
一般来说，如果想达到足以媲美PostgreSQL的数据安全性，应该同时使用两种持久化方式。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。
如果可以承受输分钟内的数据丢失，可以只使用RDB持久化。

Redis为什么运行速度这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

Redis多路复用

redis 采用网络IO多路复用技术来保证在多连接的时候， 系统的高吞吐量。

首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

redis的io模型主要是基于epoll实现的，不过它也提供了 select和kqueue的实现，默认采用epoll。

epoll有诸多优点：

1. epoll 没有最大并发连接的限制，上限是最大可以打开文件的数目，这个数字一般远大于 2048,
一般来说这个数目和系统内存关系很大
，具体数目可以 cat /proc/sys/fs/file-max 察看。

2. 效率提升， Epoll 最大的优点就在于它
只管你“活跃”的连接
，而跟连接总数无关，因此在实际的网络环境中， Epoll 的效率就会远远高于 select 和 poll 。

3. 内存拷贝， Epoll 在这点上使用了“
共享内存
”，这个内存拷贝也省略了。

面试题

1.Redis的数据类型 3

2.Redis怎么实现hash

Redis底层数据结构和内存模型

bitmap介绍下

Redis容灾怎么做

一致性hash 2

redis集群 2

Redis分布式锁 2

Redis的底层数据结构说一下

Redis雪崩、击穿、穿透

缓存雪崩

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决方案
缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存击穿

缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

解决方式也很简单，可以将热点数据设置为永远不过期；或者基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。

缓存穿透

举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

怎么处理Redis宕机的情况？（我说了持久化策略，RDB和AOF，这两个的介绍）

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

一般来说， 如果想达到足以媲美PostgreSQL的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

有很多用户都只使用AOF持久化，但并不推荐这种方式：因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外， 使用RDB还可以避免之前提到的AOF程序的bug。

Redis读写速度很快，这是怎么做到的？

Redis中的事件处理机制，我说放到事件队列里面，这样有什么好处？

Redis为什么不用多线程去处理？

1.因为Redis是基于内存的操作，CPU不是Redis的瓶颈。2.单线程容易实现。3.不需要各种锁的性能消耗 4.单线程多进程集群方案
5. 上下文切换会对CPU有影响

多线程上下文切换的具体操作。（切换消耗CPU资源）

Redis中的数据有没有设置过期时间。

Redis中有个设置时间过期的功能，即对存储在Redis数据库中的值可以设置一个过期时间

EXPIRE : 将键的生存时间设为 ttl 秒

PERSIST 命令可以移除一个键的过期时间

三种过期策略

立即删除
给CPU的压力会比较大

惰性删除
惰性删除是指，某个键值过期后，此键值不会马上被删除，而是等到下次被使用的时候，才会被检查到过期，此时才能得到删除。
占用内存比较多

定时删除

从上面分析来看，立即删除会短时间内占用大量cpu，惰性删除会在一段时间内浪费内存，所以定时删除是一个折中的办法。
定时删除是：每隔一段时间执行一次删除操作，并通过限制删除操作执行的时长和频率，来减少删除操作对cpu的影响。另一方面定时删除也有效的减少了因惰性删除带来的内存浪费。

Redis中的数据要是内存空间不够会怎么样？（内存淘汰策略）.

https://cloud.tencent.com/developer/article/1699610

allkeys-lru：在主键空间中，优先移除最近未使用的key。(推荐)

linux启动redis

解压：tar -zxvf redis-6.0.8.tar.gz
进入解压：cd ./redis-6.0.8/src
编译：make
指定目录安装：make PREFIX=/home/redis install
进入指定目录：cd /home/redis
启动redis：./redis-server

后端模式启动redis
./redis-server redis.conf