Redis 深入学习 03

Redis 底层实现

Redis的五大数据类型也称五大数据对象；前面介绍过6大数据结构，Redis并没有直接使用这些结构来实现键值对数据库，而是使用这些结构构建了一个对象系统redisObject；这个对象系统包含了五大数据对象，字符串对象（string）、列表对象（list）、哈希对象（hash）、集合（set）对象和有序集合对象（zset）；而这五大对象的底层数据编码可以用命令OBJECT ENCODING来进行查看。

2、字符串对象(string)

字符串对象底层数据结构实现为简单动态字符串（SDS）和直接存储，但其编码方式可以是int、raw或者embstr，区别在于内存结构的不同。

字符串对象总结：

• • 在Redis中，存储long、double类型的浮点数是先转换为字符串再进行存储的。
  • raw与embstr编码效果是相同的，不同在于内存分配与释放，raw两次，embstr一次。
  • embstr内存块连续，能更好的利用缓存在来的优势
  • int编码和embstr编码如果做追加字符串等操作，满足条件下会被转换为raw编码；embstr编码的对象是只读的，一旦修改会先转码到raw

len（当前子字符串的长度）。

当Redis字符串进行删减操作时不会进行内存重分配，多余出来的空间也不会被回收，会留着为以后的添加做准备。

当然Redis也提供了一些接口供我们主动释放这些多余的空间

ziplist是redis为了节约内存而开发的顺序型数据结构。它被用在列表键和哈希键中。一般用于小数据存储。

ziplist是一个编码后的列表，是由一系列特殊编码的连续内存块组成的顺序型数据结构

redis 列表结构 底层实现(quicklist)

encoding
对于 list 对象, 早期的 redis 版本在数据量比较小时使用 ziplist 作为底层结构, 在数据量到临界值时转换为双端链表进行存储, OBJ_ENCODING_ZIPLIST 和 OBJ_ENCODING_LINKEDLIST 分别用来表示这两种结构, 他们升级转换的临界条件和 hash 对象中的升级 类似

当前的 Redis 版本不再使用的 ziplist 或者 双端链表, 而是引入了一种新的结构叫做 quicklist, 目的是最大程度减小内存空间占用并保证性能
quicklist是Redis在3.2版本加入的新数据结构，其是list列表的底层数据结构。

quicklist简介
为什么说quicklist是“二合一”呢？如果你看过STL中的deque的实现，就会知道deque是由一个map中控器和一个数组组成的数据结构，它既具有链表头尾插入便捷的优点，又有数组连续内存存储，支持下标访问的优点。Redis中是采用sdlist和ziplist来实现quicklist的，其中sdlist充当map中控器的作用，ziplist充当占用连续内存空间数组的作用。quicklist本身是一个双向无环链表，它的每一个节点都是一个ziplist。为什么这么设计呢？

双向链表在插入节点上复杂度很低，但它的内存开销很大，每个节点的地址不连续，容易产生内存碎片。
ziplist是存储在一段连续的内存上，存储效率高，但是它不利于修改操作，插入和删除数都很麻烦，复杂度高，而且其需要频繁的申请释放内存，特别是ziplist中数据较多的情况下，搬移内存数据太费时！

另外，在quicklist的源码中提到了一个LZF的压缩算法，该算法用于对quicklist的节点进行压缩操作。list的设计目的是能够存放很长的数据列表，当列表很长时，必然会占用很高的内存空间，且list中最容易访问的是两端的数据，中间的数据访问率较低，于是就可以从这个出发点来进一步节省内存用于其他操作。Redis提供了一下的配置参数，用于表示中间节点是否压缩。

list-compress-depth 0

参数list-compress-depth的取值和含义对应如下：

0 特殊值，表示不压缩
1 表示quicklist两端各有一个节点不压缩，中间的节点压缩
2 表示quicklist两端各有两个节点不压缩，中间的节点压缩
3 表示quicklist两端各有三个节点不压缩，中间的节点压缩

PUSH操作
quicklist最重要的操作就是首尾插入节点，此操作由quicklistPush函数实现。PUSH操作不管是头部还是尾部压入都包含两个步骤：

如果插入节点中的ziplist大小没有超过限制（list-max-ziplist-size），那么直接调用ziplistPush函数压入
如果插入节点中的ziplist大小超过了限制，则新建一个quicklist节点（自然会创建一个新的ziplist），新的数据项会压入到新的ziplist，新的quicklist节点插入到原有的quicklist上

哈希对象编码转换：

• • 哈希对象使用ziplist编码需要满足两个条件：一是所有键值对的键和值的字符串长度都小于64字节；二是键值对数量小于512个；不满足任意一个都使用hashtable编码。
  • 以上两个条件可以在Reids配置文件中修改hash-max-ziplist-value选项和hash-max-ziplist-entries选项。

渐进式 rehash 的好处在于它采取分而治之的方式， 将 rehash 键值对所需的计算工作均滩到对字典的每个添加、删除、查找和更新操作上， 从而避免了集中式 rehash 而带来的庞大计算量。

渐进式 rehash 执行期间的哈希表操作

因为在进行渐进式 rehash 的过程中， 字典会同时使用 ht[0] 和 ht[1] 两个哈希表， 所以在渐进式 rehash 进行期间， 字典的删除（delete）、查找（find）、更新（update）等操作会在两个哈希表上进行： 比如说， 要在字典里面查找一个键的话， 程序会先在 ht[0] 里面进行查找， 如果没找到的话， 就会继续到 ht[1] 里面进行查找， 诸如此类。

另外， 在渐进式 rehash 执行期间， 新添加到字典的键值对一律会被保存到 ht[1] 里面， 而 ht[0] 则不再进行任何添加操作： 这一措施保证了 ht[0] 包含的键值对数量会只减不增， 并随着 rehash 操作的执行而最终变成空表

对于有序集合zset，所有元素的长度小于64字节，元素个数也需要小于128个

当ziplist作为zset的底层存储结构时候，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个元素保存元素的分值。

 当skiplist作为zset的底层存储结构的时候，使用skiplist按序保存元素及分值，使用dict来保存元素和分值的映射关系。

skiplist跳跃列表中每个节点的数据格式，每个节点有保存数据的robj指针，分值score字段，后退指针backward便于回溯，zskiplistLevel的数组保存跳跃列表每层的指针。

zset存储过程

 zset的添加过程我们以zadd的操作作为例子进行分析，整个过程如下：

• 解析参数得到每个元素及其对应的分值
• 查找key对应的zset是否存在不存在则创建
• 如果存储格式是ziplist，那么在执行添加的过程中我们需要区分元素存在和不存在两种情况，存在情况下先删除后添加；不存在情况下则添加并且需要考虑元素的长度是否超出限制或实际已有的元素个数是否超过最大限制进而决定是否转为skiplist对象。
• 如果存储格式是skiplist，那么在执行添加的过程中我们需要区分元素存在和不存在两种情况，存在的情况下先删除后添加，不存在情况下那么就直接添加，在skiplist当中添加完以后我们同时需要更新dict的对象。

上图中整个跳表结构存放了4个元素5->10->20->30,图中的红色线表示查找元素30时，走的查找路线,从Head指针数组里最顶层的指针所指的20开始比较，与普通的链表查找相比，跳表的查询可以跳跃元素，上图中查询30，发现30比20大，则查找就是20开始，而普通链表的查询必须一个元素一个元素的比较，时间复杂度为O(n)

  有了上图所示的跳表基本结构，再看看如何向跳表中插入元素，向跳表中插入元素，由于元素所在层级的随机性，平均起来也是O(logn)，说白了，就是查找元素应该插入在什么位置，然后就是普通的移动指针问题，再想想往有序单链表的插入操作吧，时间复杂度是不是也是O(n),下图所示是往跳表中插入元素28的过程,图中红色线表示查找插入位置的过程，绿色线表示进行指针的移动，将该元素插入

有了跳表的查找及插入那么就看看在跳表中如何删除元素吧，跳表中删除元素的个程，查找要删除的元素，找到后，进行指针的移动，过程如下图所示，删除元素30

在代码中我们定义了跳表结构中保存的数据为Key->Value这种形式的键值对，注意的是skiplistNode里面内含了一个结构体,代表的是层级，并且定义了跳表的最大层级为32级,下面的代码是创建空跳表，以及层级的获取方式

Redis中跳表的基本数据结构定义如下，与基本跳表数据结构相比，在Redis中实现的跳表其特点是不仅有前向指针，也存在后向指针，而且在前向指针的结构中存在span跨度字段，这个跨度字段的出现有助于快速计算元素在整个集合中的排名

     a、从最高层开始枚举，对每一层找到  (score, obj)  的前驱结点；
        b、前驱结点的 score 要么小于 当前结点的 score，要么 score 和当前结点相等且 obj 的字典序比 当前结点的obj 小；
        c、对跨度进行累加，所有层的前驱结点的跨度之和就是最后要求的 Rank；
        d、为了避免找到的 x 是头结点，需要判断 x->obj 不为 NULL；
 

