Redis（一）Redis_NoSQL入门概述、Redis的安装、redis数据类型介绍以及Redis的持久化

redis系列笔记
Redis（一）Redis_NoSQL入门概述、Redis的安装、redis数据类型介绍以及Redis的持久化.
redis（二）redis事务、主从复制以及缓存雪崩、穿透.

第一章NoSQL入门和概述

1.1入门概述

1.1.1为什么要用nosql

• 1.单机MySQL的美好时代
  • 一个网站的访问量一般都不大，而且更多的是静态页面，动态交互类型的网站不多，用单个数据库完全可以轻松应对。
  • 上述架构下，数据存储的瓶颈是什么？
    • 数据量的总大小一个机器放不下时
    • 数据的索引（B+Tree）一个机器的内存放不下时
    • 访问量（读写混合）一个实例不能承受
• 2.Memcached（缓存）+MySQL+垂直拆分
  • 随着访问量的上升，几乎发部分使用MySQL架构的网站在数据库上都开始出现性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带来了比较高的IO压力。因此，Memcached就成为了一个非常时尚的技术产品
    。
• 3.Mysql主从读写分离
  • 由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配。
• 4.分表分库+水平拆分+mysql集群
  • 在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这是MySQL的主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISQM。
  • 同时开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就是在这个时候，MySQL推出了还不太稳定的表分区，虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只能在高可靠性上提供了非常大的保证。
• 5.MySQL的扩展性瓶颈
  • MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速回复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正式当前使用MySQL的开发人员面临的问题。
• 6.为什么用NoSQL
  • 今天我们可以通过第三方平台（如Google，Facebook等）可以很容易的访问和抓取数据。用户个人信息，社交网络，地理位置，用户产生的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了，NoSQL数据库的发展却能很好的处理这些大的数据。

1.1.2nosql是什么

• NoSQL（NoSQL = Not Only SQL），意思是不仅仅是SQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包含超大规模数据的存储。
• （例如古河或Facebook每天为他们的用户手机万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。

1.1.3nosql能干嘛

• 易扩展
  • NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。
  • 数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
• 大数据量高性能
  • NoSQL数据里都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
• 多样灵活的数据模型.
  • NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。

1.1.4nosql怎么用

• KV
• Cache
• Persistence

1.2 3v和3高

1.2.1大数据时代的3V

• 海量Volume
• 多样Variety
• 实时Velocity

1.2.2互联网需求的3高

• 高并发
• 高可扩
• 高性能

1.3NoSQL数据模型简介

• 以一个电商客户、订单、订购、地址模型来对比下关系性数据库和非关系型数据库
  • 传统的关系型数据库你如何设计？
    • ER图（1:1/1:N/N:N,主外键等常见）
    • 具体的表有客户表、订单表、订单详情表、地址表、支付表、产品表等
  • Nosql你如何设计？
    • 给学生用BSON画出构建的数据模型
    • 什么是BSON？BSON()是一种类json的一种二进制形式的存储格式，简称为Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象。
  • 两者对比，问题和难点
    • 为什么上述的情况可以用聚合模型来处理
      • 高并发的操作是不太建议有关联查询的，互联网公司用冗余数据来避免关联查询
      • 分布式事务是支持不了太多的并发的
    • 关系型数据库如何查询？如果按照我们新设计的BSON，是不是查询起来很方便
• 聚合模型
  • KV键值
  • Bson
  • 列族
  • 图形

1.4NoSQL数据库的四大分类

• KV键值对：
  新浪：BerkeleyDB + Redis
  美团：Redis + Tair
  阿里、百度：Redis + memecache
• 文档型数据库（bson格式 和json一样）：
  • MongoDB （一般必须要掌握）
    • MongoDB 是一个基于分布式文件存储的数据库，C++ 编写，主要用来处理大量的文档！
    • MongoDB 是一个介于关系型数据库和非关系型数据中中间的产品！MongoDB 是非关系型数据库中功能最丰富，最像关系型数据库的！
  • ConthDB
• 列存储数据库
  HBase
  分布式文件系统
• 图关系数据库
  • 他不是存图形，放的是关系，比如：朋友圈社交网络，广告推荐！专注于构建关系图谱
  • Neo4j，InfoGrid
• 四者对比：
  

1.5 在分布式数据库中CAP原理CAP+BASE

1.5.1传统的ACID分别是什么

• A（Atomicity）原子性
  整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过一样。
