Redis基础入门知识点梳理
NoSql
问题现象
- 海量用户
- 高并发
罪魁祸首——关系型数据库
-
性能瓶颈:磁盘IO性能低下
-
扩展瓶颈:数据关系复杂,扩展性差,不便于大规模集群
因为MySQL数据库中的数据是存储在硬盘上,而且表结构复杂。首先硬盘的访问速度是比较低的,而且因为表结构关系复杂,查数据时可能会关联到很多张数据表,这又会造成硬盘访问。所以当用户增多访问数量增加,这就很容易造成服务器瘫痪。并且因为表结构的的关联,造成数据表扩展性差。
解决思路
降低磁盘IO次数,越低越好 —— 内存存储
去除数据间关系,越简单越好 —— 不存储关系,仅存储数据
所以NoSql的概念就被提出
Nosql
NoSQL:即 Not-Only SQL( 泛指非关系型的数据库),作为关系型数据库的补充。
作用:应对基于海量用户和海量数据前提下的数据处理问题。
现实中应用的一些场景:
比如:春节12306的抢票软件,前几年天猫的双十一,微博突然爆一个热点新闻等等。这些都会造成服务器崩溃。
大量的用户同时访问造成服务器瘫痪。
特征:
- 可扩容,可伸缩
- 大数据量下高性能
- 灵活的数据模型
- 高可用
常见 Nosql 数据库:
- Redis
- memcache
- HBase
- MongoDB
为什么要使用NOSQL
具体表现为对如下三高问题的解决:
High Performance - 数据库高并发访问
在同一个时间点,同时有海量的用户并发访问。往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。
- 如天猫的双11,从凌晨0点到2点这段时间,每秒达到上千万次的访问量。
- 12306春运期间,过年回家买火车抢票的时间,用户不断查询有没有剩余票。
Huge Storage - 海量数据的存储
数据库中数据量特别大,数据库表中每天产生海量的数据。
类似QQ,微信,微博,每天用户产生海量的用户动态,每天产生几千万条记录。对于关系数据库来说,在一张几亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。
High Scalability && High Availability- 高可扩展性和高可用性的需求
关系型数据库进行扩展和升级是比较麻烦的一样事,对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移。
非关系型数据库可以通过不断的添加服务器节点来实现扩展,而不需对原有的数据库进行维护。
Redis简介
概念 :Redis (REmote DIctionary Server) 是用 C 语言开发的一个开源的高性能键值对(key-value)数据库。
特征 :
- 数据间没有必然的关联关系
- 内部采用单线程机制进行工作
- 高性能。官方提供测试数据,50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
- 多数据类型支持
◆ 字符串类型 string
◆ 列表类型 list
◆ 散列类型 hash
◆ 集合类型 set
◆ 有序集合类型 zset/sorted_set - 支持持久化,可以进行数据灾难恢复
Redis 的应用
- 为热点数据加速查询(主要场景),如热点商品、热点新闻、热点资讯、推广类等高访问量信息等
- 即时信息查询,如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息(聊天室、网站)、设备信号等
- 时效性信息控制,如验证码控制、投票控制等
- 分布式数据共享,如分布式集群架构中的 session 分离
- 消息队列
Windows版Redis的下载
-
官网提供了Linux版的Redis下载
http://redis.io/download
-
Windows版的Redis,下载地址如下:
https://github.com/MSOpenTech/redis/tags
Windows版Redis的安装
Windows版的安装及其简单,解压Redis压缩包完成即安装完毕
- 安装的注意事项:
- 不要放在有中文的目录下
- 目录层次不要太深
- 安装文件所在的硬盘空间最好剩余20G以上
因为每次启动会占用内存大小的空间。服务器关闭,这个文件会被删除
基于Center OS7安装Redis
- 下载安装包
- 上传到Linux中(使用的是第三方工具)
- 解压安装包 tar -xvf redis-5.0.0.tar.gz
- 编译(在解压的目录中执行) make
- 安装(在解压的目录中执行) make install
注意:在线安装gcc-c++,所有的提示都回答yes。自动从服务器上下载这个包和它所有依赖的包,并且安装。这个包是c语句编译运行环境,安装redis是用C语言写的,必须先安装gcc-c++这个包。
yum -y install gcc-c++
Redis的目录文件
目录或文件 | 作用 |
---|---|
redis-benchmark | 用于性能测试一个工具命令 |
redis-check-aof | AOF文件的检查和修复工具 (AOF是它的一种文件存储格式) |
redis-check-dump | RDB文件的检查和修改工具 (RDB是它的一种文件存储格式) |
redis-cli | 客户端启动程序 |
redis-server.exe | 服务器端启动程序 (不会自动启动,默认每次都要手动开启) |
redis.conf | 服务器配置文件 |
在解压的目录中,windows中会有.exe后缀名,Linux中没有
Redis的启动与关闭
windows:在安装目录中,也就是你能看见redis-server.exe文件的目录中打开cmd,输入redis-server 回车,就启动了Redis服务器
Linux:在安装Redis的目录中,再进入src目录下,输入 ./redis-server 回车,就启动了Redis服务器
在Windows中直接关闭窗口或者 输入:shutdown 命令
在Linux中,可以使用快捷键 CTRL+C ,或者使用exit命令
Redis服务器的默认端口号是 6379
客户端的启动
与服务端的启动方式是一样的,只是 执行的是redis-cli 命令
使用配置文件的方式启动Redis
在windows中,首先你得在安装目录中,也就是redis-server的同级目录中创建一个后缀名.conf的文件。
简单介绍几个会用到的配置项
daemonize yes|no | 设置服务器以守护进程的方式运行,开启后服务器控制台中将打印服务器运行信息(同日志内容相同) |
---|---|
bind ip | 绑定主机地址 |
port port | 设置服务器端口号 |
dir path | 设置服务器文件保存地址 |
maxclients count | 服务器允许客户端连接最大数量,默认0,表示无限制。当客户端连接到达上限后,Redis会拒绝新的连接 |
timeout seconds | 客户端闲置等待最大时长,达到最大值后关闭对应连接。如需关闭该功能,设置为 0 |
loglevel debug|verbose|notice|warning | 设置服务器以指定日志记录级别 |
注意:日志级别开发期设置为verbose即可,生产环境中配置为notice,简化日志输出量,降低写日志IO的频度
在Linux中配置选项是相同的,只是在启动的时候,你需要指定配置文件的完整路径。
在windows中,你在redis-server目录下,直接指定文件名即可。
Linux
redis-server 路径/redis-conf
windows
redis-server redis.config
Redis的基本操作
信息读写
- 设置 key,value 数据
set key value
-
根据key查询对应的value,如果不存在返回空(nil)
get key
帮助信息
-
获取命令帮助文档
help set 获取set命令的帮助信息文档
数据类型
Redis的5种数据类型
redis是一种高级的key-value的存储系统,其中value支持五种数据类型,指的是它值的类型,键可以认为是字符串类型。redis不是用Java写的,是C语言写的。
值的数据类型 | 说明 |
---|---|
string类型 | 字符串 |
list类型 | 列表:元素可以重复,元素是有索引号,有先后顺序的 |
set类型 | 集合:元素是不可重复的,元素没有索引号,没有先后顺序的 |
hash类型 | 值由多个键值对组成 |
zset类型 | 集合:元素不可重复的,每个元素有索引号,还有一个分数值,可以根据分数进行排序 |
字符串类型string
在Redis中以二进制保存,没有编码和解码的过程。
无论存入的是字符串、整数、浮点类型都会以字符串写入。
在Redis中字符串类型的值最多可以容纳的数据长度是512M,这是以后最常用的数据类型。
常用命令
命令 | 功能 |
---|---|
set 键 值 | 存入字符串类型的键和值,如果键不存在就是添加,存在就是修改 |
setnx 键 值 | 键不存在就是添加,存在不做任何操作,不会覆盖以前的键和值 |
get 键 | 通过键获取值 |
del 键 | 通过键删除键和值 |
mset 键1 值1 键2 值2… | 添加/修改多个数据 |
mget 键1 键2… | 获取多个数据 |
strlen 键 | 获取数据字符个数(字符串长度) |
append 键 值 | 追加信息到原始信息后面(如果原始信息存在就追加,不存在就新建) |
单数据操作和多数据操作之间的选择,如果插入三条数据,
使用单数据操做,需要三次请求和响应
使用多数据操作,需要一次请求和响应,但是这次请求和响应数据体量肯定比单数据的大,那么耗时也会相对多一些。
所以,根据具体情况和你自己的心情吧。。。
list类型
概述
在Redis中,List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样,我们可以在其左部(left)和右部(right)添加新的元素。
在插入时,如果该键并不存在,Redis将为该键创建一个新的链表。
如果链表中所有的元素均被移除,那么该键也将会被从数据库中删除。
List中可以包含的最大元素数量是4G个(41亿个)
常用命令
命令 | 行为 |
---|---|
lpush 键 元素 元素 | 从左边添加1个或多个元素 |
rpush 键 元素 元素 | 从右边添加1个或多个元素 |
lpop 键 | 删除最左边的一个元素,并且返回 |
rpop 键 | 删除最右边的一个元素,并且返回 |
lrange 键 开始 结束 | 查找指定索引范围内元素返回,每个元素有2个索引号 索引号从左向右:0~length-1 索引号从右向左:-1~-length 如果要获取整个列表中所有的元素,索引号范围如何写?0~-1 |
llen 键 | 获取列表中有多少个元素 |
hash类型
- 新的存储需求:对一系列存储的数据进行编组,方便管理,典型应用存储对象信息
- 需要的存储结构:一个存储空间保存多个键值对数据
- hash类型:底层使用哈希表结构实现数据存储
- hash存储结构优化
- 如果field数量较少,存储结构优化为类数组结构
- 如果field数量较多,存储结构使用HashMap结构
常用命令
命令 | 行为 |
---|---|
hset key field1 value | 添加或修改数据 |
hget key field | 获取数据 |
hdel key field1 [field2] | 删除数据 |
hsetnx key field value | 设置field的值,如果该field存在则不做任何操作 |
hmset key field1 value1 field2 value2… | 添加或修改多个数据 |
hmget key field1 field2… | 获取多个数据 |
hlen key | 获取哈希表中字段的数量 |
hexists key field | 判断哈希表中是否存在指定的字段,存在就获取 |
hash 类型数据操作的注意事项
- hash类型中value只能存储字符串,不允许存储其他数据类型,不存在嵌套现象。如果数据未获取到,对应的值为(nil)
- 每个 hash 可以存储 2
32 - 1 个键值对 - hash类型十分贴近对象的数据存储形式,并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计
的,切记不可滥用,更不可以将hash作为对象列表使用 - hgetall 操作可以获取全部属性,如果内部field过多,遍历整体数据效率就很会低,有可能成为数据访问瓶颈
set 类型
- 新的存储需求:存储大量的数据,在查询方面提供更高的效率
- 需要的存储结构:能够保存大量的数据,高效的内部存储机制,便于查询
- set类型:与hash存储结构完全相同,仅存储键,不存储值(nil),并且值是不允许重复的
常用命令
命令 | 行为 |
---|---|
sadd key value1[value2] | 添加数据 |
smembers key | 获取全部数据 |
srem key value1[value1] | 删除数据 |
scard key | 获取集合数据总量 |
sismember key value | 判断集合中是否包含指定数据 |
set 类型数据操作的注意事项
-
set 类型不允许数据重复,如果添加的数据在 set 中已经存在,将只保留一份
-
set 虽然与hash的存储结构相同,但是无法启用hash中存储值的空间
Key常用指令
Key基本操作
命令 | 行为 |
---|---|
del key | 删除指定key |
exists key | 获取key是否存在 |
type | 获取key的类型 |
Key的扩展操作
命令 | 行为 |
---|---|
sort | 排序 |
rename key newkey | 改名 |
key 的重复问题
- key是由程序员定义的
- redis在使用过程中,伴随着操作数据量的增加,会出现大量的数据以及对应的key
- 数据不区分种类、类别混杂在一起,极易出现重复或冲突
解决方案
- redis为每个服务提供有16个数据库,编号从0到15
- 每个数据库之间的数据相互独立
数据库常用指令
基本操作
命令 | 行为 |
---|---|
select index | 切换数据库 |
move key db | 数据移动 |
flushdb flushall | 数据清除 |
Jedis
概述:
Redis不仅可以使用命令来操作,现在基本上主流的语言都有API支持,比如Java、C#、C++、PHP、Node.js、Go等。
在官方网站里列一些Java的客户端,有Jedis、Redisson、Jredis、JDBC-Redis等其中官方推荐使用Jedis和Redisson。
Jedis操作redis需要导入jar包如下:
Jedis类常用方法
- 每个方法就是redis中的命令名,方法的参数就是命令的参数。
- 每个Jedis对象似于JDBC中Connection对象,获取一个Jedis对象本质上就是获取一个连接对象。
连接和关闭 | 功能 |
---|---|
new Jedis(String host, int port) | 创建一个连接对象 参数1:主机名 参数2:端口号 6379 |
void close() | 关闭连接 |
对string操作的方法 | 说明 |
---|---|
set(String key,String value) | 添加字符串类型的键和值 |
String get(String key) | 通过键获取值 |
del(String … keys) | 删除一个或多个键和值 |
对list操作的方法 | 说明 |
---|---|
lpush(String key,String…values) | 从左边添加1个或多个元素 |
List lrange(String key,long start,long end) | 获取一个范围内所有的元素 |
Jedis连接池的使用
jedis连接池的基本概念
jedis连接资源的创建与销毁是很消耗程序性能,所以jedis为我们提供了jedis的连接池技术,jedis连接池在创建时初始化一些连接对象存储到连接池中,使用jedis连接资源时不需要自己创建jedis对象,而是从连接池中获取一个资源进行redis的操作。使用完毕后,不需要销毁该jedis连接资源,而是将该资源归还给连接池,供其他请求使用。
Jedis连接池API
用于创建连接池的配置信息
JedisPoolConfig配置类 | 功能说明 |
---|---|
JedisPoolConfig() | 构造方法,创建一个配置对象 |
void setMaxTotal() | 连接池中最大连接数 |
void setMaxWaitMillis() | 设置最长等待时间,单位是毫秒 |
JedisPool连接池类 | 说明 |
---|---|
JedisPool(配置对象,服务器名,端口号) | 构造方法,创建连接池的类 参数1:上面的配置对象 参数2:服务器名 参数3:端口号 |
Jedis getResource() | 从连接池中获取一个创建好的连接对象,返回Jedis对象 |
测试Demo
package com.test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
import java.util.List;
/**
* Jedis连接池的基本使用
*/
public class Demo2Pool {
public static void main(String[] args) {
//1.创建连接池的配置对象
JedisPoolConfig config = new JedisPoolConfig();
//2.设置连接池的参数
config.setMaxTotal(10); //最大连接数
config.setMaxWaitMillis(2000); //最长等待时间为2秒钟
//3.创建连接池,使用上面配置对象
JedisPool pool = new JedisPool(config,"localhost", 6379);
//4.从连接池中获取连接对象
Jedis jedis = pool.getResource();
//5.使用连接对象
jedis.lpush("students", "孙悟空", "猪八戒", "白骨精");
List<String> students = jedis.lrange("students", 0, -1);
System.out.println(students);
//6.关闭连接对象
jedis.close();
}
}
Jedis连接池工具类
jedis.properties配置文件
# 主机名
host=localhost
# 端口号
port=6379
# 最大连接数
maxTotal=20
# 最长等待时间
maxWaitMillis=3000
JedisUtils.java
package com.test.utils;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
import java.util.ResourceBundle;
/**
* Jedis连接池工具类
*/
public class JedisUtils {
private static JedisPool pool;
//在静态代码块中创建连接池
static {
//读取配置文件
ResourceBundle bundle = ResourceBundle.getBundle("jedis");
//读取属性值
int maxTotal = Integer.parseInt(bundle.getString("maxTotal"));
int maxWaitMillis = Integer.parseInt(bundle.getString("maxWaitMillis"));
int port = Integer.parseInt(bundle.getString("port"));
String host = bundle.getString("host");
//创建连接池配置对象
JedisPoolConfig config = new JedisPoolConfig();
//设置连接池的参数
config.setMaxTotal(maxTotal);
config.setMaxWaitMillis(maxWaitMillis);
//创建连接池
pool = new JedisPool(config, host, port);
}
/**
* 获取连接对象
*/
public static Jedis getJedis() {
return pool.getResource();
}
}
可视化客户端
客户端工具Redis Desktop Manager的安装
安装很简单,直接无脑下一步,只需要选择一下安装目录
注:如果安装过程中出现缺少DLL文件的提示,可以安装vcredist_x86.exe文件。
客户端工具连接
启动后出现如下登录界面:
- 点左上角的连接按钮
2.新连接设置,名字随意起,地址为服务器的IP地址,端口号默认。
- 操作指定的数据库
注意:
说说连接客户端这些参数的作用:
- 名字: 配置名字随意起
- 主机: 服务器名字,本机127.0.0.1或localhost
- 端口号: 6379
Redis持久化
什么是持久化
利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化
持久化用于防止数据的意外丢失,确保数据安全性.
Redis默认是会持久化的,你看你的安装目录中会有dump.rdb文件
持久化过程保存什么
- 将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据
- 将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程
RDB持久化
1. RDB启动方式-----save指令
手动执行一次保存操作
save
save指令相关配置(就是启动redis时的配置文件)
设置本地数据库文件名,默认为dump.rdb,通常设置为dump-端口号.rdb
dbdilename 文件名
设置存储.rdb文件的路径
dir 路径
设置存储至本地数据库时是否压缩数据,默认yes,设置为no,节省 CPU 运行时间,但存储文件变大 rdbcompression yes|no
设置读写文件过程是否进行RDB格式校验,默认yes,设置为no,节约读写10%时间消耗,单存在数据损坏的风险 rdbchecksum yes|no
save指令工作原理
Redis是单线程工作原理,所以,save指令的执行会阻塞当前Redis服务器,直到当前RDB过程完成为止,有可能会造成长时间阻塞,线上环境不建议使用。
2. RDB启动方式 —— bgsave指令
手动启动后台保存操作,但不是立即执行
bgsave
bgsave指令相关配置
后台存储过程中如果出现错误现象,是否停止保存操作,默认yes
stop-writes-on-bgsave-error yes|no
bgsave指令工作原理
bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式,save命令可以放弃使用。就相当于保存是另外开启的一个线程,不影响后面的操作执行。
save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,结果可能是灾难性的save配置启动后执行的是bgsave操作
RDB存储的弊端
- 存储数据量较大,效率较低,基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程,内存产生额外消耗
- 宕机带来的数据丢失风险
解决思路
- 不写全数据,仅记录部分数据
- 降低区分数据是否改变的难度,改记录数据为记录操作过程
- 对所有操作均进行记录,排除丢失数据的风险
AOF持久化
AOF概念
- AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
- AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式
AOF写数据过程
启动AOF相关配置
开启AOF持久化功能,默认no,即不开启状态
appendonly yes|no
AOF持久化文件名,默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof
appendfilename filename
AOF持久化文件保存路径,与RDB持久化文件保持一致即可
dir
AOF写数据策略,默认为everysec
appendfsync always|everysec|no
AOF写数据三种策略(appendfsync)
- always(每次):每次写入操作均同步到AOF文件中数据零误差,性能较低,不建议使用。
- everysec(每秒):每秒将缓冲区中的指令同步到AOF文件中,在系统突然宕机的情况下丢失1秒内的数据数据准确性较高,性能较高,建议使用,也是默认配置
- no(系统控制):由操作系统控制每次同步到AOF文件的周期整体过程不可控
AOF写数据遇到的问题
如果连续执行如下指令该如何处理
AOF重写
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录
AOF重写作用
- 降低磁盘占用量,提高磁盘利用率
- 提高持久化效率,降低持久化写时间,提高IO性能
- 降低数据恢复用时,提高数据恢复效率
AOF重写规则
-
进程内具有时效性的数据,并且数据已超时将不再写入文件
-
非写入类的无效指令将被忽略,只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据,但是更改了数据的存储位置,此类命令同样需要记录
-
对同一数据的多条写命令合并为一条命令
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为:lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素
AOF重写方式
手动重写
bgrewriteaof
自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
AOF自动重写方式
自动重写触发条件设置
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent
percent 时间 size 次数
在规定时间内达到了多少了操作次数,就触发重写
RDB与AOF的选择之惑
- 对数据非常敏感,建议使用默认的AOF持久化方案
- AOF持久化策略使用everysecond,每秒钟fsync一次。该策略redis仍可以保持很好的处理性能,当出现问题时,最多丢失0-1秒内的数据。
- 注意:由于AOF文件存储体积较大,且恢复速度较慢
- 数据呈现阶段有效性,建议使用RDB持久化方案
- 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段点数据恢复通常采用RDB方案
- 注意:利用RDB实现紧凑的数据持久化会使Redis降的很低,慎重总结:
- 综合比对
- RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊
- 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF
- 如能承受数分钟以内的数据丢失,且追求大数据集的恢复速度,选用RDB
- 灾难恢复选用RDB
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为:lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令最多写入64个元素
AOF重写方式
手动重写
bgrewriteaof
自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
AOF自动重写方式
自动重写触发条件设置
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent
percent 时间 size 次数
在规定时间内达到了多少了操作次数,就触发重写
RDB与AOF的选择之惑
- 对数据非常敏感,建议使用默认的AOF持久化方案
- AOF持久化策略使用everysecond,每秒钟fsync一次。该策略redis仍可以保持很好的处理性能,当出现问题时,最多丢失0-1秒内的数据。
- 注意:由于AOF文件存储体积较大,且恢复速度较慢
- 数据呈现阶段有效性,建议使用RDB持久化方案
- 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的),且恢复速度较快,阶段点数据恢复通常采用RDB方案
- 注意:利用RDB实现紧凑的数据持久化会使Redis降的很低,慎重总结:
- 综合比对
- RDB与AOF的选择实际上是在做一种权衡,每种都有利有弊
- 如不能承受数分钟以内的数据丢失,对业务数据非常敏感,选用AOF
- 如能承受数分钟以内的数据丢失,且追求大数据集的恢复速度,选用RDB
- 灾难恢复选用RDB
- 双保险策略,同时开启 RDB 和 AOF,重启后,Redis优先使用 AOF 来恢复数据,降低丢失数据的量