JAVA SkipList 跳表 的原理和使用例子

跳跃链表是一种随机化数据结构，基于并联的链表，其效率可比拟于二叉查找树(对于大多数操作需要O(log n)平均时间)，并且对并发算法友好。

基本上，跳跃列表是对有序的链表增加上附加的前进链接，增加是以随机化的方式进行的，所以在列表中的查找可以快速的跳过部分列表(因此得名)。

所有操作都以对数随机化的时间进行。

跳跃列表是按层建造的。底层是一个普通的有序链表。每个更高层都充当下面列表的"快速跑道"，这里在层 i 中的元素按某个固定的概率 p 出现在层 i+1 中。

平均起来，每个元素都在 1/(1-p) 个列表中出现，而最高层的元素(通常是在跳跃列表前端的一个特殊的头元素)在 O(log1/pn) 个列表中出现。

要查找一个目标元素，起步于头元素和顶层列表，并沿着每个链表搜索，直到到达小于或的等于目标的最后一个元素。

通过跟踪起自目标直到到达在更高列表中出现的元素的反向查找路径，在每个链表中预期的步数显而易见是 1/p。所以查找的总体代价是 O(log1/p n / p)，

当p 是常数时是 O(logn)。通过选择不同p 值，就可以在查找代价和存储代价之间作出权衡。

插入和删除的实现非常像相应的链表操作，除了"高层"元素必须在多个链表中插入或删除之外。
跳跃列表不像某些传统平衡树数据结构那样提供绝对的最坏情况性能保证，因为用来建造跳跃列表的扔硬币方法总有可能(尽管概率很小)生成一个糟糕的不平衡结构。

但是在实际中它工作的很好，随机化平衡方案比在平衡二叉查找树中用的确定性平衡方案容易实现。跳跃列表在并行计算中也很有用，

这里的插入可以在跳跃列表不同的部分并行的进行，而不用全局的数据结构重新平衡。

 我们知道Redis数据库作为一个内存数据库，与memcached比较类似，基本的操作都是存储在内存缓冲区中，等到缓冲区中数据满后，在持久化到磁盘中

二、Redis各类型的应用

1. string
   此类型和memcache相似，作为常规的key-value缓存应用。分布式锁，计数器，Web集群session共享，分布式xi't
   例如微博数、粉丝数等
   注：一个键最大能存储512MB
2. hash
   redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象(应为对象可能会包含很多属性)
   常用命令：hget hset hgetall；     以用户id为key，商品id为field，商品数量为value；
3. 主要用来存储对象信息

   

4. list
   list列表是简单的字符串列表，按照插入顺序排序(内部实现为LinkedList)，可以选择将一个链表插入到头部或尾部
   常用命令 :lpush（添加左边元素）,rpush,lpop（移除左边第一个元素）,rpop,lrange（获取列表片段，LRANGE key start stop）等。
   应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。
5. set
   案例：在微博中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
6. zset
   常用命令：zadd,zrange
   实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，跳跃表按score从小到大保存所有集合元素。使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。时间复杂度与红黑树相同，增加、删除的操作较为简单。
   输入方式
   应用场景：排行榜

Hlen key 返回购物车中用户购买商品的数量

hdel cart: 1001  10088  清除userId = 1001 下，商品skuId=10088

hgetall cart: 1001 获取购物车所有商品

相比string消耗内存和cpu更小  ，过期功能不能使用在field上，只能用在key上

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

一、redis 数据结构使用场景

原来看过 redisbook 这本书，对 redis 的基本功能都已经熟悉了，从上周开始看 redis 的源码。目前目标是吃透 redis 的数据结构。我们都知道，在 redis 中一共有5种数据结构，那每种数据结构的使用场景都是什么呢？

String——字符串
Hash——字典
List——列表
Set——集合
Sorted Set——有序集合

下面我们就来简单说明一下它们各自的使用场景：

1. String——字符串

String 数据结构是简单的 key-value 类型，value 不仅可以是 String，也可以是数字（当数字类型用 Long 可以表示的时候encoding 就是整型，其他都存储在 sdshdr 当做字符串）。使用 Strings 类型，可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受 Redis 的定时持久化（可以选择 RDB 模式或者 AOF 模式），操作日志及 Replication 等功能。除了提供与 Memcached 一样的 get、set、incr、decr 等操作外，Redis 还提供了下面一些操作：

