一文带你玩转Redis缓存数据库

Redis

---

1. Redis概述

1.1 简介

Redis，REmote DIctionary Server(远程字典服务器)是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的(key-value)分布式内存数据库，基于内存运行并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一,也被人们称为数据结构服务器。
Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用；
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储；
• Redis支持数据的备份，即master-slave模式的数据备份。
  Reids数据库在很多方面都可以用到：
• 缓存
• 消息队列
• 任务队列
• 分布式锁

官网: http://redis.io/
中文官网:http://www.redis.cn/

1.2 安装

• Linux
  
• windows
  

1.3 redis服务启动与停止

• 交互式启动redis服务

  redis-server
  1

• 后台式启动redis服务

  sudo service redis-server start
  1

  

• 连接redis服务

redis-cli
1

• 设置连接密码,编写 配置文件//etc/redis/redis.conf

requirepass 123qwe
1

• 设置远程连接,编写配置文件/etc/redis/redis.conf,注释 bind 127.0.0.1即可
  

2. Redis 数据类型

3. 常用命令

3.1 字符串类型常用命令

3.2 Hash类型常用命令

3.3 列表类型常用命令

通常用作任务队列

3.4 集合类型常用命令

• 无序集合
  
• 有序集合
  

3.5 通用命令

4. 在Java中操作redis

4.1 介绍

4.2 Jedis

import redis.clients.jedis.Jedis;  
  
import java.util.HashMap;  
  
