Redis入门

NoSQL

问题

• 类似12306春运期间、淘宝京东双11促销等情况面临的问题

  • 海量用户
  • 高并发

罪魁祸首——关系型数据库

• 性能瓶颈：磁盘IO性能低下
• 扩展瓶颈：数据关系复杂，扩展性差，不便于大规模集群

解决思路

• 降低磁盘IO次数，越低越好——内存存储
• 去除数据间关系，越简单越好——不存储关系，仅存储数据

由上述面临的问题，NoSQL由此诞生

NoSQL

• 即Not-Only SQL(泛指非关系型的数据库)，作为关系型数据库的补充
• 作用：应对基于海量用户和海量数据前提下的数据处理问题

NoSQL并不是一个数据库，只是对关系型数据库的补充，是一个辅助工具

特征

• 可扩容，可伸缩
• 大数据量下高性能（不走磁盘，通过内存读写）
• 灵活的数据模型（有自己的一套数据模型）
• 高可用

常见NoSQL数据库

• Redis
• memcache
• HBase
• MongoDB

解决方案（电商场景）

1. 商品基本信息（MySQL）

   • 名称
   • 价格
   • 厂商

2. 商品附加信息（MongoDB）

   • 描述
   • 详情
   • 评论
3. 图片信息（分布式文件系统）
4. 搜索关键字（ES、Lucene、solr）

5. 热点信息（Redis、memcache、tair）

   • 高频
   • 波段性（不是稳定的热度很高，具有一定时效）

即所有基础信息都是存储在MySQL中，在它之上，就是类似于MongoDB、Redis等NoSQL，他们原来并没有数据，是把MySQL中的数据加载进去，由此来提高效率

Redis

概念：Redis（REmote DIctionary Server）是用C语言开发的一个开源的高性能键值对（key-value）数据库

特征

1. 数据库之间没有必然的关联关系
2. 内部采用单线程机制进行工作（单线程不会有数据并发问题，安全）

3. 高性能

   官方提提供测试数据，50个并发执行100000个请求，读的速度是110000次/s，写的速度是81000次/s

4. 多数据类型支持

   • 字符串类型——string
   • 列表类型——list
   • 散列类型——hash
   • 集合类型——set
   • 有序集合类型——zset/sorted_set（仅了解，应用场景不多）
5. 支持持久化，可以进行数据灾难恢复

应用场景

• 为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等
• 即时信息查询，如各类排行榜、网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等
• 时效性信息控制，如验证码控制、投票控制等
• 分布式数据共享，如分布式集群架构中的session分离
• 消息队列（了解即可，已经慢慢的弱化）

下载与安装

基于Centos 7 安装Redis

1. 下载安装包

   wget http://download.redis.io/releases/redis-5.0.0.tar.gz

2. 解压安装包

   tar -zxvf redis-5.0.0.tar.gz

3. 编译（再解压的目录中执行）

   make

4. 安装（在解压的目录中执行）

   make install

解压完成后，进入src目录，查看redis开头的文件，就是可执行的文件

Redis-server服务器启动指令；Redis-cli客户端启动指令

再退回上一级，可以看到redis.conf，即为Redis的配置文件

在根目录下，redis目录名为redis-5.0.0,名称比较长，使用起来不太方便，可以做一个快链（快捷方式）

ln -s redis-5.0.0 redis

服务器与客户端启动

服务器

• 启动服务器——参数启动（默认端口：6379）

  redis-server [--port port]

• 范例

  redis-server --port 6379

• 启动服务器——配置文件启动【主流】

  redis-server config_file_name

• 范例

  redis-server redis.conf

客户端

• 启动客户端（默认端口：6379）

  redis-cli [-h host] [-p port]

• 范例

  redis-cli -h 61.129.65.248 -p 6384

注意：服务器启动指定端口使用的是--port，客户端启动指定端口使用的是-p，注意-的数量是不同的

基础环境设置约定

• 创建配置文件存储目录

  mkdir conf

• 创建服务器文件存储目录（包含日志、数据、临时配置文件等）

  mkdir data

• 创建快速访问链接

  ln -s redis-5.0.0 redis

配置文件启动与常用配置

• 过滤原redis.conf配置文件并保存到redis-6379.conf文件

  cat redis.conf | grep -v "#" | grep -v "^$" > redis-6379.conf