1.LEN niushuai：O(1)获取字符串长度
2.APPEND niushuai redis：往字符串 append 内容，而且采用智能分配内存（每次2倍）
3.设置和获取字符串的某一段内容
4.设置及获取字符串的某一位（bit）
5.批量设置一系列字符串的内容
6.原子计数器
7.GETSET 命令的妙用，请于清空旧值的同时设置一个新值，配合原子计数器使用

2. Hash——字典

在 Memcached 中，我们经常将一些结构化的信息打包成 hashmap，在客户端序列化后存储为一个字符串的值（一般是 JSON 格式），比如用户的昵称、年龄、性别、积分等。这时候在需要修改其中某一项时，通常需要将字符串（JSON）取出来，然后进行反序列化，修改某一项的值，再序列化成字符串（JSON）存储回去。简单修改一个属性就干这么多事情，消耗必定是很大的，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而 Redis 的 Hash 结构可以使你像在数据库中 Update 一个属性一样只修改某一项属性值。

订单新客属性   field 和 value

用户再次下单后，会更新redis缓存集群中的新客属性
 

3. List——列表

List 说白了就是链表（redis 使用双端链表实现的 List），相信学过数据结构知识的人都应该能理解其结构。使用 List 结构，我们可以轻松地实现最新消息排行等功能（比如新浪微博的 TimeLine ）。List 的另一个应用就是消息队列，可以利用 List 的 *PUSH 操作，将任务存在 List 中，然后工作线程再用 POP 操作将任务取出进行执行。Redis 还提供了操作 List 中某一段元素的 API，你可以直接查询，删除 List 中某一段的元素。

4. Set——集合

Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

1.共同好友、二度好友
2.利用唯一性，可以统计访问网站的所有独立 IP
3.好友推荐的时候，根据 tag 求交集，大于某个 threshold 就可以推荐

4.点击参与抽奖，加入集合；查看参与抽奖所有用户，抽取count名中奖者；微博点赞，取消点赞；获取点赞的用户列表

5.共同关注的人

5. Sorted Set——有序集合

和Sets相比，Sorted Sets是将 Set 中的元素增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列，比如一个存储全班同学成绩的 Sorted Sets，其集合 value 可以是同学的学号，而 score 就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用 Sorted Sets 来做带权重的队列，比如普通消息的 score 为1，重要消息的 score 为2，然后工作线程可以选择按 score 的倒序来获取工作任务。让重要的任务优先执行。

1.带有权重的元素，比如一个游戏的用户得分排行榜
2.比较复杂的数据结构，一般用到的场景不算太多

二、redis 其他功能使用场景

1. 订阅-发布系统

Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在 Redis 中，你可以设定对某一个 key 值进行消息发布及消息订阅，当一个 key 值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

2. 事务——Transactions

谁说 NoSQL 都不支持事务，虽然 Redis 的 Transactions 提供的并不是严格的 ACID 的事务（比如一串用 EXEC 提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个 Transactions 还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis 还提供了一个 Watch 功能，你可以对一个 key 进行 Watch，然后再执行 Transactions，在这过程中，如果这个 Watched 的值进行了修改，那么这个 Transactions 会发现并拒绝执行。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Redis 5 中引入了一个名为 Streams 的新的 Redis 数据结构，吸引了社区极大的兴趣。接下来，我会在社区里进行调查，同用户们谈谈他们在实际生产中的使用场景，然后写个博客记录一下。

今天我想解决另一个问题：我有点怀疑许多用户仅仅把Streams 作为解决类似 Kafka 所要解决的问题的一个手段。实际上，这个数据结构，在当初设计的时候，在生产者/消费者消息通信的场景下，也是可以用起来的。而且我意识到 Streams 是很擅长这个场景的，用法也很简洁。Streaming 是一个很好的模式和“思维模型”，在被用来设计系统时，可以获得巨大的成功。但是 Redis Streams 就像大多数 Redis 数据结构一样，是比较通用的结构，可以用来对许多不同的问题进行建模。在本篇博文中，我将聚焦在作为纯粹数据结构的 Streams，完全忽略其阻塞式的操作、消费者群组和所有和消息通讯有关的部分。

作为 CSV 文件加强版的 Streams

