Redis支持的数据类型：
string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。
string类型是Redis最基本的数据类型，一个键最大能存储512MB。
- 能表达三种类型：字符串、整数和浮点数。根据场景相互间自动转换，并且根据需要选取底层的承载方式
- value内部以int、sds作为结构存储。int存放整型数据，sds存放字节/字符串和浮点型数据
- sds内部结构：
- 用buf数组存储字符串的内容，但数组的长度会大于所存储内容的长度。会有一格专门存放” ”（C标准库）作为结尾，还有预留多几个空的（即free区域），当append字符串的长度小于free区域，则sds不会重新申请内存，直接使用free区域
- 扩容：当对字符串的操作完成后预期的串长度小于1M时，扩容后的buf数组大小=预期长度*2+1；若大于1M，则buf总是会预留出1M的free空间
- value对象通常具有两个内存部分：redisObject部分和redisObject的ptr指向的sds部分。创建value对象时，通常需要为redisObject和sds申请两次内存。单对于短小的字符串，可以把两者连续存放，所以可以一次性把两者的内存一起申请了
hash（map） 是一个键值对集合，特别适合用于存储对象。每个 hash 可以存储 2的32 - 1次方 键值对（40多亿）。
- map又叫hash。map内部的key和value不能再嵌套map了，只能是string类型：整形、浮点型和字符串
- map主要由hashtable和ziplist两种承载方式实现，对于数据量较小的map，采用ziplist实现
- hashtable内部结构
- 主要分为三层，自底向上分别是dictEntry、dictht、dict
- dictEntry：管理一个key-value对，同时保留同一个桶中相邻元素的指针，一次维护哈希桶的内部连
- dictht：维护哈希表的所有桶链
- dict：当dictht需要扩容/缩容时，用于管理dictht的迁移
- 哈希表的核心结构是dictht，它的table字段维护着hash桶，它是一个数组，每个元素指向桶的第一个元素（dictEntry）
- set值的流程：先通过MurmurHash算法求出key的hash值，再对桶的个数取模，得到key对应的桶，再进入桶中，遍历全部entry，判定是否已有相同的key，如果没有，则将新key对应的键值对插入到桶头，并且更新dictht的used数量，used表示hash表中已经存了多少元素。由于每次插入都要遍历hash桶中的全部entry，所以当桶中entry很多时，性能会线性下降
- 扩容：通过负载因子判定是否需要增加桶数。负载因子=哈希表中已有元素/哈希桶数的比值。有两个阈值，小于1一定不扩容；大于5一定扩容。扩容时新的桶数目是现有桶的2n倍
- 缩容：负载因子的阈值是0.1
- 扩/缩容通过新建哈希表的方式实现。即扩容时，会并存两个哈希表，一个是源表，一个是目标表。通过将源表的桶逐步迁移到目标表，以数据迁移的方式实现扩容，迁移完成后目标表覆盖源表。迁移过程中，首先访问源表，如果发现key对应的源表桶已完成迁移，则重新访问目标表，否则在源表中操作
- redis是单线程处理请求，迁移和访问的请求在相同线程内进行，所以不会存在并发性问题
list 列表是简单的字符串列表，按照插入顺序进行排序，可以添加一个元素导列表的头部（左边）或者尾部（右边）。
- list类型的value对象内部以linkedlist或ziplist承载。当list的元素个数和单个元素的长度较小时，redis会采用ziplist实现以减少内存占用，否则采用linkedlist结构
- linkedlist内部实现是双向链表。在list中定义了头尾元素指针和列表的长度，是的pop/push操作、llen操作的复杂度为O(1)。由于是链表，lindex类的操作复杂度仍然是O(N)
- ziplist的内部结构
- 所有内容被放置在连续的内存中。其中zlbytes表示ziplist的总长度，zltail指向最末元素，zllen表示元素个数，entry表示元素自身内容，zlend作为ziplist定界符
- rpush、rpop、llen，复杂度为O(1);lpush/pop操作由于涉及全列表元素的移动，复杂度为O(N)
set 集合是string类型的无需集合，通过哈希表实现，添加，删除，查找的复杂度都是O(1)。若插入相同元素时，第二次的插入将被忽略。
- set以intset或hashtable来存储。hashtable中的value永远为null，当set中只包含整数型的元素时，则采用intset
- intset的内部结构
- 核心元素是一个字节数组，从小到大有序存放着set的元素
- 由于元素有序排列，所以set的获取操作采用二分查找方式实现，复杂度O(log(N))。进行插入时，首先通过二分查找得到本次插入的位置，再对元素进行扩容，再将预计插入位置之后的所有元素向右移动一个位置，最后插入元素，插入复杂度为O(N)。删除类似
zset 有序集合，也是string类型元素的集合,且不允许重复的成员。
- 类似map是一个key-value对，但是有序的。value是一个浮点数，称为score，内部是按照score从小到大排序
- 内部结构以ziplist或skiplist+hashtable来实现
Redis是什么
MemcacheDB是一个分布式、key-value形式的持久存储系统。它不是一个缓存组件，而是一个基于对象存取的、可靠的、快速的持久存储引擎
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
用redis实现分布式锁
- 主要使用的命令：
- setnx key val。当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。
- expire key timeout。为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
- delete key。删除锁
- 实现思想：
- 使用setnx加锁，如果返回1，则说明加锁成功，并设置超时时间，避免系统挂了，锁没法释放。在finally中delete删除锁释放。
- 如果需要设置超时等待时间，则可以加个while循环，在获取不到锁的情况下，进行循环获取锁，超时了则退出。
缓存算法：
- FIFO算法：First in First out，先进先出。原则：一个数据最先进入缓存中，则应该最早淘汰掉。也就是说，当缓存满的时候，应当把最先进入缓存的数据给淘汰掉。
- LFU算法：Least Frequently Used，最不经常使用算法。
- LRU算法：Least Recently Used，近期最少使用算法。
- LRU和LFU的区别。LFU算法是根据在一段时间里数据项被使用的次数选择出最少使用的数据项，即根据使用次数的差异来决定。而LRU是根据使用时间的差异来决定的。
回收策略：
-
volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据进行淘汰，Redis将回收那些超时的（仅仅是超时的）键值对，即：它只淘汰那些超时的键值对。
-
allkeys-lru：从数据集中挑选最近最少使用的数据进行淘汰，淘汰最近最少使用的key-value，Redis将对所有（不仅仅是超时的）的键值对采用最近最少使用的淘汰策略。
-
volatile-lfu：淘汰最近最不常用的key-value，Redis将淘汰在一定时期内被访问次数最少的超时键值对。
-
allkeys-lfu：淘汰最近最不常用的key-value，Redis将对所有的键值对采用最近最不常用的淘汰策略。
-
volatile-random：从已设置过期时间的数据集中任意选择数据进行淘汰。采用随机淘汰策略删除超时的键值对。
-
allkeys-random：从数据集中任意选择数据进行淘汰。采用随机淘汰策略删除所有的键值对，这个策略不常用。
-
volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据进行淘汰。采用删除存活时间最短的键值对策略。
-
noeviction：禁止驱逐数据，不淘汰任何键值对。当内存达到限制的最大内存并且客户端还在继续执行会占用内存的命令时，会返回错误。当内存满时，如果进行读操作，例如get命令它将正常工作，而做写操作它将返回错误。即：当Redis采用这个策略内存达到最大的时候，它就只能读不能写了。
Redis默认采用noeviction策略。
一般的经验规则:
- 使用allkeys-lru策略：当你希望你的请求符合一个幂定律分布，也就是说，你希望部分的子集元素将比其它其它元素被访问的更多。如果你不确定选择什么，这是个很好的选择。
- 使用allkeys-random：如果你是循环访问，所有的键被连续的扫描，或者你希望请求分布正常（所有元素被访问的概率都差不多）。
- 使用volatile-ttl：如果你想要通过创建缓存对象时设置TTL值，来决定哪些对象应该被过期。
缓存雪崩：可能是因为数据未加载到缓存中，或者在设置缓存采用了相同的过期时间，导致缓存在某一时刻同时大面积失效，从而导致所有请求都转发到数据库去查询，导致数据库CPU和内存负载过高，甚至宕机。
解决思路：
- 线程互斥：只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据才可以，每个时刻只有一个线程在执行请求，减轻了db的压力，但缺点也很明显，降低了系统的qps。
- 交错失效时间：可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
- 分析用户行为，然后失效时间均匀分布。
- 如果是某台缓存服务器宕机，则考虑做主备。
缓存穿透：是指查询一个一定不存在的数据，由于缓存是请求数据不命中时被动写入的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，在流量大时数据库可能就挂掉了，通俗说就是恶意用户模拟请求很多缓存中不存在的数据，由于缓存中都没有，导致这些请求短时间内直接落在了数据库上，导致数据库异常。从系统层面来看像是穿透了缓存层直接达到db。
解决思路：
-
空值缓存：一种比较简单的解决办法，在第一次查询完不存在的数据后，将该key与对应的空值也放入缓存中，只不过设定为较短的失效时间，最长不超过五分钟。这样则可以应对短时间的大量的该key攻击，设置为较短的失效时间是因为该值可能业务无关，存在意义不大，且该次的查询也未必是攻击者发起，无过久存储的必要，故可以早点失效。
-
布隆过滤器(bloom filter)：类似于哈希表的一种算法，将所有可能存在的数据哈希到一个足够大的bitmap中，在进行数据库查询之前会使用这个bitmap进行过滤，如果一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
缓存击穿：对于一些设置了过期时间的key，如果这些key在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候可能会发生缓存被“击穿”的问题，和缓存雪崩的区别在于：缓存击穿是针对某一/几个key缓存，缓存雪崩则是很多key。当缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
比如：微博有一个热门话题的功能，用户对于热门话题的搜索量往往在一些时刻会大大的高于其他话题，这种我们成为系统的“热点“，由于系统中对这些热点的数据缓存也存在失效时间，在热点的缓存到达失效时间时，此时可能依然会有大量的请求到达系统，没有了缓存层的保护，这些请求同样的会到达db从而可能引起故障。击穿与雪崩的区别即在于击穿是对于特定的热点数据来说，而雪崩是全部数据。
解决思路：
- 二级缓存：对于热点数据进行二级缓存，并对于不同级别的缓存设定不同的失效时间，则请求不会直接击穿缓存层到达数据库。
- 互斥锁(mutex key): 只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据即可。
- LRU算法：根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。最常见的实现是使用一个链表保存缓存数据，缓存步骤： 首先将新数据放入链表的头部 在进行数据插入的过程中，如果检测到链表中有数据被再次访问也就是有请求再次访问这些数据，那么就其插入的链表的头部，因为它们相对其他数据来说可能是热点数据，具有保留时间更久的意义 最后当链表数据放满时将底部的数据淘汰，也就是不常访问的数据
缓存并发：如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。
解决思路：对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。
缓存预热：目的就是在系统上线前，将数据加载到缓存中。
解决思路：数据量不大的话，在系统启动的时候直接加载。或者自己写个简单的缓存预热程序。
Redis的事务命令：
Redis 事务允许一组命令在单一步骤中执行。事务有两个特点：
- 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- Redis 事务是原子的。原子意味着要么所有的命令都执行，要么都不执
MULTI：标记一个事务块的开始。
EXEC：执行所有事务块内的命令。
DISCARD：取消事务，放弃执行事务块内的所有命令。
WATCH key[key ...]：监视一个或多个key，若事务在执行这个key之前被其他命令所改动，那么事务将被打断。
UNWATCH：取消 WATCH 命令对所有 key 的监视。
举个栗子：
redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days" QUEUED redis 127.0.0.1:6379> GET book-name QUEUED redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series" QUEUED redis 127.0.0.1:6379> SMEMBERS tag QUEUED redis 127.0.0.1:6379> EXEC 1) OK 2) "Mastering C++ in 21 days" 3) (integer) 3 4) 1) "Mastering Series" 2) "C++" 3) "Programming"
Redis设置密码：
第一种方式（修改配置文件） Sudo vim /etc/redis/redis.conf 命令模式搜索requirepass，把注释掉的那行打开 # requirepass footbared requirepass 123456 第二种方式：直接在redis中设置，只对当前启动有效 设置密码：config set requirepass 123456 取消密码：config set requirepass “”
Redis的存储机制：
RDB （快照Snapshot）工作原理: 将databases中的key-value的二进制形式存储在了rdb文件中。先将数据存在内存，然后当数据累计达到某些设定的阀值的时候，就会触发一次DUMP操作，将变化的数据一次性写入数据文件（RDB文件）。
AOF 工作原理: 是将数据也是先存在内存，但是在存储的时候会使用调用fsync来完成对本次写操作的日志记录，这个日志揭露文件其实是一个基于Redis网络交互协议的文本文件。AOF调用fsync也不是说全部都是无阻塞的，在某些系统上可能出现fsync阻塞进程的情况，对于这种情况可以通过配置修改，但默认情况不要修改。AOF最关键的配置就是关于调用fsync追加日志文件的平率，有两种预设频率，always每次记录进来都添加，everysecond 每秒添加一次。两个配置各有所长后面分析。由于是采用日志追加的方式来持久话数据，所以引出了第二个日志的概念：rewrite. 后面介绍它的由来。
无论是那种机制,Redis都是将数据存储在内存中。
性能&安全比较：
性能：
RDB方式的性能明显高于AOF方式，RDB采用压缩的二进制方式存储数据，数据文件比较小，加载快速。存储的时候是按照配置项中的save策略来存储，每次都是聚合很多数据批量存储，写入的效率很好，而AOF则一般都是工作在实时存储或者准实时模式下。相对来说存储的频率高，效率却偏低。
数据安全：
AOF数据安全性高于RDB存储，Snapshot存储是基于累计批量的思想，也就是在允许的情况下，累计的数据越多那么写入效率也就越高，但数据的累计是靠时间的积累完成的，那么如果在长时间数据不写入RDB，但Redis又遇到了崩溃，那么没有写入的数据就无法恢复了，但是AOF方式偏偏相反，根据AOF配置的存储频率的策略可以做到最少的数据丢失和较高的数据恢复能力。
Redis常见性能问题？
1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要保存写内存快照。
2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，可使用某个Slave开启AOF备份数据，策略为每秒同步一次。
3).Master调用 BGREWRITEAOF 重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
4).Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内
Redis适用场景
（1）会话缓存（Session Cache）最常使用，优势在于：Redis提供持久化。比如用户的购物车数据。
（2）全页缓存（FPC）
（3）队列 ，Reids提供的 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，类似于Python当中对 list 的 push/pop 操作。
（4）排行榜/计数器
Redis特点：
- 速度快：使用标准C写，所有数据都在内存中完成，读写速度分别达到10万/20万
- 持久化：对数据的更新采用Copy-on-write技术，可以异步地保存到磁盘上，主要有两种策略，一是根据时间，更新次数的快照（save 300 10 ）二是基于语句追加方式(Append-only file，aof)
- 自动操作：对不同数据类型的操作都是自动的，很安全
- 快速的主--从复制，官方提供了一个数据，Slave在21秒即完成了对Amazon网站10G key set的复制。
- Sharding技术： 很容易将数据分布到多个Redis实例中，数据库的扩展是个永恒的话题，在关系型数据库中，主要是以添加硬件、以分区为主要技术形式的纵向扩展解决了很多的应用场景，但随着web2.0、移动互联网、云计算等应用的兴起，这种扩展模式已经不太适合了，所以近年来，像采用主从配置、数据库复制形式的，Sharding这种技术把负载分布到多个特理节点上去的横向扩展方式用处越来越多。
缺点：
- 是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
- Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
- Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复。
- 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了系统的可用性。
-
Redis 的主从复制采用全量复制，复制过程中主机会 fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦
Redis使用场景：
- 1. 取最新 N 个数据的操作
- 2. 排行榜应用,取 TOP N 操作
- 3. 需要精准设定过期时间的应用
- 4. 计数器应用
- 5. uniq 操作,获取某段时间所有数据排重值
- 6. Pub/Sub 构建实时消息系统
- 7. 构建队列系统
- 8. 缓存
Redis宕机？
主从模式下的宕机区分：
- slave从机宕机：在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；如果从数据库实现了持久化，只要重新假如到主从架构中会实现增量同步。
- Master 宕机：假如主从都没数据持久化，此时千万不要立马重启服务，否则可能会造成数据丢失，正确的操作如下：
- 在slave数据上执行SLAVEOF ON ONE,来断开主从关系并把slave升级为主库
- 此时重新启动主数据库，执行SLAVEOF,把它设置为从库，自动备份数据。
注：以上过程很容易配置错误，可以使用简单的方法：redis的哨兵（sentinel）的功能。
哨兵（sentinel）的原理：Redis提供了sentinel（哨兵）机制通过哨兵模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决。
心跳机制：每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。
投票裁决：若"哨兵群"中的多数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。
哨兵的配置：复制redis中sentinel.conf，根据情况进行配置
Redis持久化方式：
- RDB 持久化(Redis DataBase)可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
- AOF 持久化(Append-only file)记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
- Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
RDB 快照
在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动保存一次数据集。
执行保存操作：调用 SAVE 或者 BGSAVE ，手动让 Redis 进行数据集保存操作。一个栗子，save 60 1000 会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集。这种持久化方式被称为快照（snapshot）。
SAVE：阻塞redis的服务器进程，直到RDB文件被创建完毕。BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。
快照的运作方式
当Redis需要保存 dump.rdb 文件时，执行以下操作：
- Redis 调用
fork()，同时拥有父进程和子进程。 - 子进程将数据集写入到一个临时 RDB 文件中。
- 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。
RDB 优点
- RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
- 生成的文件是一种压缩的二进制文件，方便于在网络中传输。
- RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是
fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。 - RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
RDB 缺点
- 如果想要避免在服务器故障时丢失数据，那么 RDB 不太适合。 RDB保存一次备份之后，到下一次保存之前，这段期间所产生的的新数据，如果还没有达到生成备份文件的条件，此时服务器宕机就会丢失这部分数据。虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是因为 RDB 文件需要保存整个数据集的状态，所以它是一个非常耗费系统资源的操作。 因此若是需要至少 5 分钟才保存一次 RDB 文件的情况下， 一旦发生故障停机，可能会丢失好几分钟的数据。
- 每次保存 RDB 的时候，Redis 都要
fork()创建出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行fork()，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。创建子线程和生成rdb文件会占用大量 的系统资源和处理时间
RDB 配置文件
# dbfilename：配置RDB文件的名称，默认叫 dump.rdb dbfilename dump.rdb # dir：配置的RDB文件存储在本地的路径，如果是在 /redis/redis-3.0.6/src 下启动的redis-cli，则数据会存储在当前src目录下 dir ./ # snapshot触发时机的配置：save <seconds> <changes> ， 可通过 save “” 关闭snapshot功能 # changes：对于此值设置需谨慎，要评估系统的变更操作密集程度 save 900 1 # 更改了1个key的时候，间隔900秒后，至少有一个变更操作，进行持久化存储snapshot save 300 10 # 更改了10个key的时候，间隔300s进行持久化存储 save 60 10000 # 更改10000个key的时候，间隔360s进行存储。 # 当生成 RDB 文件出错无法继续时，是否则色客户端的“变更操作”，是否继续处理 Redis 写命令，默认为不处理。“错误”可能因为磁盘已满/磁盘故障/OS级别异常等 stop-writes-on-bgsave-error yes # 是否对rdb文件进行压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的 rdbcompression yes
# 是否对 RDB 文件进行校验和校验
rdbchecksum
RDB 命令演示
Redis shutdown模拟服务器宕机
mv dump.rdb dump.rdb.bak
停止redis服务器service redis stop
启动redis-server /etc/redis/redis.conf
redis-cli
查询keys *
cp dump.rdb.bak dump.rdb
ps aux | grep redis
Kill -9 xxxx
停止redis服务器service redis stop
重启redis-server
重启redis-cli
查询keys *
AOF：只进行追加操作的文件（append-only file）
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。如果对于数据追求完全耐久能力（full durability）的要求，快照功能就不太适用。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。
通过修改配置文件来打开 AOF 功能：appendonly yes 。每当 Redis 执行一个改变数据集的命令时（比如 SET key value [EX seconds] [PX milliseconds] [NX|XX]）， 这个命令就会被追加到 AOF 文件的末尾（对数据的每一条修改命令追加到aof文件）。这样的话，当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令。
AOF文件生成的过程：命令追加、文件写入、文件同步
AOF 重写（Rewrite）
因为 AOF 的运作方式是不断地将命令追加到文件的末尾，按照记录日志的方式去工作的，所以随着写入命令的不断增加，成千上万的数据插入必然导致日志文件的扩大，AOF 文件的体积也会变得越来越大。举个栗子：如果你对一个计数器调用了 100 次 INCR key ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。然而实际上，只使用一条 SET key value [EX seconds] [PX milliseconds] [NX|XX] 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。
为了处理这种情况， Redis 支持另一种特性：可以在不打断服务客户端的情况下，对 AOF 文件进行重建（rebuild）：执行 BGREWRITEAOF 命令：将日志文件中的所有数据都重新写到另外一个新的日志文件中，不同的是，在旧文件当中对于key的多次操作，只会保留最终值的那次操作命令记录到日志文件中。Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写。
两个配置需要注意：
auto-aof-rewrite-percentage 100 （当前写入日志文件的大小占到初始日志文件大小的某个百分比时触发Rewrite）
auto-aof-rewrite-min-size 64mb （本次Rewrite最小的写入数据量）
两个条件需要同时满足。
AOF 的运作方式
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。
以下是 AOF 重写的执行步骤：
- Redis 执行
fork()，现在同时拥有父进程和子进程。 - 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾：这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
- 搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
AOF的优点
- 提供了多种同步命令方式，默认1s同步（
fsync）一次写命令，就算发生故障停机，最多丢失1s的数据。（fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求）。 - AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行查找(
seek)， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等），redis-check-aof工具也可以轻易地修复这种问题。 - Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作，如果你不小心执行了 FLUSHALL 命令，只要 AOF 文件未被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis，就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF 的缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。当Redis负载较高时，RDB比AOF性能更好。
- 根据所使用的
fsync策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒fsync的性能依然非常高， 而关闭fsync可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。 - AOF 曾经发生过的 bug ：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个栗子，阻塞命令 BRPOPLPUSH source destination timeout 就曾引起过这样的 bug）它们会自动生成随机、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种 bug 的。
AOF 配置文件
# 是否打开 AOF 持久化功能，默认为“no”，可通过“yes”来开启AOF功能 appendonly yes # 只有在“yes”下，aof重写/文件同步等特性才会生效 # 指定AOF文件的名称 appendfilename appendonly.aof # 同步频率：指定AOF操作时，文件的同步策略，有三个合法值：always everysec no,默认为everysec 会影响到服务器间隔多久完成一次命令的记录。 # always：每一条aof记录都立即同步到文件，这是最安全的方式，但大量磁盘操作和阻塞延迟造成IO开支大，速度最慢不推荐。 # everysec：将缓存区的内容每隔一秒写入AOF文件中，性能和安全都比较中庸，是Redis官方推荐的方式。 # no ：写入AOF文件中的操作由操作系统决定，Redis不直接调用。一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。在物理服务器故障时，数据丢失量会因OS配置有关 appendfsync everysec # 在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no” no-appendfsync-on-rewrite no # aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb” auto-aof-rewrite-min-size 64mb # 相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。 # 每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后，触发下一次rewrite，每一次aof记录的添加都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100
# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mbRDB和AOF如何选择
- AOF更加安全，可以将数据更加及时的同步到文件中，但是AOF需要较多的磁盘IO开支，AOF文件尺寸较大，文件内容恢复数度相对较慢
- RDB（snapshot），安全性较差，它是“正常时期”数据备份以及 master-slave 数据同步的最佳手段，文件尺寸较小，恢复数度较快。
（1）不要仅仅使用RDB，因为那样会导致你丢失很多数据
（2）也不要仅仅使用AOF，因为那样有两个问题，第一，通过AOF做冷备的操作，没有RDB做冷备来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug 。
（3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。
怎么从 RDB 持久化切换到 AOF 持久化
在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：
- 为最新的
dump.rdb文件创建一个备份。 - 将备份放到一个安全的地方。
- 执行以下两条命令：
redis-cli> CONFIG SET appendonly yes redis-cli> CONFIG SET save ""
- 确保命令执行之后，数据库的键的数量没有改变。
- 确保写命令会被正确地追加到 AOF 文件的末尾。
步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。
步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。
别忘了在 redis.conf 中打开 AOF 功能！ 否则服务器重启之后， 之前通过 CONFIG SET 设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。
对比
AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。RDB持久化，安全性较差，它是正常时期数据备份及master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。
备份 Redis 数据
官方建议：
- 创建一个定期任务（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹。
- 确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用
find命令来删除过期的快照： 比如可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照。 - 至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服务器的物理机器之外。
从数据集中任意选择数据进行淘汰