Redis（详解）

背景

在我们的项目架构中，基本上是web服务器和数据库独立部署，独占服务器资源，随着用户数的增长，并发读写数据库，会增加数据库访问的压力，导致性能下降，严重则会导致系统宕机：

此时，我们可以在Tomcat同服务器上增加本地缓存，并在外部增加分布式缓存，缓存热门数据。也就是通过缓存把绝大部分请求在读写数据库前拦截掉，大大降低数据库压力。

基于这样的一种架构设计，于是redis分布式数据库就诞生了。

Redis 概述

Redis是一个Key-value存储系统，是一个分布式缓存数据库。

Redis常用数据类型

Redis作为一种Key/value结构的数据存储系统，为了便于对数据进行管理，提供了多种数据类型。

然后基于指定类型存储我们项目中产生的数据，例如用户的登录信息，购物车信息，商品详情信息等。

String类型

字符串类型是redis中最简单的数据类型，它存储的值可以是字符串，其最大字符串长度支持到512M。基于此类型，可以实现博客的字数统计，将日志不断追加到指定key，实现一个分布式自增iid，实现一个博客的的点赞操作等

mset/mget

同时设置/获取多个键值
语法：MSET key value [key value …]
MGET key [key …]

Hash类型应用实践

Redis散列类型相当于Java中的HashMap，实现原理跟HashMap一致,一般用于存储对象信息，存储了字段（field）和字段值的映射，一个散列类型可以包含最多232-1个字段。

List类型应用实践

Redis的list类型相当于java中的LinkedList，其原理就就是一个双向链表。支持正向、反向查找和遍历等操作，插入删除速度比较快。经常用于实现热销榜，最新评论等的设计。

Set类型应用实践

Redis的Set类似Java中的HashSet，是string类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。Redis中Set集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

Java中操作redis

Jedis的基本应用

简介

Jedis是java操作redis的一个客户端，类似通过JDBC访问数据库。

RedisTemplate基本应用

简介

RedisTemplate为SpringBoot工程中操作redis数据库的一个java对象，此对象封装了redis的一些基本操作。

准备工作

第一步：添加在redis-template工程添加依赖

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.3.2.RELEASE</version>
                <scope>import</scope>
                <type>pom</type>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

第二步：创建工程配置文件application.yml,其内容如下

spring:
  redis:
    host: 192.168.64.128  #写自己的ip
    port: 6379

第三步：创建工程启动类

Redis 数据持久化

背景
Redis是一种内存数据库，在断电时数据可能会丢失。比如你redis整个挂了，然后redis不可用了，如果没有持久化的话，redis就会丢失所有的数据，如果通过持久化将数据搞一份儿到磁盘上去，然后再定期同步到一些云存储服务上去，那么就可以保证一些数据不丢失，保证数据的可靠性。

持久化方式

Redis中为了保证在系统宕机(类似进程被杀死)情况下，能更快的进行故障恢复，设计了两种数据持久化方案，分别为rdb和aof方式。

配置准备工作
第一步:从redis.io官方下载对应版本的redis.conf文件,地址如下

https://redis.io/topics/config/

第二步:停止redis并删除挂载目录下(/usr/local/docker/redis01/conf)的redis.conf配置文件.
第三步:将下载的redis.conf文件拷贝到redis挂载目录(/usr/local/docker/redis01/conf)
第四步:基于vim打开redis.conf文件,然后注释 bind 127.0.0.1这一行,并修改protected-mode的值修改为no.(java连接redis需要改这两项目)
第五步:重启redis服务,并检查启动日志(docker logs 容器id)

Rdb方式持久化

概述

Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为0redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。

面试常问

触发redis中rdb方式持久化的时机?

1)基于配置文件中的save规则周期性的执行持久化。
2)手动执行了shutdown操作会自动执行rdb方式的持久化。
3)手动调用了save或bgsave指令执行数据持久化。
4)在Master/Slave架构下,当有新的Slave连接Master时,Master会对数据进行rdb方式持久化.
 

Redis中的save和bgsave有什么不同？

Save命令执行一个同步保存操作，将当前Redis实例的所有数据快照以Rdb文件形式保存到磁盘。

Bgsave命令执行后立即返回OK，然后Redis分出一个子进程，子进程负责讲redis数据保存到磁盘，然后退出，原来的进程则继续处理客户端请求。

RDB持久化机制有哪些优缺点？

优点： RDB 方式持久化性能较好，执行持久化时可以fork 一个子进程，由子进程处理保存工作，父进程无须执行任何磁盘 I/O 操作。

缺点：RDB方式在服务器故障时容易造成数据的丢失。实际项目中，我们可通过配置来控制持久化的频率。但是，如果频率太频繁，可能会对 Redis 性能产生影响。所以通常可能设置至少5分钟才保存一次快照，这时如果 Redis 出现宕机等情况，则意味着最多可能丢失5分钟数据。

Aof方式数据持久化

概述

Aof方式是通过记录写操作日志的方式,实现redis数据持久化的一种机制,这个机制默认是关闭的。

AOF持久化机制有哪些优缺点？

优点：AOF 比 RDB更加可靠。你可以设置不同的 fsync 策略（no、everysec 和 always）。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

缺点：性能较慢

如何选择redis的持久化方式？

第一：不要仅仅使用RDB，因为那样会导致你丢失很多数据。
第二：也不要仅仅使用AOF，因为AOF做冷备没有RDB做冷备进行数据恢复的速度快,并且RDB简单粗暴的数据快照方式更加健壮。
第三：综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备。

Redis 事务处理实践

基本指令

redis进行事务控制时，通常是基于如下指令进行实现，例如：

• multi 开启事务
• exec 提交事务
• discard 取消事务
• watch 监控，如果监控的值发生变化，则提交事务时会失败
• unwatch 去掉监控

Redis主从复制，哨兵模式！

Redis主从复制

简介

单个Redis支持的读写能力还是有限的,此时我们可以使用多个redis来提高redis的并发处理能力,这些redis如何协同,就需要有一定的架构设计,这里我们首先从主从(Master/Slave)架构进行分析和实现

基于redis,设计一主从架构,一个Master,两个Slave,其中Master负责Redis读写操作,并将数据同步到Slave,Slave只负责读.

Redis哨兵模式
简介
哨兵（Sentinel）是Redis主从架构模式下，实现高可用性（high availability）的一种机制。由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
 

哨兵工作原理分析   

1)每个Sentinel以每秒一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
2)如果一个Redis服务距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值(这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒)， 则这个Redis服务会被 Sentinel 标记为主观下线。
3)如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4)当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。