• bind：绑定主机地址
• prot：指定端口号
• timeout：客户端连接超时时间（客户端多久无操作就将其关闭）
• daemonize：设置服务器以守护进程的方式运行，开启后服务器控制台中将打印服务器运行信息（同日志内容相同）

• loglevel：日志等级（debug/verbose/notice/warning）

  日志级别开发期设置为verbose即可，生产环境中配置为notice，简化日志输出量，降低写日志IO的频度

• logfile：日志文件
• dir ./：设置服务器文件保存地址（data目录）
• maxclients：服务器允许客户端连接最大数量，默认0，表示无限制。当客户端连接达到上限后，Redis会拒绝新的连接

修改配置文件

启动

redis-server /redis/conf/redis-6379.conf

将darmonize改为yes，方便学习，开发中还是使用前台启动

基本操作

信息读写

• 设置key、value数据

  set key value

• 范例

  set name hellocode

• 根据key查询对应的value，如果不存在，返回空(nil)

  get key

• 范例

  get name

帮助信息

• 获取命令帮助文档

  help [command]

• 范例

  help set

• 获取组中所有命令信息名称

  help [@group-name]

• 范例

  help @string

退出命令行客户端模式

• 退出客户端

  quit

  exit

• 快捷键(推荐)

  Ctrl + C

• 清屏

  clear

数据类型

业务数据的特殊性

1. 原始业务功能设计

   • 秒杀
   • 618活动
   • 双11活动
   • 排队购票

2. 运营平台监控到的突发高频访问数据

   • 突发时政要闻，被强势关注围观

3. 高频、复杂的统计数据

   • 在线人数
   • 投票排行榜

Redis数据类型（5种常用）

• string
• hash
• list
• set
• sorted_set/zset（应用性较低，了解即可）

redis 自身是一个Map，其中所有的数据都是采用key:value的形式存储

string

• 存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型
• 存储数据的格式：一个存储空间保存一个数据
• 存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用

每一个存储空间只能保存一个字符串，如果存的是纯数字，也可以当作纯数字使用

基本操作

• 添加/修改数据

  set key value

• 获取数据

  get key

• 删除数据

  del key

• 判定性添加数据

  setnx key value

• 添加多个数据

  mset key1 value1 key2 value2 ...

• 获取多个数据

  mget key1 key2 ...

• 获取数据字符个数（字符串长度）

  strlen key

• 追加信息到原始信息后部（如果原始信息存在就追加，否则新建）

  append key value

setnx在设置时，如果对应的键没设置过，则为1（设置成功），如果键已存在，则为0（设置失败）

单数据操作与多数据操作的选择之感

发送的数据少的时候，可以用单数据操作；如果发送的量大，就用多指令，可以减少指令发送和接收的时间

扩展操作

• 设置数值数据增加指定范围的值

  incr key
  incrby key increment
  incrbyfloat key increment

• 设置数值数据减少指定范围的值

  decr key
  decrby key increment

• 设置数据具有指定的生命周期

  setex key seconds value
  psetex key milliseconds value

incr操作，如果变量不存在，会直接从0开始累加（需要是数字）

注意事项

1. 数据操作不成功的反馈与数据正常操作之间的差异

   • 表示运行结果是否成功

     (integer)0——false——失败

     (integer)1——true——成功

   • 表示运行结果值

     (integer)3——3——3个

     (integer)1——1——1个

2. 数据未获取到时，对应的数据为(nil)，等同于null
3. 数据最大存储量：512MB
4. string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算
5. 按数值进行操作的数据，如果原始数据不能转换为数值，或超越了redis数值上限范围，将报错
6. redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响

应用场景

• 主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量

• 在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可

  eg:user:id:3506728370:fans->12210947

  eg:user:id:3506728370:blogs->6164

  eg:user:id:3506728370:focuses->83

• 也可以使用json格式保存数据

  eg:user:id:3506728370->{"fans":12210947,"blogs":6164,"focusees":83}

• 数据库中的热点数据key命名惯例

hash

数据存储的困惑：

对象类数据的存储如果具有较频繁的更新需求操作会显得笨重，需要将整个对象数据全部获取修改

hash类型

• 新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
• 需要的存储结构：一个存储空间保存多个键值对数据

• hash类型：底层使用哈希表结构实现数据存储

  key+hash存储空间(field+value)

hash存储结构优化

• 如果field数量较少，存储结构优化为类数组结构
• 如果field数量较多，存储结构使用HashMap结构

