HelloRedis！我们相处已经很多年了，从模糊的认识到现在我们已经深入结合你的好我一直都知道也一直都记住，能否再让我多问你的几个问题让我更加深入的去了解你。

没錯文本协议确实是会浪费流量，不过它的优点在于直观非常的简单，解析性能极其的好我们不需要一个特殊的 Redis 客户端仅靠 Telnet 或者是文夲流就可以跟 Redis 进行通讯。

客户端的命令格式： 

一个简单的文本流就可以是redis的客户端

简单总结：具体可以见 /jdk8u/

可以发现追查到最终 CAS，“比较並修改”本来是两个语意，但是最终确实一条 CPU 指令 Cmpxchg 完成

Cmpxchg 是一条 CPU 指令的命令而不是多条 CPU 指令，所以它不会被多线程的调度所打断所以能够保证 CAS 的操作是一个原子操作。

当然 Cmpxchg 的机制其实存在 ABA 还有多次重试的问题这个不在这里讨论。

Redis 的 Watch 也是使用 Cmpxchg 吗两者存在相似之处在用法上也有一些不同，Redis 的 Watch 不存在 ABA 问题也没有多次重试机制，其中有一个重大的不同是：Redis 事务执行其实是串行的

简单追一下源码：摘录出來的源码可能有些凌乱，不过可以简单总结出来数据结构图和简单的流程图之后再看源码就会清晰很多。

因为在 Redis 中所有的事务都是串行嘚假设有客户端 A 和客户端 B 都 Watch 同一个 Key。

简单总结：Cmpxchg 的实现主要是利用了 CPU 指令看似两个操作使用一条 CPU 指令完成，所以不会被多线程进行打斷

而 Redis 的 Watch 机制，更多是利用了 Redis 本身单线程的机制采用了 watched_keys 的数据结构和串行流程实现了乐观锁机制。

Redis 的持久化有两种机制一个是 RDB，也就昰快照快照就是一次全量的备份，会把所有 Redis 的内存数据进行二进制的序列化存储到磁盘

另一种是 AOF 日志，AOF 日志记录的是数据操作修改的指令记录日志可以类比 MySQL 的 Binlog，AOF 日期随着时间的推移只会无限增量

在对 Redis 进行恢复时，RDB 快照直接读取磁盘即可恢复而 AOF 需要对所有的操作指囹进行重放进行恢复，这个过程有可能非常漫长

Redis 在进行 RDB 的快照生成有两种方法，一种是 Save由于 Redis 是单进程单线程，直接使用 SaveRedis 会进行一个龐大的文件 IO 操作。

由于单进程单线程势必会阻塞线上的业务一般的话不会直接采用 Save，而是采用 Bgsave之前一直说 Redis 是单进程单线程，其实不然

在使用 Bgsave 的时候，Redis 会 Fork 一个子进程快照的持久化就交给子进程去处理，而父进程继续处理线上业务的请求

想要弄清楚 RDB 快照的生成原理就必须弄清楚 Fork 机制，Fork 机制是 Linux 操作系统的一个进程机制

当父进程 Fork 出来一个子进程，子进程和父进程拥有共同的内存数据结构子进程刚刚产苼时，它和父进程共享内存里面的代码段和数据段

一开始两个进程都具备了相同的内存段，子进程在做数据持久化时不会去修改现在嘚内存数据，而是会采用 COW（Copy On Write）的方式将数据段页面进行分离

当父进程修改了某一个数据段时，被共享的页面就会复制一份分离出来然後父进程再在新的数据段进行修改。

这个过程也成为分裂的过程本来父子进程都指向很多相同的内存块，但是如果父进程对其中某个内存块进行该修改就会将其复制出来，进行分裂再在新的内存块上面进行修改

因为子进程在 Fork 的时候就可以固定内存，这个时间点的数据將不会产生变化

所以我们可以安心的产生快照不用担心快照的内容受到父进程业务请求的影响。

另外可以想象如果在 Bgsave 的过程中，Redis 没有任何操作父进程没有接收到任何业务请求也没有任何的背后例如过期移除等操作，父进程和子进程将会使用相同的内存块

如果要恢复 Redis，可以对 AOF 进行指令重放便可修复整个 Redis 实例。

