Redis,REmote DIctionary Server(远程字典服务器)是完全开源免费的,用C语言编写的,遵守BSD协议,是一个高性能的(key-value)分布式内存
数据库,基于内存运行并支持持久化的NoSQL数据库,是当前最热门的NoSql数据库之一,也被人们称为数据结构服务器。
Redis 与其他 key - value 缓存产品有以下三个特点:
官网: http://redis.io/
中文官网:http://www.redis.cn/
redis-server
后台式启动redis服务
sudo service redis-server start
连接redis服务
redis-cli
//etc/redis/redis.conf
requirepass 123qwe
通常用作任务队列
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();
}
}
解释概念
缓存穿透是指在一定条件下越过redis缓存直接访问数据库的情况。
潜在威胁
正常情况下,我们使用Redis的过程如下:
解决办法
对于查询为空的情况,我们同样可以将其存放至redis缓存中,其值为null即可,并将该情况的生命周期设置较短时间,如60秒。这样一来,就避免了系统直接对数据库的访问问题。
解释概念
缓存雪崩指在同一时间内,缓存中大量的key失效(失效时间到了),导致同一时间访问数据库的数量激增,形成周期性的峰值,从而对数据库造成较大压力,甚至宕机。
解决办法
这种方式的解决方式很简单,即对不同的key设置不同的失效时间,避免造成峰值的现象。对于大量访问的数据,甚至可以设置永不失效!
解释概念
对于一个热点数据,当缓存中的key在某一失效的瞬间,持续的大并发就直接访问数据库,对数据库造成巨大压力,就像是在缓存屏障上穿透一样,因此被称为缓存击穿。
潜在风险
瞬间对数据库进行大量的访问,数据库的压力激增,容易造成宕机。
解决方法
这种问题的解决方式比较简单,我们同样可以对这些热点数据设置 永不失效。
这三种概念容易混淆,但是其侧重点不同,总结如下:
这篇文章对Redis的主从复制讲解的挺详细,作为参考 Redis的主从复制
当系统负载超过了Redis单机能够处理的上限时,我们如何进行处理?还有一种情况就是Redis进程所在的机器挂了时,我们如何处理?
以上的处理方式就是主从复制,主从复制
可以说是整个Redis高可用实现的基石。
在主从复制模式下Redis节点分为两种角色:主节点(也称为master)
和从节点(也称为slave)
。这种模式集群是由一个主节点和多个从节点
构成。形成一主多从。slave对外提供读操作,而master负责写操作,形成一个读写分离的架构,这样一来就能够承载更多的业务请求。
Master会将数据同步到slave,而slave不会将数据同步到master。Slave启动时会连接master来同步数据。因此经常利用master来处理写操作,slave提供读操作。这样可以有效减少单个机器的并发访问数量。
要实现主从复制这种模式非常简单,主节点不用做任何修改,直接启动服务即可。
从节点需要修改 redis.conf
配置文件,加入配置:
slaveof <主节点ip地址> <主节点端口号>
例如master的ip地址为192.168.200.129,端口号为6379,那么slave只需要在redis.conf文件中配置slaveof 192.168.200.129 6379
即可。
如下图:创建了一个主节点(master)和两个子节点(slave01、slave02)。
当在master中存入一个数据后,在slave01和slave02中都可以查询到。
Redis Sentinel-深入浅出原理和实战 - 知乎 (zhihu.com)
我们现在已经给Redis实现了主从复制,可将主节点数据同步给从节点,实现了读写分离,提高Redis的性能。但是现在还存在一个问题,就是在主从复制这种模式下只有一个主节点,一旦主节点宕机,就无法再进行写操作了。也就是说主从复制这种模式没有实现高可用。
高可用(HA)是分布式系统架构设计中必须考虑的因素之一,它是通过架构设计减少系统不能提供服务的时间。保证高可用通常遵循下面几点:
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的配置文件。
修改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
参数说明:
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 failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
启动sentinel哨兵进程,然后手动使用命令停止master节点,观察哨兵进程的输出结果
redis-sentinel sentinel01.conf
Redis Cluster
是Redis的内置集群,在Redis3.0推出的实现方案。在Redis3.0之前是没有这个内置集群的。Redis Cluster是无中心节点的集群架构,依靠Gossip协议协同自动化修复集群的状态。
Redis cluster在设计的时候,就考虑到了去中心化,去中间件,也就是说,集群中的每个节点都是平等的关系,都是对等的,每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接,而且这些连接保持活跃,这样就保证了我们只需要连接集群中的任意一个节点,就可以获取到其他节点的数据。
需要注意的是,这种集群模式下集群中每个节点保存的数据并不是所有的数据,而只是一部分数据。那么数据是如何合理的分配到不同的节点上的呢?
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
按照redis cluster的哈希槽算法:CRC16('my_name')%16384 = 2412
。 那么就会把这个key 的存储分配到 节点A 上了。
redis cluster 为了保证数据的高可用性,加入了主从模式,一个主节点对应一个或多个从节点,主节点提供数据存取,从节点则是从主节点拉取数据备份,当这个主节点挂掉后,就会在这些从节点中选取一个来充当主节点,从而保证集群不会挂掉。
redis cluster加入了主从模式后的效果如下: