什么是Redis

Redis是一个使用C语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库
Redis可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种类型：字符串、列表、集合、散列表、有序集合

与传统数据库不同的是Redis的数据是存在内存中的，所以读写速度非常快，因此Redis被广泛应用于缓存方向，每秒可处理10万次读写操作
Redis也可以用来做分布式锁
Redis支持事务、持久化、LUA脚本、LRU驱动事件、多种集群方案

Redis的优缺点

优点

读写性能优异
支持数据持久化
支持事务
数据结构丰富
支持主从复制

缺点

数据库容量收到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合场景主要局限于较小数据量的高性能操作和运算
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂，为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费

除了Redis，还有哪些缓存实现方式

缓存可以分为分布式缓存和本地缓存
Redis可以作为分布式缓存，当分布式部署时各个服务器之间可以保持缓存数据的一致性，但是需要保证其可用性，Redis可使用哨兵模式来保证其可用性

Map可以用来做本地缓存，使用Map的key-value键值对来保存数据，速度更快，其生命周期是和JVM一致的，当JVM销毁时，本地缓存也随之消失。当部署分布式时，每台服务器上的缓存数据都是独立存在的，不能保证相互之间的一致性

Redis为什么这么快

1、完全基于内存，纯内存操作，非常快速。
2、数据结构简单，数据操作也很简单
3、采用单线程，避免了不必要的上下文切换和竞争条件
4、使用多路I/O复用模型，非阻塞IO
5、Redis构建了自己的VM机制，省去了部分不必要的移动和请求时间

Redis的数据类型

数据类型	可以存储的值	操作	应用场景
STRING	字符串、整数或者浮点数	对整个字符串或者字符串的其中一部分执行操作；对整数和浮点数执行自增或者自减操作	做简单的键值对缓存；短信验证码、配置信息
LIST	列表	从两端压入或者弹出元素对单个或者多个元素进行修剪，只保留一个范围内的元素	存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的数据；省市区表、字典表、最新的...、消息队列
SET	无序集合	添加、获取、移除单个元素；检查一个元素是否存在于集合中	交集、并集、差集的操作，比如交集，可以把两个人的粉丝列表整一个交集；查找两个人共同的好友
HASH	包含键值对的无序散列表	添加、获取、移除、单个键值对；获取所有键值对；检查某个键是否存在	结构化的数据，比如一个对象；商品详情、个人信息详情、新闻详情
ZSET	有序集合	添加、获取、删除元素；根据分值范围或者成员来获取元素；计算一个键的排名	去重但可以排序，如获取排名前几的用户；top 10

Redis持久化

持久化就是把内存的数据写到磁盘中，防止服务宕机了内存数据丢失

Redis提供两种持久化机制RDB（默认）和AOF机制

RDB：是Redis DataBase缩写快照

RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的方式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期

优点

• 只有一个文件dump.rdb，方便持久化

• 容灾性好，一个文件可以保存到安全的磁盘

• 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化。主进程不进行任何IO操作，保证了redis的高性能

• 相对于数据集大时，比AOF的启动效率更高

缺点

• 数据安全性低。RDB是隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

AOF:持久化

AOF（Append-Only file）是指所有的命令行记录以redis命令请求协议的格式完全持久化存储，保存为aof文件。当重启Redis会重新从持久化的日志中恢复数据

当两种方式同时开启时，数据恢复Redis时会优先选择AOF恢复

优点

1. 数据安全，aof持久化可以配置appendfsync属性，有always，每进行一次命令操作就记录到aof文件中一次

2. 通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题

3. AOF的rewrite模式。AOF文件没被rewritr之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令

缺点

1. AOF文件比RDB文件大，且恢复速度慢

2. 数据集大得时候，比rdb启动效率低

---

1. AOF文件比RDB更新频率高，优先使用AOF还原数据

2. AOF比RDB更安全也更大

3. RDB性能比AOF好

4. 如果两个都配了。优先加载AOF

Redis持久化数据和缓存怎么做扩容？

• 如果Redis被当作缓存使用，使用一致性哈希实现动态扩容缩容

• 如果Redis被当作一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，结点的数量一旦确定不能变化

过期键的删除策略

Redis的过期键的删除策略

过期策略通常有以下三种

• 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好，但会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量