• C（Consistency）一致性
  • 一个事务可以封装状态改变(除非它是一个只读的)。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。
  • 也就是说:如果事务是并发多个，系统也必须如同串行事务一样操作。其主要特征是保护性和不变性(Preserving an Invariant)，以转账案例为例，假设有五个账户，每个账户余额是100元，那么五个账户总额是500元，如果在这个5个账户之间同时发生多个转账，无论并发多少个，比如在A与B账户之间转账5元，在C与D账户之间转账10元，在B与E之间转账15元，五个账户总额也应该还是500元，这就是保护性和不变性。
• I（Isolation）隔离性
  隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
• D（Durability）持久性
  在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚

1.5.2CAP

• C：Consistency（强一致性）
  访问所有的节点得到的数据应该是一样的。注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。
• A：Availability（可用性）
  所有的节点都保持高可用性。注意，这里的高可用还包括不能出现延迟，比如如果节点B由于等待数据同步而阻塞请求，那么节点B就不满足高可用性。
  也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集
• P：Partion tolerance（分区容错性）
  这里的分区是指网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

1.5.2CAP的3进2

• CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,因此,根据CAP原理将NoSQL数据库分成了满足CA原则,满足CP原则和满足AP原则三大类:

  • CA-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强太;
  • CP-满足一致性,分区容忍必的系统,通常性能不是特别高;
  • AP-满足可用性,分区容错性的系统,通常可能对一致性要求低一些;

• 在某个节点挂掉的时候 要满足c 强一致性 就必须要down掉所有的节点但是 满足a高可用性 就只需要挂掉这一个节点 他们是互相矛盾的，所以只能3进2

• 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
  所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

• C:强一致性 A：高可用性 P：分布式容忍性

  • CA 传统Oracle数据库
  • AP 大多数网站架构的选择
  • CP Redis、Mongodb

• 注意：分布式架构的时候必须做出取舍。

• 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向

• 一致性与可用性的决择

  • 从 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

  • 数据库事务一致性需求

    • 很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。

  • 数据库的写实时性和读实时性需求

    • 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

  • 对复杂的SQL查询，特别是多表关联查询的需求

    • 任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

1.5.3BASE

• BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

• BASE其实是下面三个术语的缩写：
  基本可用（Basically Available）
  软状态（Soft state）
  最终一致（Eventually consistent）

• 它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法。

1.5.4分布式+集群简介

• 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。
• 集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。

第二章Redis入门介绍

2.1入门概述

2.1.1是什么

• Redis：REmote DIctionary Server（远程字典服务器）
• 是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的（key/value）分布式内存数据库，基于内存运行并支持持久化的NoSQL数据库，被称为数据结构数据库。
• Redis与其他key-value缓存产品有一下三个特点
  • Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
  • Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
  • Redis支持数据的备份，即master-slave模式的数据备份。

2.1.2.能干嘛

• 内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务。
• 取最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面
• 模拟类似于HttpSession这种需要设定过期时间的功能。
• 发布、订阅消息系统
• 定时器、计数器

2.1.3.去哪下

• http://redis.io/
• http://www.redis.cn/

2.1.4.怎么用

• 数据类型、基本操作和配置
• 持久化和复制，RDB/AOF
• 事务的控制
• 复制

2.2.Redis的安装

• Windows版安装
• 重要提示：
  企业做Redis开发，99%都是Linux版的运用和安装。
• Linux版安装

  • 1.下载获得redis-3.0.4.tar.gz后将它放入我们的Linux目录/opt
    指令是wget http://download.redis.io/releases/redis-6.0.5.tar.gz

  • 2./opt目录下，解压命令：tar xzf redis-3.0.0.tar.gz

  • 3.解压完成后出现文件夹：redis-3.0.0，然后执行指令cd redis-3.0.0

  • 4.在redis-3.0.4目录下执行make命令

    • 运行make命令时如果出现错误解析（未安装gcc）：
      • 安装gcc（gcc是linux下的一个编译程序，是C程序的编译工具）
      • 能上网：yum install gcc-c++
      • 二次make

  • 如果make完成后继续执行make install

  • 查看默认安装目录：usr/local/bin

  • l另外存一份用作操作（一般不在原文件操作）：新建一个文件夹，将redis-3.0.0文件下的redis.conf拷贝到新建文件夹下，并且用vim命令更改其内容 daemonize yes （这里讲原来的no改为yes,目的是为了设置后台运行）
    
    

  • 查看redis是否启动
    

  • 若未启动 ，则在安装目录bin下输入redis-server /myredis/redis.conf 外加redis-cli -p 6379

  • 永远的helloworld

  • 关闭

  • 

2.3.Redis启动后杂项基础知识讲解