/**  
 * @Description: 使用jedis操作redis数据库  
 * @date: 2022/7/18  上午10:36  
 * @author: xcy.小相  
 * @ClassName : JedisTest  
 */public class JedisTest {  
    public static void main(String[] args) {  
  
        // 1. 创建连接  
        Jedis jedis = new Jedis("localhost",6379);  
        jedis.auth("123qwe");  
  
        // 2. 进行操作  
        // 2.1 字符串操作  
        jedis.set("user","小相");  
        System.out.println(jedis.get("user"));  
  
        // 2.2 hash操作  
        jedis.hset("myhash","id","123");  
        System.out.println(jedis.hget("myhash","id"));  
  
        // 2.3 通用操作  
        System.out.println(jedis.keys("*"));  
  
        // 3. 关闭连接  
        jedis.close();  
    }  
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

4.3 Spring Data redis

5. Redis缓存相关问题

5.1 缓存穿透

解释概念
缓存穿透是指在一定条件下越过redis缓存直接访问数据库的情况。
潜在威胁
正常情况下，我们使用Redis的过程如下:

1. 首先查询缓存，看是否存在目标数据，若存在直接返回缓存中的数据，若不存在则进行下一步
2. 查询数据库中的数据，若存在目标数据，将目标数据返回，并将目标数据存入到缓存中，若不存在，则直接返回空置，不对缓存进行处理。
   以上这种逻辑情况看似非常正确，但是存在一个漏洞：当用户查询一个实际上并不存在的数据时，系统会直接访问数据库，在这种情况下，攻击者可利用该漏洞重复对数据库进行查询，直接对数据库进行巨大的压力，甚至导致数据库宕机。

解决办法
对于查询为空的情况，我们同样可以将其存放至redis缓存中，其值为null即可，并将该情况的生命周期设置较短时间，如60秒。这样一来，就避免了系统直接对数据库的访问问题。

5.2 缓存雪崩

解释概念
缓存雪崩指在同一时间内，缓存中大量的key失效（失效时间到了），导致同一时间访问数据库的数量激增，形成周期性的峰值，从而对数据库造成较大压力，甚至宕机。
解决办法
这种方式的解决方式很简单，即对不同的key设置不同的失效时间，避免造成峰值的现象。对于大量访问的数据，甚至可以设置永不失效！

5.3 缓存击穿

解释概念
对于一个热点数据，当缓存中的key在某一失效的瞬间，持续的大并发就直接访问数据库，对数据库造成巨大压力，就像是在缓存屏障上穿透一样，因此被称为缓存击穿。

潜在风险
瞬间对数据库进行大量的访问，数据库的压力激增，容易造成宕机。

解决方法
这种问题的解决方式比较简单，我们同样可以对这些热点数据设置 永不失效。

5.4 小结

这三种概念容易混淆，但是其侧重点不同，总结如下：

1. 缓存击穿的侧重点在于查询 数据并不存在。
2. 缓存雪崩的侧重点是 大量的key 同时失效。
3. 缓存击穿的侧重点是 一个热点的key。

6. 主从赋值 Replication

这篇文章对Redis的主从复制讲解的挺详细，作为参考 Redis的主从复制

当系统负载超过了Redis单机能够处理的上限时，我们如何进行处理？还有一种情况就是Redis进程所在的机器挂了时，我们如何处理？

以上的处理方式就是主从复制，主从复制 可以说是整个Redis高可用实现的基石。
在主从复制模式下Redis节点分为两种角色：主节点(也称为master)和从节点(也称为slave)。这种模式集群是由一个主节点和多个从节点构成。形成一主多从。slave对外提供读操作，而master负责写操作，形成一个读写分离的架构，这样一来就能够承载更多的业务请求。

Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。因此经常利用master来处理写操作，slave提供读操作。这样可以有效减少单个机器的并发访问数量。

要实现主从复制这种模式非常简单，主节点不用做任何修改，直接启动服务即可。

从节点需要修改 redis.conf 配置文件，加入配置：

slaveof <主节点ip地址> <主节点端口号>
1

例如master的ip地址为192.168.200.129，端口号为6379，那么slave只需要在redis.conf文件中配置slaveof 192.168.200.129 6379即可。
如下图：创建了一个主节点（master）和两个子节点(slave01、slave02)。

当在master中存入一个数据后，在slave01和slave02中都可以查询到。

7. 哨兵 sentinel

Redis Sentinel-深入浅出原理和实战 - 知乎 (zhihu.com)

我们现在已经给Redis实现了主从复制，可将主节点数据同步给从节点，实现了读写分离，提高Redis的性能。但是现在还存在一个问题，就是在主从复制这种模式下只有一个主节点，一旦主节点宕机，就无法再进行写操作了。也就是说主从复制这种模式没有实现高可用。

7.1 高可用

高可用(HA)是分布式系统架构设计中必须考虑的因素之一，它是通过架构设计减少系统不能提供服务的时间。保证高可用通常遵循下面几点：

1. 单点是系统高可用的大敌，应该尽量在系统设计的过程中避免单点。
2. 通过架构设计而保证系统高可用的，其核心准则是：冗余。
3. 实现自动故障转移。

7.2 Sentinel 简介

sentinel(哨兵)是用于监控redis集群中Master状态的工具，其本身也是一个独立运行的进程，能够独立运行。

Sentinel是Redis高可用的解决方案之一，本身也是分布式的架构，包含了多个Sentinel节点和多个Redis节点。而每个Sentinel节点会对Redis节点和其余的Sentinel节点进行监控。

当其发现某个节点不可达时，如果是master节点就会与其余的Sentinel节点协商。当大多数的Sentinel节点都认为master不可达时，就会选出一个Sentinel节点对master执行故障转移，并通知Redis的调用方相关的变更。

相对于**「主从」下的手动故障转移，Sentinel的故障转移是全自动的，「无需」**人工介入。

sentinel可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求，并且其余从节点开始从新的主节点复制数据。

在redis安装完成后，会有一个redis-sentinel的文件，这就是启动sentinel的脚本文件，同时还有一个sentinel.conf文件，这个是sentinel的配置文件。

7.3 Sentinel的使用

7.3.1 配置

修改sentinel的配置文件 sentinel.conf：

# 外部可以访问
bind 0.0.0.0
# 配置主节点，名称 可以随便起 最后的1表示 当多个哨兵服务时，投票数超过该数值系统 才会认为该master挂掉了
sentinel monitor mymaster 127.0.0.1 6379 1
# 设置多长时间没有反应 后认为挂掉 （ms）
sentinel down-after-milliseconds mymaster 10000
# 设置故障转移的超时时间
sentinel failover-timeout mymaster 60000
# 设置故障转移时同步的新节点数
sentinel parallel-syncs mymaster 1
1
2
3
4
5
6
7
8
9
10

参数说明：

• sentinel monitor mymaster 192.168.200.129 6379 1
mymaster 主节点名,可以任意起名，但必须和后面的配置保持一致。
  192.168.200.128 6379 主节点连接地址。
  1 将主服务器判断为失效需要投票，这里设置至少需要 1个 Sentinel 同意。
• sentinel down-after-milliseconds mymaster 10000
  设置Sentinel认为服务器已经断线所需的毫秒数。
• sentinel failover-timeout mymaster 60000
  设置failover（故障转移）的过期时间。当failover开始后，在此时间内仍然没有触发任何failover操作，当前 sentinel 会认为此次failover失败。
• sentinel parallel-syncs mymaster 1
  设置在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小，表示同时进行同步的从服务器越少，那么完成故障转移所需的时间就越长。

7.3.2 启动

启动sentinel哨兵进程，然后手动使用命令停止master节点，观察哨兵进程的输出结果

redis-sentinel sentinel01.conf
1

7.3.3 测试

故障转移的流程如下：

8. 内置集群 Cluster

8.1 Cluster简介

Redis Cluster 是Redis的内置集群，在Redis3.0推出的实现方案。在Redis3.0之前是没有这个内置集群的。Redis Cluster是无中心节点的集群架构，依靠Gossip协议协同自动化修复集群的状态。

Redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

8.2 哈希槽方式分配数据

需要注意的是，这种集群模式下集群中每个节点保存的数据并不是所有的数据，而只是一部分数据。那么数据是如何合理的分配到不同的节点上的呢？

Redis 集群是采用一种叫做哈希槽 (hash slot)的方式来分配数据的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。

假设现在有3个节点已经组成了集群，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

• 节点A覆盖0－5460

• 节点B覆盖5461－10922

• 节点C覆盖10923－16383

那么，现在要设置一个key ,比如叫my_name:

set my_name itcast
1

按照redis cluster的哈希槽算法：CRC16('my_name')%16384 = 2412。 那么就会把这个key 的存储分配到 节点A 上了。

8.3 Redis cluster的主从模式

redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会在这些从节点中选取一个来充当主节点，从而保证集群不会挂掉。
redis cluster加入了主从模式后的效果如下：