• 惰性过期：只有当访问一个key时，才会判断key是否过期，过期则清楚。该策略可以最大化地节省CPU资源，却对内存不太友好。极端情况下可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存

• 定期过期：每隔一定的时间，会扫描一定数量地数据库地expires字典中一定数量地key，并清除其中已过期地key，该策略是前两者地一个折中方案，通过调整定时扫描地时间间隔和每次扫描地限定耗时，可以在不同情况下是的CPU和内存资源达到最优的平衡

Redis中同时使用了惰性过期和定期过期两种过期策略

Redis key的过期时间和永久有效分别怎么设置？

EXPIRE和PERSIST命令

内存相关

Mysql里有2000W数据，redis中只存20W的数据，如何保证redis中的数据都是热点数据

redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略

Redis的内存淘汰策略

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外的数据

全局的键空间选择性移除

• noeviction：当内存不足以容纳新写入数据时，新写入数据会报错

• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常使用的）

• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key

设置过期时间的键空间选择性移除

• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key

• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key

• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

Redis主要消耗什么物理资源

内存

Redis的内存用完了会发生什么？

如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回）或者你可以配置内存淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容

Redis如何做内存优化？

散列表

尽可能使用散列表（hash），散列表使用的内存非常小

缩减键值对象

key长度：设计键规则时，在完整完整描述业务情况下，键值越短越好
value长度：值对象缩减常见的方式就是将业务数据对象序列化二进制数组，序列化需要注意两点
（1）精简对象信息，避免无用信息的存储
（2）序列化工具的选择，选择更为高效的序列化工具可以有效降低字节数组的大小

共享对象池

共享对象池指的是Redis内部维护这[0-9999]的整数对象池。创建大量的整数类型redis对象存在内存开销，每个redis对象内部结构至少占16字节，甚至超过了整数自身空间消耗。所以redis内部维护了一个[0-9999]的整数对象池，用于节省内存

设置内存上限

使用maxmemory参数限制最大可用内存，当超出内存上限时使用LRU等删除策略释放空间以及防止所用内存超过服务器物理内存

配置内存回收策略

Redis所用内存达到maxmemory上限时会触发相应的溢出控制策略。具体策略受maxmemory-policy参数控制，Redis支持6种策略
（1）noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息OOM，command not allowed when used memory,此时Redis只响应读操作
（2）volatile-lru：根据LRU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。
（3）allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止
（4）allkeys-random：随机删除所有键，直到腾出足够空间为止
（5）volatile-random：随即删除过期键，直到腾出足够空间为止
（6）volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略

字符串优化

字符串对象是Redis内部最常用的数据类型。所有的键都是字符串类 型，值对象数据除了整数之外都使用字符串存储。在使用过程中应当尽量优先使用整数，比字符串类型更节省空间。并且要优化字符串使用，避免预分配造成的内存浪费。使用ziplist压缩编码优化hash、list等结构，注重效率和空间的平衡，使用intset编码优化整数集合。使用ziplist编码的hash结构降低小对象链规模。

编码优化

Redis对外提供了多种数据类型，但是Redis内部对于不同类型的数据使用的内部编码不一样。内部编码不同将直接影响数据的内存占用和读写效率。

控制键的数量

当Redis存储的数据越来越多，必然会存在大量的键，过多的键同样会消耗大量的内存

Redis线程模型

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器（file event handler）。它的组成结构分为4部分：多个套接字、IO多路复用器、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型

• 文件事件处理器使用I/O多路复用程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器

• 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，与操作对应的文件事件就会产生，这是文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件

为啥 redis 单线程模型也能效率这么高？

• 纯内存操作

• 核心是基于非阻塞的 IO 多路复用机制

• 单线程反而避免了多线程的频繁上下文切换问题

事务

什么是事务？

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求打断

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行

Redis事务的概念

Redis事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中

Redis事务的三个阶段

1. 事务开始MULTI

2. 命令入队

3. 事务执行EXEC

事务执行过程中，如果服务端收到EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队

Redis事务相关命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH四个原语实现的

Redis会将一个事务中的所有命令序列化，然后按顺序执行

1. redis不支持回滚，“Redis在事务失败时不进行回滚，而是继续执行余下的命令”，所以Redis的内部可以保持简单且快速

2. 如果在一个事务中的命令出现错误，那么所有的命令都不会执行

3. 如果在一个事务中出现运行错误，那么正确的命令会被执行