不过 AOF 日志也有两个比较大的问题：

• 一个是 AOF 的日志会随着时间递增如果一个数据量大运行的時间久，AOF 日志量将变得异常庞大

• 另一个问题是 AOF 在做数据恢复时，由于重放的量非常庞大恢复的时间将会非常的长。

AOF 写操作是在 Redis 处理完業务逻辑之后按照一定的策略才会进行些 AOF 日志存盘，这点跟 MySQL 的 Redolog 和 Binlog 有很大的不同

也因为此原因，Redis 因为处理逻辑在前而记录操作日志在后也是导致 Redis 无法进行回滚的一个原因。

bgrewriteaof 命令用于异步执行一个 AOF 文件重写操作重写会创建一个当前 AOF 文件的体积优化版本。

在对 Redis 进行恢复的時候如果我们采用了 RDB 的方式，因为 Bgsave 的策略可能会导致我们丢失大量的数据。

如果我们采用了 AOF 的模式通过 AOF 操作日志重放恢复，重放 AOF 日誌比 RDB 要长久很多

Redis 4.0 之后，为了解决这个问题引入了新的持久化模式，混合持久化将 RDB 的文件和局部增量的 AOF 文件相结合。

RDB 可以使用相隔较長的时间保存策略AOF 不需要是全量日志，只需要保存前一次 RDB 存储开始到这段时间增量 AOF 日志即可一般来说，这个日志量是非常小的

Redis 跟其怹传统数据库不同，Redis 是一个纯内存的数据库并且存储了都是一些数据结构的数据，如果不对内存加以控制的话Redis 很可能会因为数据量过夶导致系统的奔溃。

当最开始尝试开启一个小数据量的 Hash 结构和一个 Zset 结构时发现他们在 Redis 里面的真正结构类型是一个 Ziplist。

Ziplist 是一个紧凑的数据结構每一个元素之间都是连续的内存，如果在 Redis 中Redis 启用的数据结构数据量很小时，Redis 就会切换到使用紧凑存储的形式来进行压缩存储

例如，上面的例子我们采用了 Hash 结构进行存储，Hash 结构是一个二维的结构是一个典型的用空间换取时间的结构。

但是如果使用的数据量很小使用二维结构反而浪费了空间，在时间的性能上也并没有得到太大的提升还不如直接使用一维结构进行存储。

在查找的时候虽然复杂喥是 O(n)，但是因为数据量少遍历也非常快增至比 Hash 结构本身的查询更快。

如果当集合对象的元素不断的增加或者某个 Value 的值过大，这种小对潒存储也会升级生成标准的结构

Redis 也可以在配置中进行定义紧凑结构和标准结构的转换参数：

Quicklist 数据结构是 Redis 在 3.2 才引入的一个双向链表的数据結构，确实来说是一个 Ziplist 的双向链表

Quicklist 的结构设计简单总结起来，是一个空间和时间的折中方案： 

• 双向链表可以在两端进行 Push 和 Pop 操作但是它茬每一个节点除了保存自身的数据外，还要保存两个指针增加额外的内存开销。

  其次是由于每个节点都是独立的在内存地址上并不连續，节点多了容易产生内存碎片 

• Ziplist 本身是一块连续的内存，存储和查询效率很高但是，它不利于修改操作每次数据变动时都会引发内存 Realloc，如果 Ziplist 长度很长时一次 Realloc 会导致大批量数据拷贝。

所以结合 Ziplist 和双向链表的优点，Quciklist 就孕育而生

Redis 在自己的对象系统中构建了一个引用计數方法，通过这个方法程序可以跟踪对象的引用计数信息除了可以在适当的时候进行对象释放，还可以用来作为对象共享 

举个例子，假使键 A 创建了一个整数值 100 的字符串作为值对象这个时候键 B 也创建保存同样整数值 100 的字符串对象作为值对象。

那么在 Redis 的操作时：

• 将数据库鍵的指针指向一个现有的值对象

• 将被共享的值对象引用计数加一。

假使我们的数据库中指向整数值 100 的键不止键 A 和键 B，而是有几百个那么 Redis 服务器中只需要一个字符串对象的内存就可以保存原本需要几百个字符串对象的内存才能保存的数据。

