3 Redis Cluster
4.1 Redis-Cluster简介
4.1.1 什么是Redis-Cluster
为何要搭建Redis集群。Redis是在内存中保存数据的,而我们的电脑一般内存都不大,这也就意味着Redis不适合存储大数据,适合存储大数据的是Hadoop生态系统的Hbase或者是MogoDB。Redis更适合处理高并发,一台设备的存储能力是很有限的,但是多台设备协同合作,就可以让内存增大很多倍,这就需要用到集群。
Redis集群搭建的方式有多种,例如使用客户端分片、Twemproxy、Codis等,但从redis 3.0之后版本支持redis-cluster集群,它是Redis官方提出的解决方案,Redis-Cluster采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。其redis-cluster架构图如下:
客户端与 redis 节点直连,不需要中间 proxy 层.客户端不需要连接集群所有节点连接集群中任何一个可用节点即可。
所有的 redis 节点彼此互联(PING-PONG 机制),内部使用二进制协议优化传输速度和带宽.
4.1.2分布存储机制-槽
(1)redis-cluster 把所有的物理节点映射到[0-16383]slot 上,cluster 负责维护
node<->slot<->value
(2)Redis 集群中内置了 16384 个哈希槽,当需要在 Redis 集群中放置一个 key-value 时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,这样每个key 都会对应一个编号在 0-16383 之间的哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。
例如三个节点:槽分布的值如下:
SERVER1: 0-5460
SERVER2: 5461-10922
SERVER3: 10923-16383
4.1.3容错机制-投票
(1)选举过程是集群中所有master参与,如果半数以上master节点与故障节点通信超过(cluster-node-timeout),认为该节点故障,自动触发故障转移操作. 故障节点对应的从节点自动升级为主节点
(2)什么时候整个集群不可用(cluster_state:fail)?
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完成时进入fail状态.
4.2搭建Redis-Cluster
4.2.1搭建要求
需要 6 台 redis 服务器。搭建伪集群。
需要 6 个 redis 实例。
需要运行在不同的端口 7001-7006
4.2.2准备工作
(1)安装gcc 【此步省略】
Redis 是 c 语言开发的。安装 redis 需要 c 语言的编译环境。如果没有 gcc 需要在线安装。
yum install gcc-c++
(2)使用yum命令安装 ruby (我们需要使用ruby脚本来实现集群搭建)【此步省略】
yum install ruby
yum install rubygems
----- 知识点小贴士 -----
Ruby,一种简单快捷的面向对象(面向对象程序设计)脚本语言,在20世纪90年代由日本人松本行弘(Yukihiro Matsumoto)开发,遵守GPL协议和Ruby License。它的灵感与特性来自于 Perl、Smalltalk、Eiffel、Ada以及 Lisp 语言。由 Ruby 语言本身还发展出了JRuby(Java平台)、IronRuby(.NET平台)等其他平台的 Ruby 语言替代品。Ruby的作者于1993年2月24日开始编写Ruby,直至1995年12月才正式公开发布于fj(新闻组)。因为Perl发音与6月诞生石pearl(珍珠)相同,因此Ruby以7月诞生石ruby(红宝石)命名
RubyGems简称gems,是一个用于对 Ruby组件进行打包的 Ruby 打包系统
(3)将redis源码包上传到 linux 系统 ,解压redis源码包
(4)编译redis源码 ,进入redis源码文件夹
make
看到以下输出结果,表示编译成功
(5)创建目录/usr/local/redis-cluster目录, 安装6个redis实例,分别安装在以下目录
/usr/local/redis-cluster/redis-1
/usr/local/redis-cluster/redis-2
/usr/local/redis-cluster/redis-3
/usr/local/redis-cluster/redis-4
/usr/local/redis-cluster/redis-5
/usr/local/redis-cluster/redis-6
以第一个redis实例为例,命令如下
make install PREFIX=/usr/local/redis-cluster/redis-1
出现此提示表示成功,按此方法安装其余5个redis实例
(6)复制配置文件 将 /redis-3.0.0/redis.conf 复制到redis下的bin目录下
[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis-cluster/redis-1/bin
[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis-cluster/redis-2/bin
[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis-cluster/redis-3/bin
[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis-cluster/redis-4/bin
[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis-cluster/redis-5/bin
[root@localhost redis-3.0.0]# cp redis.conf /usr/local/redis-cluster/redis-6/bin
4.2.3配置集群
(1)修改每个redis节点的配置文件redis.conf
修改运行端口为7001 (7002 7003 .....)
将cluster-enabled yes 前的注释去掉(632行)
集群:
6个节点
3主
3从
1)创建6个节点 7001-7006
2)开启集群
3)串联集群[将集群链接到一起]
(2)启动每个redis实例
以第一个实例为例,命令如下
cd /usr/local/redis-cluster/redis-1/bin/
./redis-server redis.conf
把其余的5个也启动起来,然后查看一下是不是都启动起来了
[root@localhost ~]# ps -ef | grep redis
root 15776 15775 0 08:19 pts/1 00:00:00 ./redis-server *:7001 [cluster]
root 15810 15784 0 08:22 pts/2 00:00:00 ./redis-server *:7002 [cluster]
root 15831 15813 0 08:23 pts/3 00:00:00 ./redis-server *:7003 [cluster]
root 15852 15834 0 08:23 pts/4 00:00:00 ./redis-server *:7004 [cluster]
root 15872 15856 0 08:24 pts/5 00:00:00 ./redis-server *:7005 [cluster]
root 15891 15875 0 08:24 pts/6 00:00:00 ./redis-server *:7006 [cluster]
root 15926 15895 0 08:24 pts/7 00:00:00 grep redis
(3)上传redis-3.0.0.gem ,安装 ruby用于搭建redis集群的脚本。
[root@localhost ~]# gem install redis-3.0.0.gem
Successfully installed redis-3.0.0
1 gem installed
Installing ri documentation for redis-3.0.0...
Installing RDoc documentation for redis-3.0.0...
(4)使用 ruby 脚本搭建集群。
进入redis源码目录中的src目录 执行下面的命令 redis-trib.rb
ruby工具,可以实现Redis集群,create
创建集群,--replicas
创建主从关系 1:是否随机创建(是)。
./redis-trib.rb create --replicas 1 192.168.25.140:7001 192.168.25.140:7002 192.168.25.140:7003
192.168.25.140:7004 192.168.25.140:7005 192.168.25.140:7006
出现下列提示信息
>>> Creating cluster
Connecting to node 192.168.25.140:7001: OK
Connecting to node 192.168.25.140:7002: OK
Connecting to node 192.168.25.140:7003: OK
Connecting to node 192.168.25.140:7004: OK
Connecting to node 192.168.25.140:7005: OK
Connecting to node 192.168.25.140:7006: OK
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:
192.168.25.140:7001
192.168.25.140:7002
192.168.25.140:7003
Adding replica 192.168.25.140:7004 to 192.168.25.140:7001
Adding replica 192.168.25.140:7005 to 192.168.25.140:7002
Adding replica 192.168.25.140:7006 to 192.168.25.140:7003
M: 1800237a743c2aa918ade045a28128448c6ce689 192.168.25.140:7001
slots:0-5460 (5461 slots) master
M: 7cb3f7d5c60bfbd3ab28800f8fd3bf6de005bf0d 192.168.25.140:7002
slots:5461-10922 (5462 slots) master
M: 436e88ec323a2f8bb08bf09f7df07cc7909fcf81 192.168.25.140:7003
slots:10923-16383 (5461 slots) master
S: c2a39a94b5f41532cd83bf6643e98fc277c2f441 192.168.25.140:7004
replicates 1800237a743c2aa918ade045a28128448c6ce689
S: b0e38d80273515c84b1a01820d8ecee04547d776 192.168.25.140:7005
replicates 7cb3f7d5c60bfbd3ab28800f8fd3bf6de005bf0d
S: 03bf6bd7e3e6eece5a02043224497c2c8e185132 192.168.25.140:7006
replicates 436e88ec323a2f8bb08bf09f7df07cc7909fcf81
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join....
>>> Performing Cluster Check (using node 192.168.25.140:7001)
M: 1800237a743c2aa918ade045a28128448c6ce689 192.168.25.140:7001
slots:0-5460 (5461 slots) master
M: 7cb3f7d5c60bfbd3ab28800f8fd3bf6de005bf0d 192.168.25.140:7002
slots:5461-10922 (5462 slots) master
M: 436e88ec323a2f8bb08bf09f7df07cc7909fcf81 192.168.25.140:7003
slots:10923-16383 (5461 slots) master
M: c2a39a94b5f41532cd83bf6643e98fc277c2f441 192.168.25.140:7004
slots: (0 slots) master
replicates 1800237a743c2aa918ade045a28128448c6ce689
M: b0e38d80273515c84b1a01820d8ecee04547d776 192.168.25.140:7005
slots: (0 slots) master
replicates 7cb3f7d5c60bfbd3ab28800f8fd3bf6de005bf0d
M: 03bf6bd7e3e6eece5a02043224497c2c8e185132 192.168.25.140:7006
slots: (0 slots) master
replicates 436e88ec323a2f8bb08bf09f7df07cc7909fcf81
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
4.3连接Redis-Cluster
4.3.1客户端工具连接
Redis-cli 连接集群:
redis-cli -p ip地址 -p 端口 -c
-c:代表连接的是 redis 集群
测试值的存取:
(1)从本地连接到集群redis 使用7001端口 加 -c 参数
(2)存入name值为abc ,系统提示此值被存入到了7002端口所在的redis (槽是5798)
(3)提取name的值,可以提取。
(4)退出(quit)
(5)再次以7001端口进入 ,不带-c
(6)查询name值,无法获取,因为值在7002端口的redis上
(7)我们以7002端口进入,获取name值发现是可以获取的,而以其它端口进入均不能获取
4.3.2 springboot连接redis集群
(1)创建工程 ,打包方式jar包,命名为redis-demo
(3)配置application.yml
spring:
datasource:
driver-class-name: com.mysql.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/changgou_user?useUnicode=true&characterEncoding=UTF-8&serverTimezone=UTC
username: root
password: itcast
application:
name: redis-demo
#redis配置
# rabbitmq:
# addresses: 192.168.25.130:5672,192.168.25.134:5672
# username: guest
# password: guest
redis:
cluster:
nodes:
- 192.168.25.153:7001
- 192.168.25.153:7002
- 192.168.25.153:7003
- 192.168.25.153:7004
- 192.168.25.153:7005
- 192.168.25.153:7006
server:
ssl:
enabled: false
port: 9008
mybatis:
configuration:
map-underscore-to-camel-case: true
(4)创建测试类进行测试:
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.test.context.junit4.SpringRunner;
@RunWith(SpringRunner.class)
@SpringBootTest
public class ChanggouRedisDemoApplicationTests {
@Autowired
private RedisTemplate redisTemplate;
@Test
public void contextLoads() {
redisTemplate.boundValueOps("key111").set("123");
System.out.println(redisTemplate.boundValueOps("key111").get());
}
}
4.4 Redis的持久化
4.4.1 redis的持久化介绍
Redis的数据都放在内存中。如果机器挂掉,内存的数据就不存在,数据不能恢复,严重影响使用。那么redis本身给我们提供了持久化机制。即时出现这样的问题,也能恢复数据。接下来我们来看下redis的两种持久化方
4.4.2 开启RDB
RDB: 快照形式 (定期数据保存磁盘中)会产生一个dump.rdb文件,redis默认开启了RDB的持久化方式。
特点:会存在数据丢失,性能较好,用于数据备份。
如图:有一个文件产生
如图:redis.conf中 的默认的RDB的配置:
解释:
# 在 900 秒内最少有 1 个 key 被改动,或者 300 秒内最少有 10 个 key 被改动,又或者 60 秒内最少有 1000 个 key 被改动,以上三个条件随便满足一个,就触发一次保存操作。
# if(在60秒之内有10000个keys发生变化时){
# 进行镜像备份
# }else if(在300秒之内有10个keys发生了变化){
# 进行镜像备份
# }else if(在900秒之内有1个keys发生了变化){
# 进行镜像备份
# }
4.4.3 开启AOF
AOF : append only file . 所有对redis的操作命令记录在.aof文件中,如果想恢复数据,重新加载文件,执行文件中的命令即可。默认的情况下 redis没有开启,要想开启,必须配置。
特点:每秒保存,数据完整性比较好,耗费性能。
开启AOF: 如图 去掉注释
配置 AOF的执行策略:
always:总是执行
everysec:每秒钟执行(默认)
no:不执行。
如果随着时间的推移,AOF文件中的数据越来越大,所以需要进行重写也就是压缩。
如图所示:自动压缩的比例为:
100:上一次AOF文件达到100%的时候进行压缩
64mb :压缩时最小的文件大小。
4.4.4 模式的抉择应用场景介绍
AOF 和RDB对比:
命令 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
RDB的最佳策略:
- 关闭
- 集中管理(用于备份数据)
- 主从模式,从开。
AOF的最佳策略:
- 建议 开 每秒刷盘->aof日志文件中
- AOF重写集中管理
最佳的策略:
- 小分片(max_memery 4G左右)
- 监控机器的负载
4.6 Redis哨兵模式
Redis在使用过程中服务器毫无征兆的宕机,是一个麻烦的事情,如何保证备份的机器是原始服务器的完整备份呢?这时候就需要哨兵和复制。
Sentinel(哨兵)可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能,
Replication(复制)则是负责让一个Redis服务器可以配备多个备份的服务器。
Redis也是利用这两个功能来保证Redis的高可用的
4.6.1 Redis的主从复制实现高可用
如图,通过主从架构,一个主节点,两个从节点。
通过手动监控的方式,监控master的宕机,以及出现故障将故障转移的方式可以做到高可用。
比如:如果主节点宕机,我们手动监控到主节点的宕机,并将某一个Slave变成主节点。 但是这样话,如何手动监控也是很麻烦的事情。所以使用sentinel机制就可以解决了这个问题,Sentinel(哨兵)是Redis 的高可用性解决方案。
- 它能自动进行故障转移。
- 客户端连接sentinel,不需要关系具体的master。
- 当master地址改变时由sentinel更新到客户端。
架构原理如图:
1.多个sentinel 发现并确认master有问题。
2.sentinel内部选举领导
3.选举出slave作为新的master
4.通知其余的slave成为新master的slave
5.通知客户端 主从变化
6.如果老的master重新复活,那么成为新的master的slave
要实现上边的功能的主要细节主要有以下三个定时任务:
- 每10秒,哨兵会向master和slave发送INFO命令(目的就是监控每一个节点信息)
- 每2秒,哨兵会向master库和slave的频道(__sentinel__:hello)发送自己的信息 (sentinel节点通过__sentinel__:hello频道进行信息交换,比如加入哨兵集群,分享自己节点数据)
- 每1秒,哨兵会向master和slave以及其他哨兵节点发送PING命令(目的就是 redis节点的状态监控,还有领导选举,主备切换选择等)
策略总结:
1.尽量为 每一个节点部署一个哨兵
2.哨兵也要搭建集群(防止哨兵单点故障)
3.每一个节点都同时设置quorum的值超过半数(N/2)+1
面试常问的问题:
主从复制,以及哨兵 和集群之间区别。
主从复制 是redis实现高可用的一个策略。将会有主节点 和从节点,从节点的数据完整的从主节点中复制一份。
哨兵:当系统节点异常宕机的时候,开发者可以手动进行故障转移恢复,但是手动比较麻烦,所以通过哨兵机制自动进行监控和恢复。为了解决哨兵也会单点故障的问题,可以建立哨兵集群。
集群:即使使用哨兵,redis每个实例也是全量存储,每个redis存储的内容都是完整的数据,浪费内存且有木桶效应。为了最大化利用内存,可以采用集群,就是分布式存储。这个时候可以使用redis集群。将不同的数据分配到不同的节点中,这样就可以横向扩展,扩容。
4.7 redis缓存击穿问题解决
4.7.1 什么是缓存击穿
如图:
1. 当用户根据key 查询数据时,先查询缓存,如果缓存有命中,返回,
2. 但是如果缓存没有命中直接穿过缓存层,访问数据层 如果有,则存储指缓存,
3. 但是同样如果没有命中,(也就是数据库中也没有数据)直接返回用户,但是不缓存
这就是缓存的穿透。如果某一个key 请求量很大,但是存储层也没有数据,大量的请求都会达到存储层就会造成数据库压力巨大,有可能宕机的情况。
4.7.2 缓存击穿的解决方案
如图:
1.当缓存中没有命中的时候,从数据库中获取
2.当数据库中也没有数据的时候,我们直接将null 作为值设置redis中的key上边。
3.此时如果没有数据,一般情况下都需要设置一个过期时间,例如:5分钟失效。(为了避免过多的KEY 存储在redis中)
4.返回给用户,
5.用户再次访问时,已经有KEY了。此时KEY的值是null而已,这样就可以在缓存中命中,解决了缓存穿透的问题。
(2)例如:代码如下:
注意:缓存空对象会有两个问题:
第一,空值做了缓存,意味着缓存层中存了更多的键,需要更多的内存空间 ( 如果是攻击,问题更严重 ),比较有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。
第二,缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。例如过期时间设置为 5分钟,如果此时存储层添加了这个数据,那此段时间就会出现缓存层和存储层数据的不一致,此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
4.8 Redis缓存雪崩问题解决(作业)
4.8.1 什么是缓存雪崩
如果缓存集中在一段时间内失效,发生大量的缓存穿透,所有的查询都落在数据库上,造成了缓存雪崩。
4.8.2 如何解决
这个没有完美解决办法,但可以分析用户行为,尽量让失效时间点均匀分布。
- 限流 加锁排队
在缓存失效后,通过对某一个key加锁或者是队列 来控制key的线程访问的数量。例如:某一个key 只允许一个线程进行 操作。
- 限流
在缓存失效后,某一个key 做count统计限流,达到一定的阈值,直接丢弃,不再查询数据库。例如:令牌桶算法。等等。
- 数据预热
在缓存失效应当尽量避免某一段时间,可以先进行数据预热,比如某些热门的商品。提前在上线之前,或者开放给用户使用之前,先进行loading 缓存中,这样用户使用的时候,直接从缓存中获取。要注意的是,要更加业务来进行过期时间的设置 ,尽量均匀。
- 做缓存降级(二级缓存策略)
当分布式缓存失效的时候,可以采用本地缓存,本地缓存没有再查询数据库。这种方式,可以避免很多数据分布式缓存没有,就直接打到数据库的情况。
4.8.3二级缓存解决雪崩的案例
分析:
基本的思路:通过redis缓存+mybatis的二级缓存整合ehcache来实现。
EhCache 是一个纯Java的进程内缓存框架,具有快速、精干等特点,是Hibernate中默认的CacheProvider。
(1)在原来的工程中加入依赖
<dependency>
<groupId>org.mybatis.caches</groupId>
<artifactId>mybatis-ehcache</artifactId>
<version>1.1.0</version>
</dependency>
(2)创建dao的接口 使用XML的方式
@Mapper
public interface TbUserMapper {
/**
* 根据用户名查询用户的信息
* @param username
* @return
*/
public TbUser findOne(String username);
}
(3)创建TbUserMapper.xml,如图加入echache的配置 开启二级缓存
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper
PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
"http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.itheima.changgouredisdemo.dao.TbUserMapper">
<!--加入使用缓存-->
<cache type="org.mybatis.caches.ehcache.EhcacheCache">
<!--缓存自创建日期起至失效时的间隔时间一个小时-->
<property name="timeToIdleSeconds" value="3600"/>
<!--缓存创建以后,最后一次访问缓存的日期至失效之时的时间间隔一个小时-->
<property name="timeToLiveSeconds" value="3600"/>
<!--设置在缓存中保存的对象的最大的个数,这个按照业务进行配置-->
<property name="maxEntriesLocalHeap" value="1000"/>
<!--设置在磁盘中最大实体对象的个数-->
<property name="maxEntriesLocalDisk" value="10000000"/>
<!--缓存淘汰算法-->
<property name="memoryStoreEvictionPolicy" value="LRU"/>
</cache>
<select id="findOne" resultType="com.itheima.changgouredisdemo.pojo.TbUser" parameterType="string">
SELECT * from tb_user where username = #{username}
</select>
</mapper>
(4)配置application.yml
mybatis:
configuration:
map-underscore-to-camel-case: true
# 指定mapper映射文件目录
mapper-locations: classpath:mapper/*Mapper.xml
(5)创建controller service 来进行测试:
package com.itheima.changgouredisdemo.controller;
import com.itheima.changgouredisdemo.pojo.TbUser;
import com.itheima.changgouredisdemo.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
/**
* 描述
*
* @version 1.0
* @since 1.0
*/
@RestController
@RequestMapping("/user")
public class UserController {
@Autowired
private UserService userService;
@RequestMapping("/findOne/{username}")
public TbUser findOne(@PathVariable String username) {
return userService.findOne(username);
}
}
import com.itheima.changgouredisdemo.dao.TbUserMapper;
import com.itheima.changgouredisdemo.pojo.TbUser;
import com.itheima.changgouredisdemo.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;
/**
* 描述
*
* @since 1.0
*/
@Service
public class UserServiceImpl implements UserService {
@Autowired
private TbUserMapper userMapper;
@Autowired
private RedisTemplate redisTemplate;
@Override
public TbUser findOne(String username) {
TbUser user = (TbUser) redisTemplate.boundValueOps(username).get();
if (redisTemplate.hasKey(username)) {
return user;
} else {
//没有key 数据库中查询
TbUser one = userMapper.findOne(username);
System.out.println("第一次查询数据库");
redisTemplate.boundValueOps(username).set(one);
if (one == null) {
redisTemplate.expire(username, 30, TimeUnit.SECONDS);
}
return one;
}
}
}
(6)测试:
已知: 数据库中有zhangsan
准备好redis
浏览器输入
http://localhost:9008/user/findOne/zhangsan
效果:
redis中: 也有数据
此时:修改数据库的数据zhangsan为zhangsan5,并清空redis缓存。
再次输入浏览器地址:
http://localhost:9008/user/findOne/zhangsan
此时数据库总已经没有zhangsan,但是效果却是
说明数据从二级缓存中也就是本地缓存中获取到了,测试成功。