• WATCH命令是一个乐观锁，可以为Redis事务提供check-and-set（CAS）行为，可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会被执行，监控一直持续到EXEC命令

• MULTI命令用于开启一个事务，它总是返回OK。MULTI执行后，客户端可以继续向服务器发送多条命令，这些命令不会被立即执行，而是放到一个队列里，当EXEC命令执行时，所有队列中的命令才会被执行

• EXEC：执行所有事务块内的命令，返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回值null

• 通过执行DISCARD，客户端可以清空事务队列。并放弃执行事务，并且客户端会从事务状态中退出

• UNWATCH命令可以取消watch对所有key的监控

事务管理（ACID）概述

原子性、一致性、隔离性、持久性

Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的，当服务器运行在AOF持久化模式下，并且appendfsync选项的值未always时，事物也具有耐久性

Redis事务支持隔离性吗

Redis是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis的事务总是带有隔离性的

Redis事务保证原子性吗，支持回滚吗

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令失败，其余的命令仍会被执行

集群方案

主从复制

主机数据更新后根据配置和策略，自动同步到master/slave机制，Master以写为主，Slave以读为主

主少从多、主写从读、读写分离、主写同步复制到从

一主二从

搭建过程静等后续吧

哨兵模式

哨兵的介绍

sentinel，中文名是哨兵。哨兵是redis集群架构中非常重要的一个组件，主要有以下功能

• 集群监控：负责监控redis master和slave进程是否正常工作

• 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

• 故障转移：如果master node挂掉了，会自动转移到slave node上

• 配置中心：如果故障转移发生了，通知client客户端新的master地址

哨兵用于实现redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同去工作

• 故障转移时，判断一个master node是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题

• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单节点的，就很扯淡

哨兵的核心知识

• 哨兵至少需要3个实例，来保证自己的健壮性

• 哨兵+redis主从的部署架构，是不保证数据零丢失的，只能保证redis集群的高可用性

• 对于哨兵+redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

操作命令

数据库操作

127.0.0.1:6379> select 3  #切换到3号数据库，默认0号数据库
127.0.0.1:6379> dbsize  #查看数据库大小
127.0.0.1:6379> keys *  #查看所有的key
127.0.0.1:6379> flushdb  #清空当前数据库
127.0.0.1:6379> flushall  #清空所有数据库内容
127.0.0.1:6379> exists 'key'  #判断某个key是否存在
127.0.0.1:6379> move 'key' 1  #移除某个key，后面的1代表数据库
127.0.0.1:6379> expire 'key' 10  #设置某个key过期时间，10表示10秒
127.0.0.1:6379> ttl 'key'  #查看某个key剩余时效
127.0.0.1:6379> set 'key' 'value'  #set一个key
127.0.0.1:6379> type 'key'  #查看当前key的类型

数据类型及对应操作

String

127.0.0.1:6379> append 'key' 'value'  #在key对应的value上追加字符串
127.0.0.1:6379> strlen 'key'  #获取字符串长度
127.0.0.1:6379> incr 'key'  #当前key加1
127.0.0.1:6379> decr 'key'  #当前key减1
127.0.0.1:6379> incrby 'key' 10  #当前key增加10
127.0.0.1:6379> decrby 'key' 10  #当前key减少10
127.0.0.1:6379> getrange 'key' 0 3  #截取当前字符串
127.0.0.1:6379> getrange 'key' 0 -1  #获取全部的字符串 和 get key是一样的
127.0.0.1:6379> setrange 'key' 1 xxx  #替换指定位置开始的字符串
127.0.0.1:6379> setnx 'key' 30 xxx  #设置当前key的过期时间
127.0.0.1:6379> setnx 'key' xxx  #不存在再设置（在分布式锁中常使用）
127.0.0.1:6379> mset k1 v1 k2 v2 k3 v3  #同时设置多个值
127.0.0.1:6379> mget k1 k2 k3  #同时获取多个值
127.0.0.1:6379> msetnx k1 v2 k4 v4  #msetnx 是一个原子性操作，要么一起成功，要么一起失败

List