基本操作

• 添加/修改数据

  hset key field value

• 获取数据

  hget key field

  hgetall key

• 删除数据

  hdel key field1 [field2]

• 设置field的值，如果该field存在则不做任何操作

  hsetnx key field value

• 添加/修改多个数据

  hmset key field1 value1 field2 value2 ...

• 获取数据

  hmget key field1 field2 ...

• 获取哈希表中字段的数量

  hlen key

• 获取哈希表中是否存在指定的字段

  hexists key field

扩展操作

• 获取哈希表中所有的字段名或字段值

  hkeys key
  hvals key

• 设置指定字段的数值数据增加指定范围的值

  hincrby key field increment
  hincrbyfloat key field increment

  需要进行decr操作时，在increment传递负值即可

注意事项

1. hash类型中value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为(nil)
2. 每个hash可以存储2^32 -1个键值对
3. hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用
4. hgetall操作可以获取全部属性，如果内部field过多，遍历整体数据效率就会很低，很有可能成为数据访问瓶颈

应用场景

双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000张

• 存储结构

  • 商家id——key
  • 充值卡id——field
  • 数量——value
• 抢购时使用降值的方式控制产品数量

注意：实际业务中还有超卖等实际问题，这里不做讨论

list

• 数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
• 需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
• list类型：保存多个数据，底层使用双向链表存储结构实现（key——list）

基本操作

• 添加/修改数据

  lpush key value1 [value2] ...

  rpush key value1 [value2] ...

• 获取数据

  lrange key start stop

  lindex key index

  llen key

• 获取并移除数据

  lpop key

  rpop key

扩展操作

• 移除指定数据

  lrem key count value

• 规定时间内获取并移除数据

  blpop key1 [key2] timeout

  brpop key1 [key2] timeout

  brpoplpush source destination timeout

注意事项

1. list中保存的数据都是string类型的，数据总容量是有限的，最多2^32-1个元素(4294967295)
2. list具有索引的概念，但是操作数据时通常以队列的形式进行入队和出队操作，或以栈的形式进行入栈出栈操作
3. 获取全部数据操作结束索引可以设置为-1
4. list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载

应用场景

企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？

• 依赖list的数据具有顺序的特征对信息进行管理
• 使用队列模型解决多路信息汇总合并的问题
• 使用栈模型解决最新消息的问题

set

• 新的存储需求：存储大量的数据，在查询方面提供更高的效率
• 需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
• set类型：与hash存储结构完全相同，仅存储键，不存储值(nil)，并且值是不允许重复的(key-field(value))

基本操作

• 添加数据

  sadd key member1 [member2]

• 获取全部数据

  smembers key

• 删除数据

  srem key member1 [member2]

• 获取大小

  scard key

扩展操作

• 求两个集合的交、并、差集

  sinter key1 [key2] ...
  sunion key1 [key2] ...
  sdiff key1 [key2] ...

• 求两个集合的交、并、差集并存储到指定集合中

  sinterstore destination key1 [key2 ...]
  sunionstore destination key1 [key2 ...]
  sdiffstore destination key1 [key2 ...]

• 将指定数据从原始集合中移动到目标集合中

  smove source destination member

注意事项

• set 类型不允许数据重复，如果添加的数据在set中已经存在，将只保留一份
• set虽然与hash的存储结构相同，但是无法启用hash中存储值的空间

应用场景

黑名单

资讯类信息类网站追求高访问量，但是由于其信息的价值，往往容易被不法分子利用，通过爬虫技术，快速获取信息，个别特种行业网站信息通过爬虫获取分析后，可以转换成商业机密进行出售。例如第三方火车票、机票、酒店刷票代购软件，电商刷评论、刷好评

同时爬虫带来的伪流量也会给经营者带来错觉，产生错误的决策，有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后，需要将此类用户进行有效的屏蔽，这就是黑名单的典型应用

不是说爬虫一定要做摧毁性的工作，有些小型网站需要爬虫为其带来一些流量

白名单

对于安全性更高的应用访问，仅仅靠黑名单是不能解决问题的，此时需要设定可访问的用户群体，依赖白名单做更为苛刻的访问验证

解决方案