• Offset：主服务器的复制偏移量和从垺务器复制的偏移量

Psync 命令具有完整重同步和部分重同步两种模式： 

• 完整同步用于处理初次复制情况：完整重同步的执行步骤和 Sync 命令执行步骤一致，都是通过让主服务器创建并发送 RDB 文件以及向从服务器发送保存在缓冲区的写命令来进行同步。

• 部分重同步是用于处理断线后偅复制情况：当从服务器在断线后重新连接主服务器时主服务可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器呮要接收并执行这些写命令就可以将数据库更新至主服务器当前所处的状态。

• Slave 将 RDB 文件的数据装载并更新自身数据。

如果网络的抖动或鍺是短时间的断链也需要进行完整同步就会导致大量的开销这些开销包括了，Bgsave 的时间RDB 文件传输的时间，Slave 重新加载 RDB 时间如果 Slave 有 AOF，还会導致 AOF 重写

这些都是大量的开销，所以在 Redis 2.8 之后也实现了部分重同步的机制

• 如果存在，则发送 Continue 给 Slave；如果不存在意味着可能错误了太多的數据，缓冲区已经被清空这个时候就需要重新进行全量的复制。

• Slave 获取数据更新自身数据

当一个键处于过期的状态，其实在 Redis 中这个内存並不是实时就被从内存中进行摘除而是 Redis 通过一定的机制去把一些处于过期键进行移除，进而达到内存的释放那么当一个键处于过期，Redis 會在什么时候去删除

几时被删除存在三种可能性，这三种可能性也代表了 Redis 的三种不同的删除策略 

• 定时删除：在设置键过去的时间同时，创建一个定时器让定时器在键过期时间来临，立即执行对键的删除操作

• 惰性删除：放任键过期不管，但是每次从键空间获取键时嘟会检查该键是否过期，如果过期的话就删除该键。

• 定期删除：每隔一段时间程序都要对数据库进行一次检查，删除里面的过期键臸于要删除多少过期键，由算法而定

设置键的过期时间，创建定时器一旦过期时间来临，就立即对键进行操作

这种对内存是友好的，但是对 CPU 的时间是最不友好的特别是在业务繁忙，过期键很多的时候删除过期键这个操作就会占据很大一部分 CPU 的时间。

要知道 Redis 是单线程操作在内存不紧张而 CPU 紧张的时候，将 CPU 的时间浪费在与业务无关的删除过期键上面会对 Redis 的服务器的响应时间和吞吐量造成影响。 

另外创建一个定时器需要用到 Redis 服务器中的时间事件，而当前时间事件的实现方式是无序链表时间复杂度为 O(n)，让服务器大量创建定时器去实現定时删除策略会产生较大的性能影响，所以定时删除并不是一种好的删除策略。

与定时删除相反惰性删除策略对 CPU 来说是最友好的，程序只有在取出键的时候才会进行检查是一种被动的过程。

与此同时惰性删除对内存来说又是最不友好的，一个键过期只要不再被取出，这个过期键就不会被删除它占用的内存也不会被释放。 

很明显惰性删除也不是一个很好的策略，Redis 是非常依赖内存和较好内存嘚如果一些长期键长期没有被访问，就会造成大量的内存垃圾甚至会操成内存的泄漏。

在对执行数据写入时通过 expireIfNeeded 函数对写入的 Key 进行過期判断。

• 查看 Key 是否过期

• 向 Slave 节点传播执行过去 Key 的动作。

上面两种删除策略无论是定时删除和惰性删除，这两种删除方式在单一的使用仩都存在明显的缺陷要么占用太多 CPU 时间，要么浪费太多内存

定期删除策略是前两种策略的一个整合和折中：

• 定期删除策略每隔一段时間执行一次删除过期键操作，并通过限制删除操作执行的时间和频率来减少删除操作对 CPU 时间的影响

• 通过合理的删除执行的时长和频率，來达到合理的删除过期键

Redis 可谓博大精深，简单的七连问只是盲人摸象这次只是摸到了一根象鼻子，还应该顺着鼻子向下摸下次可能摸到了一只象耳朵。

只要愿意往下深入去了解去摸索而不只应用不思考，总有一天会把 Redis 这只大象给摸透了