127.0.0.1:6379> lpush list one   #将一个值或者多个值，插入到列表的头部（左）
127.0.0.1:6379> rpush list one   #将一个值或者多个值，插入到列表的尾部（右）
127.0.0.1:6379> lrange list 0 -1    #获取list中的值
127.0.0.1:6379> lrange list 0 1    #通过区间获取list中具体的值
127.0.0.1:6379> lpop list    #移除当前list中的第一个值
127.0.0.1:6379> rpop list    #移除当前list中的最后一个值
127.0.0.1:6379> lindex list 1   #通过下标获取list的某一个值
127.0.0.1:6379> llen list    #返回列表的长度
127.0.0.1:6379> lrem list 1 one   #移除list集合中指定个数的value，精确匹配；移除列表中的1个one
127.0.0.1:6379> lrem list 2 one   #移除list集合中指定个数的value，精确匹配；移除列表中的2个one
127.0.0.1:6379> ltrim list 1 2    #通过下标截取指定的长度   改变list，list只剩下截取的元素
127.0.0.1:6379> rpoplpush list targetlist #移除列表的最后一个元素并将其移动到另一个列表中
127.0.0.1:6379> lset list 0 item #将列表中指定下标的值替换为另一个值
127.0.0.1:6379> linsert list before "world" "other" #将某个具体的值插入列表中某个元素的前面
127.0.0.1:6379> linsert list after "world" "other" #将某个具体的值插入列表中某个元素的后面

Set

127.0.0.1:6379> sadd myset "world" #set集合中添加元素
127.0.0.1:6379> smembers myset  #查看set集合中的元素
127.0.0.1:6379> sismembers myset hello  #查看set集合是否包含某个元素
127.0.0.1:6379> scard myset  #获取set集合中的内容元素个数
127.0.0.1:6379> srem myset hello #移除set集合中的某个元素
127.0.0.1:6379> srandmember myset  #随机抽选出一个元素
127.0.0.1:6379> srandmember myset 2  #随机抽选出指定个数的元素
127.0.0.1:6379> spop myset  #随机移除元素
127.0.0.1:6379> smove myset targetset  #移动指定的元素到指定的集合
127.0.0.1:6379> sdiff set1 set2  #获取两个集合的差集
127.0.0.1:6379> sinter set1 set2  #获取两个集合的交集   共同好友可以这样实现
127.0.0.1:6379> sunion set1 set2  #获取两个集合的并集

Hash

127.0.0.1:6379> hset myhash key value  #set一个具体的key-value
127.0.0.1:6379> hget myhash key  #获取一个key对应的value
127.0.0.1:6379> hmset myhash key value key1 value1  #set多个具体的key-value
127.0.0.1:6379> hmget myhash key key1   #s获取多个value
127.0.0.1:6379> hgetall myhash    #获取所有的key-value
127.0.0.1:6379> hdel myhash  key  #删除hash指定的key，对应的value也不见了
127.0.0.1:6379> hlen myhash  #获取hash的长度
127.0.0.1:6379> hexists myhash key #判断hash中指定字段是否存在
127.0.0.1:6379> hkeys myhash  #获取所有的key
127.0.0.1:6379> hvals myhash  #获取所有的value
127.0.0.1:6379> hincrby myhash key 1 #hash中指定key自增1
127.0.0.1:6379> hdecrby myhash key 1 #hash中指定key自减1
127.0.0.1:6379> hsetnx myhash key value #如果存在则可以设置
#hash变更的数据，hash更适合存储对象

Zset（有序集合）

127.0.0.1:6379> zset myzset 1 one #添加一个值到zset
127.0.0.1:6379> zset myzset 2 two 3 three  #添加多个值到zset
127.0.0.1:6379> zrange myzset 0 -1  #获取zset的所有值
127.0.0.1:6379> zrangebyscore myzset -inf +inf  #获取zset的所有值，从小到大排序
127.0.0.1:6379> zrevrange myzset 0 -1  #获取zset的所有值，从大到小
127.0.0.1:6379> zrem myzset zzz  #移除有序集合中的指定元素
127.0.0.1:6379> zcard myzset  #获取有序集合中的个数
127.0.0.1:6379> zcount myzset targer 1 3  #获取指定区间的成员数量
#消息设置权重    普通消息；重要消息；紧急消息

Hyperloglog

PFadd mykey a b c d e f g h i j #创建第一组元素
PFcount mykey #统计mykey的元素的基数数量
PFadd mykey2 i j z y x c v b #创建第二组元素
PFcount mykey2 #统计第二组元素
PFMERGE mykey3 mykey mykey2  #合并两组 mykey mykey2 => mykey3 并集
PFCOUNT mykey3 #看并集的数量