2.3.1单进程

• 单进程模型来处理客户端的请求。对读写等时间的响应是通过对epoll函数的包装来做到的。Redis的实际处理速度完全依靠主进程的执行效率。
• Epoll是Linux内核为处理大批量文件描述符而作了改进的epoll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃情况下的系统CPU利用率。

2.3.2基础知识

• 默认16个数据库，类似数组下表从零开始，初始默认使用零号库
  

• Select命令切换数据库
  

• dbsize查看当前数据库的key的数量
  

• Flushdb：清空当前库

• Flushall：通杀全部库

• 同一密码管理，16个库都是同样密码，要么都ok要么一个也连不上

• Redis索引都是从零开始

• 默认端口是6379

第三章Redis数据类型

3.1Redis的五大数据类型

• String（字符串）
  • string是redis最基本的类型，可以理解为Memcached一样的类型，一个key对应一个value。
  • string类型是二进制安全的，意思是redis的string可以包含任何数据。比如ipg图片或者序列化的对象。
  • string类型是Redis最基本的数据结构，一个redis中字符串value最多可以是512M。
• Hash（哈希，类似java里的Map）
  • Redis hash是一个键值对集合。
  • Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
  • 类似java里面的Map
• List（列表）
  • Redis列表是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）。
  • 它的底层是一个链表。
• Set（集合）
  • Redis的Set是string类型的无序集合。它是通过HashTable实现的。
• Zset（sorted set：有序集合）
  • Redis zset和set一样也是string类型元素的集合，且不允许重复的成员。
  • 不同的是每个元素都会关联一个double类型的分数。
  • redis正是通过分数来为集合中的成员进行从小到大排序。zset的成员是唯一的，但分数（score）却可以重复。
• 哪里去获得redis常见数据类型操作命令
  http://redisdoc.com/

3.2 Redis键（key）

• 案例
  keys *
  exists key的名字,判断某个key是否存在
  move key db -->当前库就没有了，被移出了
  expire key 秒钟：为给定的key设置过期时间
  ttl key查看还有多少秒过期，-1表示永不过期，-2表示已过期
  type key 查看你的key是什么类型
  

3.3 Redis字符串（String）

• 单值单value
• 案例
  set/get/del/append/strlen
  Incr/decr/incrby/decrby,一定要是数字才能进行加减
  getrange（获取指定区间内的值，从零到负一表示全部)/setrange（设置指定范围的值，就是从制定位置替换）
  setex(set with expire)键秒值/setnx(set if not exist)
  mset/mget/msetnx
  getset(先get在set)
  
  
  

3.4 Redis列表（List）

• 所有的list命令都是用l开头的，Redis不区分大小命令

• 单值多value

• 案例

  • lpush/rpush/lrange（从零到负一表示全部）
  • lpop/rpop
  • lindex,按照索引下表获得元素（从上到下）
  • llen 长度
    

• • lren key 删N个value

  • ltrim key 开始index 结束index，截取指定范围的值后再赋值给key
    

  • rpoplpush 源列表 目的列表
    

  • lset key index value

  • linsert key before/after 值1 值2
    

  • 性能总结

    • 它是一个字符链表，left，right都可以插入添加。
      如果键不存在，创建新的链表。
      如果键已经存在，新增内容。
      如果值全移除，对应的键也就消失了。
      链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。

3.5 Redis集合（Set）

• set中的值是不能重读的！
• 单值多value
• 案例

  • sadd/smembers（不用写从零到负一就表示全部，到但是不能重读）/sismember

  • scard,获取集合里面的元素个数

  • srem key value 删除集合中元素

  • srandmember key 某个整数（随机出几个数）

  • spop key 随机出栈
    

  • smove key2 key2 在key1里某个值 作用是将key1里的某个值赋给key2
    

  • 数学集合类
    差集：sdiff key1 key2 (key1有并且key2 没有的元素)
    交集：sinter
    并集：sunion
    

3.6 Redis哈希（Hash）

• KV模式不变，但V是一个键值对（具体指：Map< String,Map< String,Object>>）
• 案例
  • 重点：hset/hget/hmset/hgetall/hdel

• • hlen
  • hexists key 在key里面的某个值的key
  • 重点：hkey/hvals
  • hincrby/hincrbyfloat
  • hsetnx
    

3.7 Redis有序集合Zset（sorted set）