从另外一个角度看，这些 CSV 条目的日志也有好的方面：他们没有固定的结构，数据列可以变化，容易生成，而且毕竟其结构也是比较紧凑的。Redis Streams 的设计理念就是取长补短，其结果就是一个和 Redis Sorted sets 非常类似的混合型数据结构：他们看起来像是一个基础数据结构，为了达到这样一个效果，在底层他们有多种表现形式。

图中从新增stream消息到消费stream中的消息，删除stream中的消息，创建分组的stream消息到消费stream的消息以及消费group中的注意情况，需要注意的是stream是不能被删除的在目前版本(5.0.5)中，因为可能会有消费者信息与它关联。具体的用法信息我们可以参考官网
 

Redis5.0重量级特性Stream尝鲜

Redis5.0最近被作者突然放出来了，增加了很多新的特色功能。而Redis5.0最大的新特性就是多出了一个数据结构Stream，它是一个新的强大的支持多播的可持久化的消息队列，作者坦言Redis Stream狠狠地借鉴了Kafka的设计。

Redis Stream的结构如上图所示，它有一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的ID和对应的内容。消息是持久化的，Redis重启后，内容还在。

每个Stream都有唯一的名称，它就是Redis的key，在我们首次使用xadd指令追加消息时自动创建。

每个Stream都可以挂多个消费组，每个消费组会有个游标last_delivered_id在Stream数组之上往前移动，表示当前消费组已经消费到哪条消息了。每个消费组都有一个Stream内唯一的名称，消费组不会自动创建，它需要单独的指令xgroup create进行创建，需要指定从Stream的某个消息ID开始消费，这个ID用来初始化last_delivered_id变量。

每个消费组(Consumer Group)的状态都是独立的，相互不受影响。也就是说同一份Stream内部的消息会被每个消费组都消费到。

同一个消费组(Consumer Group)可以挂接多个消费者(Consumer)，这些消费者之间是竞争关系，任意一个消费者读取了消息都会使游标last_delivered_id往前移动。每个消费者者有一个组内唯一名称。

消费者(Consumer)内部会有个状态变量pending_ids，它记录了当前已经被客户端读取的消息，但是还没有ack。如果客户端没有ack，这个变量里面的消息ID会越来越多，一旦某个消息被ack，它就开始减少。这个pending_ids变量在Redis官方被称之为PEL，也就是Pending Entries List，这是一个很核心的数据结构，它用来确保客户端至少消费了消息一次，而不会在网络传输的中途丢失了没处理。

消息ID

消息ID的形式是timestampInMillis-sequence，例如1527846880572-5，它表示当前的消息在毫米时间戳1527846880572时产生，并且是该毫秒内产生的第5条消息。消息ID可以由服务器自动生成，也可以由客户端自己指定，但是形式必须是整数-整数，而且必须是后面加入的消息的ID要大于前面的消息ID。

消息内容

消息内容就是键值对，形如hash结构的键值对，这没什么特别之处。

增删改查

1. xadd 追加消息

2. xdel 删除消息，这里的删除仅仅是设置了标志位，不影响消息总长度

3. xrange 获取消息列表，会自动过滤已经删除的消息

4. xlen 消息长度

5. del 删除Stream

独立消费

我们可以在不定义消费组的情况下进行Stream消息的独立消费，当Stream没有新消息时，甚至可以阻塞等待。Redis设计了一个单独的消费指令xread，可以将Stream当成普通的消息队列(list)来使用。使用xread时，我们可以完全忽略消费组(Consumer Group)的存在，就好比Stream就是一个普通的列表(list)。

客户端如果想要使用xread进行顺序消费，一定要记住当前消费到哪里了，也就是返回的消息ID。下次继续调用xread时，将上次返回的最后一个消息ID作为参数传递进去，就可以继续消费后续的消息。

block 0表示永远阻塞，直到消息到来，block 1000表示阻塞1s，如果1s内没有任何消息到来，就返回nil

Stream消息太多怎么办

读者很容易想到，要是消息积累太多，Stream的链表岂不是很长，内容会不会爆掉就是个问题了。xdel指令又不会删除消息，它只是给消息做了个标志位。

Redis自然考虑到了这一点，所以它提供了一个定长Stream功能。在xadd的指令提供一个定长长度maxlen，就可以将老的消息干掉，确保最多不超过指定长度

PEL如何避免消息丢失

在客户端消费者读取Stream消息时，Redis服务器将消息回复给客户端的过程中，客户端突然断开了连接，消息就丢失了。但是PEL里已经保存了发出去的消息ID。待客户端重新连上之后，可以再次收到PEL中的消息ID列表。不过此时xreadgroup的起始消息ID不能为参数>，而必须是任意有效的消息ID，一般将参数设为0-0，表示读取所有的PEL消息以及自last_delivered_id之后的新消息。

