一、引言
1.1 数据库压力过大
由于用户量增大,请求数量也随之增大,数据压力过大
1.2 数据不同步
多台服务器之间,数据不同步
1.3 传统锁失效
多台服务器之间的锁,已经不存在互斥性了
二、Redis介绍
2.1 关于关系型数据库和NOSQL数据库(键值对存储)
关系型数据库是基于关系表的数据库,最终会将数据持久化到磁盘上,而nosql数据库是基于特殊的结构,并将数据存储到内存的数据库。从性能上而言,nosql数据库要优先于关系型数据库,从安全性上来讲,关系型数据库要优先于nosql数据库,所以在实际开发中一个项目中nosql和关系型数据库会一起使用,达到性能和安全性的双保证。
NOSQL产品: redis,mongodb,memcached...
Redis就是一款NoSQLs's
NoSQL -> 非关系型数据库 -> Not Only SQL。
Key-Value:Redis ...
文档型:ElasticSearch,Solr,Mongodb ...
面向列:Hbase,Cassandra ...
图形化:Neo4j ...
除了关系型数据库都是非关系型数据库
NoSQL只是一种概念,泛指非关系型数据库,和关系型数据库做一个区分
2.2 Redis介绍
有一位意大利人,在开发一款LLOOGG的统计页面,因为MySQL的性能不好,自己研发了一款非关系型数据库,并命名为Redis。Salvatore。
Redis(Remote Dictionary Server)即远程字典服务,Redis是由C语言去编写,Redis是一款基于Key-Value的NoSQL,而且Redis是基于内存存储数据的,Redis还提供了多种持久化机制,性能可以达到110000/s读取数据以及81000/s写入数据,Redis还提供了主从,哨兵以及集群的搭建方式,可以更方便的横向扩展以及垂直扩展。
三、Redis 安装
3.1 安装Redis
官网:Redis
中文网:Redis中文网
官网提供安装方式如下:(安装redis编译的c环境,此步骤没有编译)
Installation
Download, extract and compile Redis with:
$ wget <http://download.redis.io/releases/redis-5.0.5.tar.gz >
$ tar xzf redis-5.0.5.tar.gz $ cd redis-5.0.5
$ make
The binaries that are now compiled are available in the src directory. Run Redis with:
$ src/redis-server
You can interact with Redis using the built-in client:
$ src/redis-cli
redis> set foo bar
OK
redis> get foo
"bar"
3.2 安装步骤
3.2.1 把下载好的redis-6.2.6.tar.gz安装包拷贝到当前虚拟机的root目录下,解压到/usr/local目录下
[root@localhost ~]# tar -zxvf redis-6.2.6.tar.gz -C /usr/local
3.2.2 编译的c环境
[root@localhost ~]# yum install gcc-c++
输入y
3.2.3 进入reids-6.2.6目录,使用make命令编译redis(若报错,先make distclean ,在make)
[root@localhost redis-5.0.4]# make
3.2.4 使用make PREFIX=/usr/local/redis-6.2.6 install命令安装(安装后会出现bin目录)
[root@localhost redis-5.0.4]# make PREFIX=/usr/local/redis-6.2.6 install
3.2.5 启动redis服务端(前台启动)
[root@localhost redis-5.0.4]# cd bin
[root@localhost bin]# ./redis-server
启动后看到如上欢迎页面,但此窗口不能关闭,窗口关闭就认为redis也关闭了,所以我们需要在后台启动,然后再启动客户端进行连接,所以首先按Ctrl+c退出
解决:可以通过修改配置文件redis的后台启动(即服务器启动了但不会创建控制台窗口)
步骤如下:
1.切换到redis-6.2.6目录下,把当前目录下的redis.conf文件拷贝到bin目录下
[root@localhost bin]# cd ../
[root@localhost redis-5.0.4]# cp redis.conf bin/redis.con
2.切换到bin目录下,修改redis.conf文件
[root@localhost redis-5.0.4]# cd bin
[root@localhost bin]# vim redis.con
3.将redis.conf文件中的daemonize的值从no修改成yes表示后台启动
4.启动redis服务端(后台启动)
[root@localhost bin]# ./redis-server redis.conf
5.查看是否启动成功
[root@localhost bin]# ps -ef | grep redis
6.启动客户端
[root@localhost bin]# ./redis-cli
7.存取数据进行测试
127.0.0.1:6379> set name jack
OK
127.0.0.1:6379> get name
"jack"
127.0.0.1:6379>
四、redis-benchmark官方自带的性能测试工具
4.1 在安装的redis中可以看到redis-benchmark
4.2 关于redis-benchmark的一些参数
简单测试:100个并发,十万个请求,单机测试
[root@localhost bin]# ./redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000
参数解释:
====== PING_INLINE ======
100000 requests completed in 0.84 seconds 表示对十万个请求进行写入测试
100 parallel clients 100个并发客户端
3 bytes payload 每次写入3个字节
keep alive: 1 只有一台服务器处理请求(单机性能)
99.36% <= 1 milliseconds
99.96% <= 2 milliseconds
100.00% <= 2 milliseconds 请求在3毫秒处理完成
119047.62 requests per second 每秒处理119047.62次请求
./redis-benchmark -h 127.0.0.1 -p 6379 -t set,lpush -n 10000 -q:此命令表示只测试set和lpush方式并退出
五、Redis的数据类型
常用的5种数据结构:
key-string:一个key对应一个值
key-hash:一个key对应一个map
key-list:一个key对应一个列表
key-set:一个key对应一个集合
key-zset:一个key对应一个有序的集合
另外三种数据结构:
HyperLogLog:计算近似值的。
GEO:地理位置。
BIT:一般存储的也是一个字符串,存储的是一个byte[]。
redis是一种高级的key-value的存储系统,其中的key是字符串类型,尽可能满足如下几点:
1.key不要太长,最好不要操作1024个字节,这不仅会消耗内存还会降低查找效率
2.key不要太短,如果太短会降低key的可读性
3.在项目中,key最好有一个统一的命名规范(根据企业的需求)
value最常用的五种数据类型:
1.字符串(String):最常用的,一般用于存储一个值
2.列表(List):使用list结构实现栈和队列结构
3.集合(Set):交集,差集和并集的操作
4.有序集合(sorted set):排行榜,积分存储等操作
5.哈希(Hash):存储一个对象数据的
5.1 字符串(String)
set key value:设定key持有指定的字符串value,如果该key存在则进行覆盖操作,总是返回”ok、“
get key:获取key的value。如果与该key关联的value不是Strig类型,redis将返回错误信息,因为
get命令只能用于获取String value,如果该key不存在,返回null
getset key value:先获取该key的值,然后在设置该key的值
incr key:将指定的key的value原子性的递增1,如果该key不存在,其初始化值为0,在incr之后其值为1.如果value的值不能转成整型,如hello,该操作将执行失败并返回相应的错误信息
decr key:将指定的key的value原子性的递减1,如果该key不存在,其初始化值为0,在incr之后其值为-1.如果value的值不能转成整型,如hello,该操作将执行失败并返回相应的错误信息。
incrby key increment:将指定的key的value原子性增加increment,如果该key不存在,其初始值为0,在decrby之后,该值为increment。如果该值不能转成整型,如hello则失败并返回错误信息
decrby key decrement:将指定的key的value原子性减少decrement,如果该key值不存在,其初始化值为0,在decrby之后,该值为decrement。如果该值不能转换为整型,如hello则失败并返回错误信息。
append key value:如果该key存在,则在原有的value后追加该值,如果该key不存在,则重新创建一个key/value
setex key seconds value:设置key以及对应的value,还可以设置过期时间
setnx key value:当key不存在时,设置对应的value,当key存在时,不做任何操作
使用场景如下:
1.简单的缓冲存储(最常用)
2.消息的失效性(过期时间的设置)
3.分布式锁的实现(redisson)
5.2 列表(List)
lpush key value1 value2...:在指定的key所关联的list的头部插入所有的values,如果该key不存在,该命令在插入的之前创建一个该key关联的空链表,之后再向该链表头部插入数据。插入成功,返回元素的个数。
rpush key value1 value2...:在该list的尾部添加元素。
lrange key start end:获取链表中从start到end的元素的值,start、end可以为负数,若为-1则表示链表尾部的元素,-2则表示倒数第二个,依次类推...
lpushx key value:当key存在时,在头部插入value,否则将不插入
rpushx key value:在key的尾部插入value
lpop key:返回并弹出指定的key关联的链表中的第一个元素,即头部元素。
rpop key:从尾部弹出元素
rpoplpush resource destination:将链表中的尾部元素弹出并添加到头部
llen key:返回指定的key关联的链表中的元素的数量
lset key index value:设置链表中的index的脚本的元素值,0代表链表的头元素,-1代表链表的尾元素
lrem key count value:删除count个值为value的元素,如果count大于0,从头向尾遍历并删除count个值为value的元素,如果count小于0,则从尾向头遍历并删除。如果count等于0,则删除链表中所有等于value的元素。
linsert key before | after pivot value:在pivot元素前或则后插入value这个元素
使用场景如下:
消息流的场景:
1.用户的id作为key,发送的消息作为value,例如:朋友圈发布,微博发布,公众号发布...
5.3 集合(set,不允许出现重复的元素)
sadd key value1 value2....:向set中添加数据,如果该key的值已有则不会重复添加
smembers key:获取set中所有的成员
scard key:获取set中成员的数量
sismember key member:判断参数中指定的成员是否在该set中,1表示存在,0表示不存在或则该key本身就不存在
srem key member1 member2.....:删除set中指定的成员
srandmember key:随机返回set集合中的一个成员
sdiff key1 key2:返回key1与key2 中相差的成员,而且与key的顺序有关,即返回差集
sdiffstore destination key1 key2:将key1、key2相差的成员存储在destination上
sinter key[key1,key2...] : 返回交集
sinterstore destination key1 key2:将返回的交集存储在destination上
sunion key1 key2 :返回并集
sunionstore destination key1 key2:将返回的并集存储在destination上
使用场景如下:
公司年会,随机抽奖小程序
1.把所有用户统一存入set集合中
2.查看所有抽奖人数
3.随机抽取指定得奖人数并从set集合删除
实现:
1.sadd choujiang userid1,userid2,userid3...
2.smembers choujiang
3.spop choujiang [count]
微信点赞,微博收藏
1.点赞,创建集合并加入对应用户
2.取消点赞,从集合中删除对应用户
3.检查用户是否点过赞
4.获取点赞用户列表
5.获取点赞用户数量
实现:
1.sadd dianzan userid1,userid2....
2.srem dianzan userid1
3.sismember dianzan userid1
4.smembers dianzan
5.scard dianzan
可能认识的人推荐
1.两个集合取交集
实现:
1.sinter userid1list , userid2list...
2.sinterstore list userid1list , userid2list....
5.4 有序集合(sorted set)
zadd key score member score2 member2 ....:将所有成员以及该成员的分数存放到sorted-set中
zcard key:获取集合中的成员数量
zcount key min max:获取分数在[min,max]之间的成员
zincrby key increment member:设置指定成员的增加的分数
zrange key start end [withscores]:获取集合中脚标为start-end的成员,[withscores]参数表明返回的成员包含其分数
zrangebystore key min max withscores:返回分数在[min,max]的成员并按照分数从低到高排序。[withscores]:显示分数;[limit offset count]:offset,表明从角标为offset的元素开始并返回count个成员
zrank key member:返回成员在集合中的位置
zrem key member[member....]:移除集合中指定的成员,可以指定多个成员
zscore key member:返回指定成员的分数
使用场景如下:
排行榜实现:
1.对播放的视频,分数自增1
2.展示排行榜前十的视频
实现:
1.zincrby videos 1 videoid
2.zrevrangebyscore videos 100 0 withscores limit 0 9(zrevrangebyscore从小到大排序)
5.5 哈希(Hash)
hset key field value:为指定的key设定field/value对(键值对)。
hgetall key:获取key中的所有field-value。
hget key field:返回指定的key中的field的值。
hmset key fields:设置key中的多个field/value。
hmget key fields:获取key中的多个field的值。
hexists key field:判断指定的key中的field是否存在。
hlen key:获取key中所包含的field的数量
hincrby key field increment:设置key中field的值增加increment,如:age增加20
使用场景如下:
购物车场景:
1.用户的id作为key
2.商品的id作为field(属性)
3.商品的数量作为value(属性值)
购物车操作:
1.用户添加购物车:hset cart:1001 20001 1(id为1001的用户添加了一个id为20001的商品,数量为1个)
2..增加商品的数量:hincrby cart:1001 20001 1
3.查询商品的总数:hlen cart:1001
4.删除该用户的某个商品:hdel cart:1001 20001
5.查询该用户购物车信息:hgetall cart:1001
5.6 通用操作
keys patten:获取所有与patten匹配的key,*表示任意字符,?表示一个字符
del key1 key2....:删除指定的key
exists key:判断该key是否存在,1表示存在,0表示不存在。
rename key newkey:为当前key重命名
expire key second:为当前key设置过期时间(单位:秒)
ttl key:查看当前key剩余过期时间
type key:查看当前key类型
flushall:删除所有的key
六、Jedis的使用
1.修改/usr/local/redis-6.2.6/bin目录下的redis.conf配置文件,然后启动redis服务端
将绑定127.0.0.1注释掉,然后把保护模式关掉
如需设置密码,可以使用以下两种方式
方式一:通过修改redis.conf文件,设置Redis的密码校验requirepass密码
方式二:在不修改redis.conf文件的前提下,在第一次链接Redis时,输入命令:Config set requirepass 密码
后续连接redis客户端的时候,需要先AUTH做以下校验
127.0.0.1:6379>auth 密码
2.创建maven工程,导入依赖
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.58</version>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
</dependency>
3.编写实体类
@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
private Integer uid;
private String username;
private String password;
}
4.编写测试类
package com.qf.jedis;
import org.junit.Test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
public class JedisDemo {
// 通过java程序访问redis数据库
// 获得单一的jedis对象操作数据库
@Test
public void test1() {
//获得连接对象
Jedis jedis = new Jedis("192.168.153.132", 6379);
//认证密码
//jedis.auth("root");
//获得之前redis中存储的数据
String name = jedis.get("name");
System.out.println(name);
//存储数据
jedis.set("password", "123");
System.out.println(jedis.get("password"));
//关闭
jedis.close();
}
//通过jedis的pool获得jedis连接对象
@Test
public void test2() {
// 创建池子的配置对象
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxIdle(30);// 最大闲置个数
poolConfig.setMinIdle(10);// 最小闲置个数
poolConfig.setMaxTotal(50);// 最大连接数
// 创建一个redis的连接池
JedisPool pool = new JedisPool(poolConfig, "192.168.153.132", 6379);
// 从池子中获取redis的连接资源
Jedis jedisPoolResource= pool.getResource();
// 创建User类进行存储
User user = new User(1001, "李四", "123");
// 将对象转换成json存储
jedisPoolResource.set("user", JSON.toJSONString(user));
String db_user = jedisPoolResource.get("user");
// 返回json数据
System.out.println(db_user);
// 返回User类型
System.out.println(JSON.parseObject(db_user,User.class));
// 关闭资源
jedis.close();
pool.close();
}
}
七、Redis中的事务
Redis中的事务和MySQL中的事务有本质的区别,Redis中的事务是一个单独的隔离操作,事务中的所有的命令都会序列化,按照顺序执行,事务在执行的过程中,不会被其他客户端发来的命令所打断,因为Redis服务端是个单线程的架构(Redis5.x版本,Redis6.x及以上版本是多线程),不同的Client虽然看似可以同时保持连接,但发出的命令是序列化执行的,这在通常的数据库理论下是最高级别的隔离。
Redis中的事务的作用就是串联多个命令,防止别的命令插队。
常用的命令:multi、exec、discard、watch、unwatch
当输入multi命令时,之后输入的命令都会被放在队列中,但不会执行,直到输入exec后,Redis会将队列中的命令依次执行,discard用来撤销exec之前被暂存的命令,并不是回滚。
watch/unwatch
在执行 multi之前,先执行watch key1[key2....],watch提供的乐观锁功能(初始时一个版本号,exec之后会更新当前版本号),在你exec的那一刻,如果被watch的键发生改动,则multi到exec之间的指令全部不执行。
watch表示监控,相当于加锁,但在执行完exce时就会解锁。
unwatch取消所有锁。
Redis中的事务的特性总结
1.单独的隔离操作
事务中的所有命令都会序列化,然后按顺序执行,在执行过程中,不会被其他客户端发送的命令打断
2.没有隔离级别的概念
队列中的命令没有提交之前都不会执行。
3.不能保证原子性
Redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,不会回滚
八、Redis中的持久化
Redis有两种持久化的方式:RDB和AOF
8.1 RDB(Redis DataBase)
将内存中的数据以快照的方式写入到磁盘中,在redis.conf文件中,我们可以找到如下配置:
save 900 1
save 300 10
save 30 1000
配置含义:
900秒内,如果超过1个key被修改,则发起快照保存
300秒内,如果超过10个key被修改,则发起快照保存
60秒内,如果超过1万个key被修改,则发起快照保存
RDB方式存储的数据会在dump.rdb文件中(在哪个目录启动redis服务端,该文件就会在对应目录下生成),该文件不能查看,如需备份,对Redis操作完成之后,只需要拷贝该文件即可(Redis服务端启动时会自动加载该文件)
8.2 AOF(Append of File)
AOF默认是不开启的,需要手动开启,同样是在redis.conf文件中开启,如下:
配置文件中的appendonly修改为yes,开启AOF持久化。开启后,启动redis服务端,发现多了一个appendonly.aof文件
之后的任何操作都会保存在appendonly.aof文件中,可以进行查看,Redis启动时会将appendonly.aof文件中的内容执行一遍
如果AOF和RDB同时开启,系统会默认读取AOF的数据
8.3 总结
RDB优点与缺点
优点:
如果要进行大规模数据的恢复,RDB方式要比AOF方式恢复速度要快。
RDB是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适合用作备份,同时也非常适合用作灾难性恢复,它只有一个文件,内容紧凑,通过备份原文件到本机外的其它主机上,一旦主机发生宕机,就能将备份文件复制到redis安装目录下,通过启用服务器就能完成数据的恢复。
缺点:
RDB这种持久化方式不太适应对数据完整性要求严格的情况,因为,尽管我们可以用修改快照实现持久化的频率,但是要持久化的数据是一段时间内的整个数据集的状态,如果在还没有触发快照时,本机就宕机了,那么对数据库所做的写操作就随之而消失了并没有持久化本地dump.rdb文件中
AOF优点与缺点
优点:
AOF有着多种持久化策略:
appendfsync always:每修改同步,每一次发生数据变更都会持久化到磁盘上,性能较差,但数据完整性较好
appendfsync everysec:每秒同步,每秒内记录文件,异步操作,如果一秒内宕机,有数据丢失
appendfsync no:不同步
AOF文件是一个只进行追加操作的日志文件,对文件写入不需要进行seek,即使在追加的过程中,写入了不完整的命令(例如:磁盘已满),可以使用redis-check-aof工具可以修复这种问题
Redis可以在AOF文件变得过大时,会自动地在后台对AOF进行重写:重写后的新的AOF文件包含了恢复当前数据集所需的最小命令的集合。整个重写操作是绝对安全的,因为Redis在创建AOF文件的过程中,会继续将命令追加到现有的AOF文件中,即使在重写的过程中发生宕机,现有的AOF文件也不会丢失。一旦新的AOF文件创建完毕,Redis就会从旧的AOF文件切换到新的AOF文件,并对新的AOF文件进行追加操作。
缺点:
对于相同数据集来说,AOF文件要比RDB文件大
根据所使用的持久化策略来说,AOF的速度要慢于RDB。一般情况下,每秒同步策略效果最好。不使用同步策略的情况下,AOF与RDB速度一样块。
九、Redis的消息订阅与发布
subscribe channel 订阅频道 例如:subscribe cctv5
publish channel content 在指定频道中发布内容,例如:publish cctv5 basketball
同时打开两个客户端,一个订阅频道,一个在频道中发布内容,订阅频道的客户端会接收到消息
十、使用Redis图像化程序界面
Redis中默认有16个库,可以在不同的库中存储数据,默认使用0号库存储数据,使用select 0-15可以选择不同的库
安装之后,输入IP地址登录即可看到如下界面:(连接前需要注释掉bind 127.0.0.1)
十一、Redis的主从复制
主从复制是将一台redis服务器的数据,复制到其它的redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到单节点。
默认情况下,每台redis服务器都是主节点,且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能由一个主节点。
主从复制的作用:
1.数据冗余,主从复制实现了数据的热备份,是持久化的一种数据冗余方式
2.故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复,但实际上是一种服务的冗余
3.负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读操作(即写redis数据时应用连接主节点,读redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
4.高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是redis高可用的基础。
配置步骤:
1、查看当前库信息:
127.0.0.1:6379>info replication
2.关闭当前运行的redis,打开四个链接,进行测试,拷贝三个redis.conf文件(改成6379 6380 6381)
3.分别修改这三个文件信息,需要修改:端口号,pid名字,log文件名字,dump.rdb名字
port 6379
pidfile/var/run/redis-6379.pid
logfile "6379.log"
dbfilename dump.6379.rdb
port 6380
pidfile/var/run/redis-6380.pid
logfile "6380.log"
dbfilename dump6380.rdb
port 6381
pidfile/var/run/redis-6381.pid
logfile "6381.log"
dbfilename dump6381.rdb
4.分别在三链接中启动6379 6380 6381三台redis-server,在第四个链接中查看
查看状态
5.配置一主二从
默认情况下,每台redis都是主节点,我们只需要配置从机即可,我们这里使用6379为主机,6380和6381为从机。。
在对应的6380的链接中进行配置:
[root@localhost bin]# ./redis-cli -p 6380
127.0.0.1:6380> slaveof 127.0.0.1 6379
6380从机配置成功之后,可以去主机中查看对应消息
6381从机配置方式和6380一样,配置成功之后,可以再去看一下主机
6.由于这里使用的是命令进行配置的,所以是暂时的,一般公司配置会在配置文件中配置,属于永久性配置,相当于一打开当前服务器,该服务器就是从机,一般主机可以写,从机只能读不能写,主机中的所有的信息和数据都会被从机保存!
即使主机断开连接(127.0.0.1:6379>shutdown),从机仍然可以连接到主机,如果使用的是命令行配置的从机,从机一旦断开连接后,就会变回主机了,如果再次变回从机,仍旧可以获取主机中的值
如果主机断开连接,从机可以使用命令:127.0.0.1:6380>slaveof no one使自己称为主机
7.主从复制原理
Slave启动成功连接到master后会发送一个sync同步命令,Master接到命令后,会启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕后,master将传送整个数据文件到slave,并完成依次完整的同步。
全量复制:slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制:master继续将新的所有收集到的修改命令依次传递给salve,完成同步。
十二、Redis的哨兵模式
当主服务器宕机后,并且我们并没有及时发现,这时候就可能会出现数据丢失或程序无法执行。此时,redis的哨兵模式就派上用场了,可以用它来做redis的高可用。
每个哨兵都是监控主节点,主节点宕机,哨兵不会宕机!
功能作用:
1.监控(monitoring):Sentinel会不断地检查你的主服务器和从服务器是否运行正常。
2.提醒(Notifation):当被监控的某个redis服务器出现问题时,Sentinel可以通过API向管理员或者其它应用程序发送通知。
3.自动故障转移(Automatic failover):当一个主服务器不能正常工作时,Sentinel会开始一次自动故障迁移操作,它会将失效的主服务器中的一个从服务器升级为新的主服务器,并让失效的主服务器的其它从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器替代失效服务器。
配置步骤:
1.创建哨兵配置文件
[root@localhost bin]# vim sentinel.conf
sentinel.conf文件内容如下:(格式:sentinel monitor被监控名称host port 1)
sentinel monitor myredis 127.0.0.1 6379 1
注意:后面的数字1表示有1个sentinel认为1个master失效时,master就算真正失效,slave会以投票的方式选取主机
2.启动哨兵
[root@localhost bin]# ./redis-sentinel sentinel.conf
3.如果Master节点断开了(主机宕机了),过一会,会发送哨兵日记,并自动通过算法在其它两个从机中选择一个称为主机。
如果之前的主机6379又重新启动了,过一会,哨兵检测到了之后,会把6379设置为从机!
哨兵模式的优缺点
优点
1.哨兵集群模式是基于主从模式的,所有主从的优点,哨兵模式同样具有。
2.主从可以切换,故障可以转移,系统可用性更好。
3.哨兵模式是主从模式的升级,系统更健壮,可用性更高。
缺点
1.Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。
2.实现哨兵模式的配置也不简单,甚至可以说有些繁琐
十三、Redis缓冲穿透,击穿,雪崩,倾斜
1.1缓冲穿透(查不到)
概念:当用户去查询数据的时候,发现redis内存数据库中没有,于是向持久层数据库查询,发现也没有,于是查询失败,当用户过多时,缓冲都没有查到,于是都去查持久层数据库,这会给持久层数据库造成很大压力,此时相当于出现了缓冲穿透。
解决方案:
1.布隆过滤器:是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的压力
2.缓冲空对象:当存储层查不到时,即使返回的空对象也将其缓冲起来,同时设置一个过期时间,之后再 访问这个数据将会从缓冲数据库中获取,保护后端数据。
但会有两个问题:
1.如果空值被缓冲起来,就意味着需要更多的空间存储更多的键,会有很多空值的键。
2.即使对空值设置了过期时间,还是会存在缓冲层和存储层会有一段时间窗口不一致,这对于需要保持一致性的业务会有影响
1.2 缓冲击穿(访问量大,缓冲过期)
指对某一个key的频繁访问,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就会直接请求数据库,就像在屏幕上凿开一个洞,例如微博由于某个热搜导致宕机。
其实就是:当某个key在过期的瞬间,有大量的请求并发访问,这类数据一段是热点数据,由于缓冲过期,会同时访问数据库来查询最新数据,并回写缓冲,导致数据库瞬间压力过大。
解决方案:
1.设置热点数据永不过期:从缓冲方面上来说,不设置过期时间,就不会出现热点key过期后产生的问题。
2.添加互斥锁:使用分布式锁,保证对每个key同时只有一个线程去查询后端服务,其它线程没有获得分布式锁的权限,因此只需要等待即可,这种方式 将高并发的压力转移到了分布式锁上,对分布式锁也是一种极大的考验。
1.3 缓冲雪崩
指在某一个时间段,缓冲集中过期失效或redis宕机导致的,例如双11抢购热门商品,这些商品都会放在缓冲中,假设缓冲时间为1小时,一个小时之后,这些商品的缓冲都过期了,访问压力瞬间来到了数据库上,此时数据库会产生周期性的压力波峰,所有的请求都会到达存储层,存储层的调用量暴增,造成存储层挂掉的情况。
其实比较致命的缓冲雪崩,是缓冲服务器某个节点宕机或断网,因为自然形成的缓冲雪崩,一定是在某个时间段集中创建缓冲,此时的数据库还是可以顶住压力的,而缓冲服务节点的宕机,对数据库服务器造成的压力是不可预知的,有可能瞬间就把服务器压垮。
解决方案:
1.配置Redis的高可用:其实就是搭建集群环境,有更多的备用机。
2.限流降级:在缓冲失效后,通过加锁或者队列来控制读服务器以及写缓冲的线程数量,比如对某个key只允许一个线程查询数据库和写缓冲,其它线程等待。
3.数据预热:在项目正式部署之前,把可能用的数据预先访问一遍,这样就可以把一些数据加载到缓冲中,在即将发生大并发访问之前手动触发加载缓冲中不同的key,设置不同的过期时间,让缓冲失效的时间尽量均衡。
1.4 缓冲倾斜
指某一台redis服务器压力过大而导致该服务器宕机。
十四、Redis集群搭建
十五、Redis其它常见问题
1.key的生存时间到了,Redis会立即删除吗?
不会立即删除
1.1 定期删除:Redis每隔一段时间就会去查看Redis设置了过期时间的key,会在100ms的间隔中默认查看3个key
1.2惰性删除:如果当你去查询一个已经过了生存时间的key时,Redis会先查看当前key的生存时间,是否已经到了,直接删除当前key,并且给用户返回一个空值。
2.Redis的淘汰机制
在redis内存已经满的时候,添加一个新的数据,执行淘汰机制。(redis.conf中配置)
2.1 volatile-lru:在内存不足的时候,Redis会在设置过了生存时间的key中干掉一个最近最少使用的key。
2.2 allkeys-lru:在内存不足时,Redis会在全部的key中干掉一个最近最少使用的key.
2.3 volatile-lfu:在内存不足时,Redis会在设置过了生存时间的key中干掉一个最近最少频次使用的key
2.4 allkeys-lfu:在内存不足时,Redis会在全部的key中干掉一个最近最少频次使用的key。
2.5 volatile-random:在内存不足时,Redis会在设置了生存时间的key中随机干掉一个。
2.6 allkeys-random:在内存不足时,Redis会在全部的key中随机干掉一个。
2.7 volatile-ttl:在内存不足的时候,Redis会在设置过了生存时间的key中干掉一个剩余生存时间最少的key.
2.8 noeviction:(默认)在内存不足的时候,直接报错
方案:指定淘汰机制的方式:maxmemory-policy具体策略,设置Redis的最大缓冲:maxmemory 字节大小