Redis&持久化存储

Redis支持的数据类型：

string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

string类型是Redis最基本的数据类型，一个键最大能存储512MB。

1. 能表达三种类型：字符串、整数和浮点数。根据场景相互间自动转换，而且根据须要选取底层的承载方式
2. value内部以int、sds做为结构存储。int存放整型数据，sds存放字节/字符串和浮点型数据
3. sds内部结构： 
• 用buf数组存储字符串的内容，但数组的长度会大于所存储内容的长度。会有一格专门存放”\0”（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多亿）。

1. map又叫hash。map内部的key和value不能再嵌套map了，只能是string类型：整形、浮点型和字符串
2. map主要由hashtable和ziplist两种承载方式实现，对于数据量较小的map，采用ziplist实现
3. 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 列表是简单的字符串列表，按照插入顺序进行排序，能够添加一个元素导列表的头部（左边）或者尾部（右边）。

1. list类型的value对象内部以linkedlist或ziplist承载。当list的元素个数和单个元素的长度较小时，redis会采用ziplist实现以减小内存占用，不然采用linkedlist结构
2. linkedlist内部实现是双向链表。在list中定义了头尾元素指针和列表的长度，是的pop/push操做、llen操做的复杂度为O(1)。因为是链表，lindex类的操做复杂度仍然是O(N)
3. ziplist的内部结构 
   • 全部内容被放置在连续的内存中。其中zlbytes表示ziplist的总长度，zltail指向最末元素，zllen表示元素个数，entry表示元素自身内容，zlend做为ziplist定界符
   • rpush、rpop、llen，复杂度为O(1);lpush/pop操做因为涉及全列表元素的移动，复杂度为O(N)

 

set 集合是string类型的无需集合，经过哈希表实现，添加，删除，查找的复杂度都是O(1)。若插入相同元素时，第二次的插入将被忽略。

1. set以intset或hashtable来存储。hashtable中的value永远为null，当set中只包含整数型的元素时，则采用intset
2. intset的内部结构 
   • 核心元素是一个字节数组，从小到大有序存放着set的元素
   • 因为元素有序排列，因此set的获取操做采用二分查找方式实现，复杂度O(log(N))。进行插入时，首先经过二分查找获得本次插入的位置，再对元素进行扩容，再将预计插入位置以后的全部元素向右移动一个位置，最后插入元素，插入复杂度为O(N)。删除相似

 

zset 有序集合，也是string类型元素的集合,且不容许重复的成员。

1. 相似map是一个key-value对，可是有序的。value是一个浮点数，称为score，内部是按照score从小到大排序
2. 内部结构以ziplist或skiplist+hashtable来实现

 

 

Redis是什么

Redis是一个支持网络、基于内存、也可持久性的键值对存储数据库。和Memcached相似，但它支持存储的value类型相对更多，包括string(字符串)、list(列表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove、取交集并集和差集等其余操做，并且这些操做都是原子性的，此外Redis中单个value的最大限制是1GB，不像 memcached只能保存1MB的数据。 Redis 整个数据库统统加载在内存当中进行操做，按期经过异步操做把数据库数据flush到硬盘上进行保存。由于是纯内存操做，Redis每秒能够处理超过10万次读操做 8万次写操做，是已知性能最快的Key-Value DB。所以Redis能够用来实现不少有用的功能，比方说利用List实现一个FIFO双向链表，可做为一个轻量级的高性能消息队列服务，利用Set能够作高性能的tag系统等等。另外Redis也能够对存入的Key-Value设置expire时间，所以也能够被看成一个功能增强版的memcached来用。

Redis支持主从同步。数据能够从主服务器向任意数量的从服务器上同步，从服务器能够是关联其余从服务器的主服务器。这使得Redis可执行单层树复制。同步对读取操做的可扩展性和数据冗余颇有帮助。redis协议位于TCP层之上，即客户端和redis实例保持双工的链接，交互的都是序列化后的协议数据。

MemcacheDB是一个分布式、key-value形式的持久存储系统。它不是一个缓存组件，而是一个基于对象存取的、可靠的、快速的持久存储引擎

Redis的主要缺点是数据库容量受到物理内存的限制，不能用做海量数据的高性能读写，所以Redis适合的场景主要局限在较小数据量的高性能操做和运算上。

 

用redis实现分布式锁

1. 主要使用的命令： 
   • setnx key val。当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不作，返回0。
   • expire key timeout。为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
   • delete key。删除锁
2. 实现思想： 
• 使用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 文件时，执行如下操做：

1. Redis 调用 fork() ，同时拥有父进程和子进程。
2. 子进程将数据集写入到一个临时 RDB 文件中。
3. 当子进程完成对新 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 重写的执行步骤：

1. Redis 执行 fork() ，如今同时拥有父进程和子进程。
2. 子进程开始将新 AOF 文件的内容写入到临时文件。
3. 对于全部新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾：这样即便在重写的中途发生停机，现有的 AOF 文件也仍是安全的。
4. 当子进程完成重写工做时，它给父进程发送一个信号，父进程在接收到信号以后，将内存缓存中的全部数据追加到新 AOF 文件的末尾。
5. 搞定！如今 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 64mb

 

RDB和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 ：

1. 为最新的 dump.rdb 文件建立一个备份。
2. 将备份放到一个安全的地方。
3. 执行如下两条命令：

redis-cli> CONFIG SET appendonly yes redis-cli> CONFIG SET save "" 

4. 确保命令执行以后，数据库的键的数量没有改变。
5. 确保写命令会被正确地追加到 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 服务器的物理机器以外。

 

 

从数据集中任意选择数据进行淘汰