• 基于经营战略设定问题用户发现、鉴别规则
• 周期性更新满足规则的用户黑名单，加入set集合
• 用户行为信息达到后与黑名单进行对比，确认行为去向
• 黑名单过滤IP地址：应用于开放游客访问权限的信息源
• 黑名单过滤设备信息：应用于限定访问设备的信息源
• 黑名单过滤用户：应用于基于访问权限的信息源

实践案例

业务场景

使用微信的过程中，当微信接收消息后，会默认将最近接收的消息置顶，当多个好友及关注的订阅号同时发送消息时，该排序会不停的进行交替。同时还可以将重要的会话设置为置顶。一旦用户离线后，再次打开微信时，消息该按照什么样的顺序显示？

解决方案

• 依赖list的数据具有顺序的特征对消息进行管理，将list结构作为栈使用
• 对置顶与普通会话分别创建独立的list分别管理
• 当某个list中接收到用户消息后，将消息发送方的id从list的一侧加入list（此处设定左侧）
• 多个相同id发出的消息反复入栈会出现问题，在入栈之前无论是否具有当前id对应的消息，先删除对应id
• 推送消息时先推送指定会话list，再推送普通会话list，推送完成的list清除所有数据
• 消息的数量，也就是微信用户对话数量采用计数器的思想另行记录，伴随list操作同步更新

常用指令

key常用指令

• key是一个字符串，通过key获取redis中保存的数据
• 对于key自身状态的相关操作，例如：删除，判断存在，获取类型等
• 对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等
• 对于key快速查询操作，例如：按制定策略查询key
• ...

基本操作

• 删除指定key

  del key

• 获取key是否存在

  exists key

• 获取key的类型

  type key

扩展操作

• 排序

  sort

• 改名

  rename key newkey

  renamenx key newkey

时效性控制【重要】

• 为指定key设置有效期

  expire key seconds
  pexpire key milliseconds
  expireat key timestamp
  pexpireat key milliseconds-timestamp

• 获取key的有效时间

  ttl key
  pttl key

  ttl获取秒，pttl获取毫秒

  -1表示永久有效，-2表示不存在（失效或本来就不存在）

• 切换key从时效性转换为永久性

  persist key

查询模式

• 查询key

  keys pattern

查询模式规则

• *匹配任意数量的任意符号
• ?配合一个任意符号
• []匹配一个指定符号

keys *——查询所有

keys hello*——查询所有以hello开头

keys *code——查询所有以code结尾

keys ??code——查询所有前面两个字符任意，后面以code结尾

keys user:?——查询所有以user:开头，最后一个字符任意

keys u[st]er:1——查询所有以u开头，以er:1结尾，中间包含一个字母：s或t

数据库常用指令

key的重复问题

• key是由程序员定义的
• redis在使用的过程中，伴随着操作数据的增加，会出现大量的数据以及对应的key
• 数据不区分种类、类别混杂在一起，极易出现重复或冲突

解决方案

• redis为每个数据库提供有16个数据库，编号从0到15
• 每个数据库之间的数据相互独立

这些数据库公用redis内存，具体每个多大是未知的

默认16个数据库，但也可以在配置文件中修改，但一般会使用默认设置

基本操作

• 切换数据库

  select index

• 其他操作

  ping

扩展操作

• 数据移动

  move key db

• 数据总量

  dbsize

• 数据清除

  flushdb——清空当前数据库

  flushall——清空所有数据库

Jedis

快速入门

编程语言与Redis

• Jedis用于Java语言连接Redis服务，并提供对应的操作API

• Java语言连接Redis服务

  Jedis

  SpringData Redis

  Lettuce

除了Java语言，类似C、C++、PHP、Python等语言，都有对应的库可以实现对Redis的连接和操作

准备工作

1. 导入jar包：https://mvnrepository.com/artifact/redis.clients/jedis
2. 获取连接对象
3. 执行操作
4. 关闭连接

Jedis接口做的非常好，所有方法名和在Linux下操作都一样，我们只需要注意返回值，有多个值时，都是以List存储

问题

1. 当前Redis是装在虚拟机中的，有一个对外的虚拟IP，需要使用这个IP来连接（可以使用ip addr查询）

2. 修改配置文件，打开bind绑定项

   

3. 重启Redis服务

若还是无法连接，可能是防火墙原因，在虚拟机执行systemctl stop firewalld指令

在更改redis.conf配置文件绑定ip后，Linux下客户端连接需要指定绑定的IP地址：redis-cli -h ip地址

