java学习（六）

1、redis有了解吗？

redis（Remote Dictionary Server远程字典服务），是一款高性能的(key/value)分布式内存数据库，基于内存运行并支持持久化的NoSQL数据库。因为数据都在内存中，所以运行速度快。redis支持丰富的数据类型并且支持事务，事务中的所有命令会被序列化、按顺序执行，在执行的过程中不会被其他客户端发送来的命令打断

2、redis相比memcached有哪些优势？

memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型。
redis的速度比memcached快很多，并且redis支持数据的持久化。
redis支持数据的备份，即master-slave模式的数据备份。
使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样。redis自己构建了VM 管理机制。
value大小不同，redis最大可以达到512MB，而memcache只有1MB。

3、redis都支持哪些数据类型？应用场景有哪些？

redis支持五种数据类型作为其Value，redis的Key都是字符串类型的。

string：redis 中字符串 value 最大可为512M。可以用来做一些计数功能的缓存（也是实际工作中最常见的）。
list：简单的字符串列表，按照插入顺序排序，可以添加一个元素到列表的头部（左边）或者尾部（右边），其底层实现是一个链表。可以实现一个简单消息队列功能，做基于redis的分页功能等。
set：是一个字符串类型的无序集合。可以用来进行全局去重等。
sorted set：是一个字符串类型的有序集合，给每一个元素一个固定的分数score来保持顺序。可以用来做排行榜应用或者进行范围查找等。
hash：键值对集合，是一个字符串类型的 Key和 Value 的映射表，也就是说其存储的Value是一个键值对（Key- Value）。可以用来存放一些具有特定结构的信息。

4、redis的配置文件有了解吗？

下载并且解压redis之后，在解压目录下有个配置文件 redis.windows.conf，在配置文件中对redis进行了分模块配置，常用的模块如下：

NETWORK：该模块可以配置一些redis服务器地址，端口以及超时时间等
GENERAL：该模块可以对日志文件的路径和日志级别等进行配置
SNAPSHOTTING：redis持久化配置信息等
REPLICATION：redis集群配置等信息
MEMORY MANAGEMENT：内存管理，包括数据过期删除策略信息的设置
APPEND ONLY MODE：日志持久化方式信息设置

5、redis是单线程的吗？为什么执行速度这么快？

redis是单线程的，redis的单线程是指网络请求模块使用了一个线程，所以不需考虑并发安全性。但是对于需要依赖多个操作的复合操作来说，还是需要锁的，而且有可能是分布式锁。

那么单线程的redis为什么执行速度如此之快？

基于内存实现，完全内存计算
单线程操作，避免了线程上下文切换操作
多路I/O复用的线程模型，实现了一个线程监控多个IO流，及时响应请求
redis对外部的依赖比较少，属于轻量级内存数据库

6、使用redis可能出现的问题

缓存雪崩：

举例：缓存同一时间大面积的失效，这个时候又来的一波请求都到数据库上，导致数据库连接异常。

解决办法：可以给缓存设置不同的缓存时间，更新数据使用互斥锁或者通过双缓存在避免缓存雪崩。

缓存穿透：

举例：故意的去请求缓存中不存在的数据，导致请求都打到了数据库上，导致数据库异常。

解决办法：可以使用互斥锁或者无论是否取到结果都将结果存入缓存，还可以使用有效的机制来拦截不合法的key值等。

数据库和缓存的双写一致性问题：

在高并发请求下很容易导致数据不一致的问题，如果你的业务需要保证数据的强一致性，那么建议不要使用缓存。在数据库中和缓存数据的删除或者写入过程中，如果有失败的情况，会导致数据的不一致。

解决办法：

双删延时的解决办法。可以先删除缓存数据，然后再更新数据库数据，最后再隔固定的时间再次删除缓存。
更新数据库产生的binlog订阅（使用canal）。将有变化的key记录下来，并且尝试去不断的去删除缓存（如果上次删除缓存失败）

7、redis的持久化方式有哪些？

在redis中的介绍中，我们知道了redis不光是一个基于内存的缓存，同时还支持数据的持久化。在redis的配置文件模块介绍中，我们可以设置redis的持久化方式。redis的持久化方式有两种，即RDB和AOF的方式，分别介绍如下：

RDB（快照方式 snapshotting）（全量持久化）：

将当前内存中的数据集快照写入磁盘，实现数据的持久化，恢复时可以将快照重新载入内存。

触发方式：

自动触发：在配置文件中，可以配置执行了多少次save就自动触发自动持久化。
手动触发：通过bgsave命令，在后台异步进行生成快照的操作，同时还可以响应客户端的请求。通过redis进程fork操作创建子进程，生成的快照由子进程负责，客户端请求只会在fork阶段被阻塞。

快照恢复：将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务，redis会自动加载快照文件数据到内存。但是，redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

优缺点分析：

RDB持久化方式存在数据的丢失，因为其没有办法实现实时持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高，会影响系统性能。自动触发也存在丢失部分数据的情况。
在恢复大数据集时候，RDB方式相对于AOF要快。

AOF（append-only-file）（增量持久化）：

在 redis配置文件的 APPEND ONLY MODE 中，可以设置AOF持久化。通过记录redis服务器所执行的写命令来记录数据库状态。恢复时可以将AOF文件载入内存，并且可以通过redis-check-aof --fix 进行修复AOF文件。

AOF日志重写：

AOF文件会随着服务器运行的时间越来越大，可以通过AOF重写来控制AOF文件的大小。
AOF重写会首先读取数据库中现有的键值对状态，然后根据类型使用一条命令来替代前面对键值对操作的多条命令。
使用命令 bgrewriteaof 来实现AOF重写

AOF重写缓存区：
redis 是单线程工作，当AOF文件较大时重写时间会比较长，在重写 AOF 期间，redis将长时间无法处理客户端请求。为了解决这个问题，可以将 AOF 重写程序放到子进程中执行，好处如下：

子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其它客户端请求。
子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

子进程中AOF重写导致的问题：

子进程在进行 AOF 重写期间，服务器进程依然可以处理其它客户端请求，这就会导致数据库状态已经发生了改变，使得当前数据库数据状态和重写后的 AOF 文件中的数据不一致。
也就是出现了AOF文件和数据库中数据不一致的问题。

数据状态不一致解决办法：

redis 服务器设置了一个 AOF 重写缓冲区。这个缓冲区在创建子进程后开始使用，当redis服务器执行一个客户端的写请求命令，之后将这个写命令也发送到 AOF 重写缓冲区。
当子进程完成 AOF 日志重写之后，给父进程发送信号，父进程接收此信号后，将 AOF 重写缓冲区的内容写到新的 AOF 文件中，保持数据的一致性。

优缺点分析：