#如果允许容错，那么一定可以使用Hyperloglog,如果不允许容错，就使用set

事务

事务的原则：ACID：原子性、一致性、隔离性、持久性

Redis单条命令保存原子性，但是事务不保证原子性

Redis事务的本质：一组命令的事务

开启事务  multi
命令入队  
执行事务  exec

127.0.0.1:6379> multi  #开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> exec  #执行事务
1) OK
2) OK
127.0.0.1:6379>


#放弃事务  事务中的命令都不会被执行
127.0.0.1:6379> discard


#异常
##编译型异常 命令有错，事务中所有命令都不会执行
##运行时异常 如果事务队列中存在语法性，那么执行命令时，其他命令是可以正常执行的，错误命令会抛出异常

Redis事务没有隔离级别的概念

所有的命令在事务中，并没有直接被执行，只有发起执行命令的时候才会执行

！！！！！Redis的watch可以实现乐观锁的操作

watch money  #监视money
multi        #开启事务
incrby money #命令入队  money+1
decrby money #命令入队  money-1
exec         #比对监视的值是否发生了变化，如果没有变化，那么可以执行成功，如果有变化就执行失败

Redis.conf详解

1、配置文件unit单位第一大小写不敏感
2、includes可以包含多个配置文件的信息
3、network
    bind 127.0.0.1  #绑定的ip
    protected-mode yes #保护模式
    port 6379 #端口设置
4、daemonize yes  #以守护进程的方式运行，默认是no，我们需要自己开启为yes
5、pidfile /var/run/redis_6379.pid  #如果以后台的方式运行，我们就需要指定一个pid文件
6、loglevel  notice #日志级别
7、log file“” #日志的文件路径
8、databases 16 # 数据库的数量，默认是16个数据库
9、always-show-logo yes #是否总是显示logo
10、持久化，在规定的时间内，执行多少次操作则会持久化到 .rdb .aof
redis是内存数据库，如果没有持久化，那么数据断电即失
    save 900 1   # 如果 900s 内，至少有 1 个 可以进行了修改，我们就进行持久化操作
    save 300 10 # 如果 300s 内，至少有 10 个 可以进行了修改，我们就进行持久化操作
    save 60 1000 # 如果 60s 内，至少有 1000 个 可以进行了修改，我们就进行持久化操作
11、stop-writes-on-bgsave-error yes #如果持久化出错，redis是否正常工作
12、rdbcompression yes  #是否压缩rdb文件，需要消耗一些cpu资源
13、rdbchecksun yes #保存rdb文件时，进行错误的校验
14、dir ./ #rdb 文件保存的目录#

########限制CLIENTS#########
15、maxclients 1000 # 设置能连接上redis的最大客户端的数量
16、maxmemory <bytes> # redis 配置最大的内存容量
17、maxmemory-policy noeviction # 内存到达上之后的处理策略
TODO 需要补充策略

########APPEND ONLY 模式 AOF配置#########
18、appendonly no #默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分的情况下，rdb完全够用
19、appendfilename "appendonly.aof" #持久化文件的名字
20、 appendfsync always #每次修改都会sync , 消耗性能
    appendfsync everysec #每秒执行一次sync,可能会丢失这1s的数据
    appendfsync no #不执行sync,这个时候操作系统自己同步数据，速度最快

触发持久化机制（RDB）

1、save的规则满足的情况下，会自动触发rdb规则
2、执行flushall命令，也会触发我们的rdb规则
3、退出redis,也会产生rdb文件

####如果要恢复rdb文件，只需要将rdb文件放在redis启动目录就可以，redis启动的时候会自动检查dump.rdb，恢复其中的数据
####优点：1、适合大规模的数据恢复
#### 2、对数据的完整性要求不高
####缺点：1、需要一定的时间间隔进程操作，如果redis意外宕机，这个最后一次的操作将会丢失

AOF(Append Only File)（默认不开启，需手动开启，重启redis生效）

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

1、AOF在大数据的情况下效率很低
2、AOF被破坏的话，redis将不能启动；可以使用 redis-check-aof --fix  进行修复

本文为学习笔记，参考多篇文章及教学视频，如有侵权，请后台联系