public class JedisTest {
    public static void main(String[] args) {
        // 1. 获取连接对象
        Jedis jedis = new Jedis("192.168.23.129",6379);
        // 2. 执行操作
        jedis.lpush("list1","a","b","c","d");
        List<String> list1 = jedis.lrange("list1", 0, -1);
        for (String s:list1) {
            System.out.println(s);
        }
        // 3. 关闭连接
        jedis.close();
    }
}

简易工具类

准备工作

• 连接池jar包下载：https://mvnrepository.com/artifact/org.apache.commons/commons-pool2
• slf4j下载：https://repo1.maven.org/maven2/org/slf4j/

public class JedisUtils {
    public static Jedis getJedis(){
        // Jedis连接池配置对象
        JedisPoolConfig jpc = new JedisPoolConfig();
        jpc.setMaxTotal(50);    // 最大连接数
        jpc.setMaxIdle(10);     // 初始连接数
        String host = "192.168.23.129";     // 主机IP
        int port = 6379;    // 端口
        // 连接池对象
        JedisPool jp = new JedisPool(jpc,host,port);
        return jp.getResource();    // 获取Jedis对象
    }
}

public class JedisTest {
    public static void main(String[] args) {
        Jedis jedis = JedisUtils.getJedis();
        jedis.lpush("list1","a","b","c","d");
        List<String> list1 = jedis.lrange("list1", 0, -1);
        for (String s:list1) {
            System.out.println(s);
        }
        jedis.close();
    }
}

工具类优化

配置文件redis.properties

redis.maxTotal=50
redis.maxIdel=10
redis.host=192.168.23.129
redis.port=6379

工具类代码

package top.hellocode.util;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

import java.util.ResourceBundle;

public class JedisUtils {
    private static int maxTotal;
    private static int maxIdel;
    private static String host;
    private static int port;

    private static JedisPoolConfig jpc;
    private static JedisPool jp;
    static {
        ResourceBundle bundle = ResourceBundle.getBundle("redis");
        maxTotal = Integer.parseInt(bundle.getString("redis.maxTotal"));
        maxIdel = Integer.parseInt(bundle.getString("redis.maxIdel"));
        host = bundle.getString("redis.host");
        port = Integer.parseInt(bundle.getString("redis.port"));

        // Jedis连接池配置对象
        jpc = new JedisPoolConfig();
        jpc.setMaxTotal(maxTotal);    // 最大连接数
        jpc.setMaxIdle(maxIdel);     // 初始连接数

        // 连接池对象
        jp = new JedisPool(jpc,host,port);
    }
  
    public static Jedis getJedis(){
        return jp.getResource();    // 获取Jedis对象
    }
}

可视化工具

Redis Desktop Manager

• 免费发行版下载：https://github.com/uglide/RedisDesktopManager/releases/tag/0.8.8
• 按照提示安装即可（安装位置推荐D盘，其他默认即可）
• 建立连接
  

持久化

• 日常操作的数据都是在内存中的，而真正的信息是保存在硬盘中的
• 内存中的信息在断电后就会丢失，而硬盘中的数据断电后还可以保存下来
• 将数据从内存保存到硬盘中叫做数据的保存，反之就是数据恢复（从硬盘读取到内存中）

• 利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化

  持久化用于防止数据的丢失，确保数据的安全性

持久化常见的两种保存形式:

保存对应的数据(二进制形式)：快照

保存操作过程：日志

• 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据（RDB）
• 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程（AOF）

RDB

RDB启动方式——save指令

• 手动执行一次保存操作

  save

save指令相关配置

• 设置本地数据库文件名，默认值为dump.rdb，通常设置为dump-端口号.rdb

  dbfilename filename

• 设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

  dir path

• 设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省CPU运行时间，但存储文件变大

  rdbcompression yes|no

• 设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，但存在数据损坏的风险

  rdbchecksum yes|no

  上述四个配置文件，一般来说设置前两个即可，后两个一般使用默认设置

bind 192.168.23.129
port 6379
daemonize no
logfile "log-6379.log"
dir /redis/data
dbfilename "dump-6379.rdb"

save指令工作原理

• 多个客户端在执行指令时，会有先后顺序问题
• Redis是单线程工作模式，会创建一个任务队列
• 所有指令都会进到队列中，执行一个，消失一个
• 在执行save时，如果数据量很大，会非常耗时，导致save后面的指令处于阻塞状态