• 和set的区别：在set基础上加上一个score值，之前set是k1 v1 v2 v3,现在zset是k1 score1 v1 score2 v2
• 案例
  • zadd/zrange/zrange带withscores
    
  • zrangebyscore key 开始score 结束score
    • （ 表示不包含
    • limit作用是返回限制 limit开始下标步 多少步
      
  • zrem key 某score下对应的value值，作用是删除元素
  • zcard/zcount key score区间/zrank key values值，作用是获得下标值/zscore key 对应值，获得分数
  • zrevrank key values值，作用是逆序获得下标值
  • zrevrange 作用是逆序输出
  • zrevrangebyscore key 结束score 开始score
    

第四章Redis的持久化

• Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能
• redis持久化的两种方式
  方式一:RDB将当前数据快照到.rdb格式文件。
  方式二:AOF将写操作追加到缓冲区，再将缓冲区的操作同步到磁盘。

4.1RDB(Redis DataBase)

4.1.1 什么是RDB

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！

4.1.2Fork

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量‘程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

4.1.3 配置位置

• 有时候在生产环境我们会将这个文件进行备份！
• rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的！
  
• 临时笔记，确定redis是否启动
• 方式一：检测后台进程是否存在 ps -ef | grep redis
• 方式二：检测6379端口是否在监听 netstat -lntp | grep 6379

4.1.4触发

默认：
是一分钟内改一万次
或5分钟内改了10次
或15分钟内改了一次

• 触发条件
  1、save的规则满足的情况下，会自动触发rdb规则
  2、执行 flushall 命令，也会触发我们的rdb规则！
  3、退出redis，也会产生 rdb 文件！
  备份就自动生成一个 dump.rdb

4.1.5恢复

• 1、只需要将rdb文件（之前自己手动备份的）放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！
• 2、查看需要存在的位置
  
• 若文件异常，用check-dump修复再重启即可

4.1.6优缺点

• 优点：
  1、适合大规模的数据恢复！
  2、对数据的完整性要求不高！
• 缺点：
  1、需要一定的时间间隔进程操作！如果redis意外宕机了，这个最后一次修改数据就没有了！
  2、fork进程的时候，会占用一定的内容空间

4.1.7小总结

• RDB是一个非常紧凑的文件
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所有RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。
• 缺点：
  • 数据丢失风险大
  • RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能导致Redis在一些毫秒级不能响应客户端请求。

4.2AOF(Append Only File)

• 将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍！

4.2.1 AOF是什么

• 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
• Aof保存的是 appendonly.aof 文件

4.2.2配置位置

• 默认是不开启的，我们需要手动进行配置！我们只需要将 appendonly 改为yes就开启了 aof！
• 重启，redis 就可以生效了！

4.2.3AOF启动/修复/恢复

• 正常恢复
  • 启动：设置Yes
  • 将有数据的aof文件复制一份保存到对应目录（config get dir）
  • 恢复：重启redis然后重新加载
    注：aof是将所有的写操作都备份到appendonly.aof中
• 异常恢复
  • 启动：设置Yes
  • 备份被写坏的AOF文件
  • 修复：
    redis-check-aof --fix进行修复
  • 恢复：
    重启redis然后重新加载
    

4.2.4Rewrite

• 是什么
  AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令gbrewriteaof
• 重写原理
  AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
• 触发机制
  Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
  

4.2.5优缺点

• 优势
  • 每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
  • 每修改同步：appendfsync everysec（默认） 异步操作 ，每秒记录 如果一秒内宕机，有数据丢失。
  • 不同步：appendfsync no 从不同步
• 劣势
  • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  • AOF运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

4.2.6小总结

• AOF文件时一个只进行追加的日志文件
  Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
  AOF文件有序地保存了对数据执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
• 缺点：
  对相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。
  根据所使用的fsync策略，AOF的速度可能会慢于RDB。

4.3总结

• RDB和AOF可以共存，但是恢复的时候找的是AOF，如果AOF文件异常，可以通过check-aof进行AOF修复。
• 两种持久化方式的对比：
  • 1）RDB不能实时持久化数据，如果redis服务器断电可能存在丢失数据的风险。而AOF方式持久化做到实时持久化数据。
  • 2）加载RDB恢复数据远快于AOF方式。因为RDB是二进制数据，而AOF是日志的形式。
  • 3）如果用高版本redis进行RDB持久化的文件用到低版本redis启动恢复会出现不兼容的问题。
• 如果你的数据很大，又希望快速的恢复和备份，换句话说你如果对数据完整性要求低的话，只简单的使用rdb即可
• 扩展：
  • RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储
  • AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
  • 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
  • 同时开启两种持久化方式
    • 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
    • RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。
  • 性能建议
    • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
    • 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
    • 如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。