结论

Stream的消费模型借鉴了kafka的消费分组的概念，它弥补了Redis Pub/Sub不能持久化消息的缺陷。但是它又不同于kafka，kafka的消息可以分partition，而Stream不行。如果非要分parition的话，得在客户端做，提供不同的Stream名称，对消息进行hash取模来选择往哪个Stream里塞。如果读者稍微研究过Redis作者的另一个开源项目Disque的话，这极可能是作者意识到Disque项目的活跃程度不够，所以将Disque的内容移植到了Redis里面。这只是本人的猜测，未必是作者的初衷。如果读者有什么不同的想法，可以在评论区一起参与讨论。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Redis  RDB底层实现

有个周期性函数，叫做serverCron，它会周期调用，大概做这几件事情，见注释。用红色标注的说明会触发bgsave和aof rewrite。

1. redis执行bgsave命令，Redis判断当前存在正在进行执行的子进程，如RDB/AOF子进程，存在bgsave命令直接返回
2. fork出子进程，fork操作中Redis父进程会阻塞
3. fork完成返回　　59117:M 13 Apr 13:44:40.312 * Background saving started by pid 59180
4. 子进程进程对内存数据生成快找文件
5. 子进程告诉父进程处理完成

1. 所有的写入命令追加到aof缓冲区
2. AOF缓冲区根据对应appendfsync配置向硬盘做同步操作
3. 定期对AOF文件进行重写
4. Redis重启时，可以加载AOF文件进行数据恢复

　为什么AOF文件会变小？为了解决AOF文件会越来越大，Redis引入重写机制来缩小文件体积，体积变小因为：

• 多条写入命令可以合并成一条。比如上面的lpush命令了3次，最后合并成1条
• 重写后AOF文件只保留最终数据的写入命令

优缺点

　　AOF持久化方式的优点：

• 做到最多丢失1-2s内的数据（最多丢失2s数据，因为AOF追加阻塞）

　　AOF持久化方式的缺点：

• AOF文件比RDB文件大
• 可能导致追加阻塞

六、copyonwrite

很简单，现在不就是主进程和子进程共享了一块内存空间，怎么做到的彼此更改互不影响吗？

数据修改之后的样子

2、回到原问题
其实就是更改数据的之前进行copy一份更改数据的数据页出来，比如主进程收到了set k 1请求(之前k的值是2)，然后这同时又有子进程在rdb持久化，那么主进程就会把k这个key的数据页拷贝一份，并且主进程中k这个指针指向新拷贝出来的数据页地址上，然后进行更改值为1的操作，这个主进程k元素地址引用的新拷贝出来的地址，而子进程引用的内存数据k还是修改之前的。

   copyonwritefork()出来的子进程共享主进程的物理空间，当主子进程有内存写入操作时，read-only内存页发生中断，将触发的异常的内存页复制一份(其余的页还是共享主进程的)。

0、调用fork()也会阻塞啊
我只能说没毛病，但是这个阻塞真的可以忽略不计。尤其是相对于阻塞主线程的save。

1、会同时存在多个子进程吗？
不会，主进程每次收到bgsave命令需要fork()子进程之前都会判断是否存在子进程了，若存在也会忽略掉这次bgsave请求。若不存在我会fork()出子进程进行工作。
为什么这么搞？
我猜测原因如下:
1.如果支持并行存在多个子进程，那么不仅会拉低服务器性能，还会造成数据问题，比如八点的bgsave在工作，九点又来个bgsave命令。这时候九点的先执行完了，八点的后执行完了，那九点的不白执行了吗？这是我所谓的数据问题。再比如，都没执行完，十点又开一个bgsave，越积越多，服务器性能被拉低。
2.那为什么不阻塞？判断有子进程在工作，就等待，等他执行完我在上场，那一样，越积越多，文件过大，只会造成堆积。
 

2、如果没有copyonwrite这种技术是什么效果？
1.假设是全量复制，那么内存空间直接减半，浪费资源不说，数据量10g，全量复制这10g的时间也够长的。这谁顶得住？2.如果不全量复制，会是怎样？相当于我一边复制，你一边写数据，看着貌似问题不大，其实不然。比如现在Redis里有k1的值是1，k2的值是
2，比如bgsave了，这时候rdb写入了k1的值，在写k2的值之前时，有个客户端请求