save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

RDB启动方式——bgsave指令

• 手动启动后台保存操作，但不是立即执行

  bgsave

bgsave指令相关配置

• 后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

  stop-writes-on-bgsave-error yes|no

• 其他

  dbfilename filename
  dir path
  rdbcompression yes|no
  rdbchecksum yes|no

这里的配置一般情况下采用默认即可

bgsave指令工作原理

bgsave命令是针对save阻塞问题做的优化。

Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

RDB启动方式——save配置

• 设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

  save second changes

• 参数

  seconds：监控时间范围

  changes：监控key的变化量

  简单来说，就是在seconds时间内，如果有changes个数据发生变化，就进行持久化存储

• 范例

  save 900 1
  save 300 10
  save 60 10000

• 其他

  dbfilename filename
  dir path
  rdbcompression yes|no
  rdbchecksum yes|no
  stop-writes-on-bgsave-error yes|no

配置文件其实和前面的一样，因为都是进行的一件事，只不过最后一个会自动执行

save配置工作原理

save配置需要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的

save配置启动后执行的是bgsave操作

RDB三种启动方式对比

RDB特殊启动形式

• 服务器运行过程中重启

  debug reload

• 关闭服务器时指定保存数据

  shutdown save

• 全量赋值（在主从复制中详解）

RDB优点

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快跟多
• 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

RDB缺点

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能

• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

  出现这种情况可以先把redis数据导出到excel或者数据库，再更换redis版本，重新导入

AOF

RDB存储的弊端

• 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
• 大数据量下的IO性能较低
• 基于fork创建子进程，内存产生额外消耗
• 宕机带来的数据丢失风险

解决思路

• 不写全数据，仅记录部分数据
• 降低区分数据是否改变的难度，改记录数据为记录操作过程
• 对所有操作均进行记录，排除丢失数据的风险

AOF概念

• AOF(Append Only File)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
• AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

目前的持久化方案中，AOF是主流方案

AOF写数据过程

启动AOF相关配置

• 开启AOF持久化功能，默认no，即不开启状态

  appendonly yes|no

• AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

  appendfilename filename

• AOF持久化文件保存路径，与RDB持久化文件保持一致即可

  dir path

• AOF写数据策略，默认为everysec

  appendfsync always|everysec|no

AOF写数据三种策略

• always(每次)：每次写入操作均同步到AOF文件中

  数据零误差，性能较低，不建议使用

• everysec(每秒)：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据

  数据准确性较高，性能较高，建议使用，也是默认配置

• no(系统控制)：由操作系统控制每次同步到AOF文件的周期

  整体过程不可控，一般不使用

只会记录对数据有影响的操作，get和未删除成功的del等操作不会记录

手动AOF重写机制与工作原理

如果客户端对同一个数据进行多次set，AOF就会出现不必要的记录

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干条命令执行结果转化成最终结果数据对应的指令进行记录

重写作用

• 降低磁盘占用量，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高IO性能
• 降低数据恢复用时，提高数据恢复效率

重写规则

• 进程内具有时效性的数据，并且数据已超时将不再写入文件
• 非写入类的无效指令将被忽略，只保留最终数据的写入命令

• 对同一数据的多条写命令合并为一条命令

  为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

重写方式

• 手动重写

  bgrewriteaof

• 自动重写

  auto-aof-rewrite-min-size size——按照大小判断是否自动重写

  auto-aof-rewrite-percentage percentage——按照百分比判断是否自动重写

工作原理

AOF自动重写方式

• 自动重写触发条件设置

  auto-aof-rewrite-min-size size

  auto-aof-rewrite-percentage percentage

• 自动重写触发比对参数（运行指令info Persistence获取具体信息）

  aof_current_size——aof当前尺寸大小

  aof_base_size——aof基础尺寸大小

• 自动重写触发条件

  aof_current_size > auto-aof-rewrite-min-size

  (aof_base_size - aof_current_size) / aof_base_size >= auto-aof-rewrite-percentage

重写流程

区别

RDB VS AOF

RDB与AOF的选择之惑

对数据非常敏感，建议使用默认的AOF持久化方案

• AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
• 注意：由于AOF文件存储体积较大，且恢复速度较慢

数据呈现阶段有效性，建议使用RDB持久化方案

• 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
• 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结

综合对比

• RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
• 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
• 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
• 灾难恢复选用RDB
• 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量