《Redis 核心技术与实战》学习笔记 03

学习极客时间《Redis 核心技术与实战》专栏过程中的一些学习笔记，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自网络

04 | AOF 日志：宕机了，Redis 如何避免数据丢失？

在服务器宕机的情况下，Redis 自己实现持久化与通过后端数据库恢复数据哪一个性能更好？毫无疑问是 Redis，那么问题来了，Redis 是如何做到的？

AOF 里面记录了 Redis 的每一条命令，其实在 MySQL 里面也有 binlog，如果设置成 statement，也能记录每一条 SQL。

Redis 使用写后日志，减少了额外的命令语法检查开销，可以避免出现记录错误日志。另外一个好处是，不会阻塞当前的写操作。

AOF 的重写其实适合应用场景密切相关的，因为 Redis 主要应用于缓存场景，所以不太在意某一个 key 的操作历史，只在乎这个 key 的当前值。

AOF 重写机制虽然巧妙，但是普通数据库估计没法使用。

AOF 重写由后台子进程 bgrewriteaof 来完成，采用“一个拷贝，两处日志”的方式。

对于课后思考题，第一题，在 bgrewriteaof 子进程进行重写的过程，我觉的在拷贝的时候有可能会发生阻塞，如果文件比较大，那么拷贝可能会比较慢（在内存里，几乎可以忽略），另一方面，就是有可能把内存占满，StackOverflow ?

第二个题目，AOF 重写的重写日志应该是在发生重新的时候（假设此时的时间为 t1）开始记录的，比原有的 AOF 重写日志要小很多，这样在完成了 t1 之前的日志重写之后，原有的 AOF 本身的日志就可以删除了。AOF 重写的重写日志相对来说要小一些，读写性能更好，最终删除的时候也更快。

看了 @Kaito 的答案，只能膜拜。

留言里面还提到 AOF 是 Append Only File 的缩写，也算是解了我的一个疑惑。

05 | 内存快照：宕机后，Redis 如何实现快速恢复？

虽然通常说 Redis 是单线程的，但是学习到这里就已经发现，Redis 在缓存读写之外，其实也用到了很多子线程，比如之前的 bgrewriteaof 和这里的 bgsave。

在处理 RDB 快照时候采用 COW, Copy-On-Write 写时复制 的技术，感觉思路和在前面处理 AOF 的时候有些类似。

内存快照和 AOF 混用这个想法实在是太好了，取了两种方法的优点，又在一定程度上避免了缺点。

对我来说，目前的工作中并没有使用 Redis，但是 Redis 的这些设计思路，算得上是“他山之石”。

对于课后题，试着分析一下

因为 4GB 内存，而 Redis 的数据量大约 2GB，那么我估计几乎所有的数据都会放在内存中，修改请求占 80% 的情况下，用 RDB 做持久化，即使是增量模式，那么每次的 RDB 估计也会比较大，500GB 磁盘大概能写 200 个 RDB，一方面有存储压力，另一方面快照的时候对于 Redis 应该也会有阻塞（不知道 2 核 在这里是否用的上）。

如果采用 AOF 和 RDB 混合模式，应该是比较好的选择；或者干脆就只用 AOF 的 everysec 模式，取一个平衡。

再次膜拜 @kaito 大神

受留言的启发，去看了一下隔壁的《02 | 日志系统：一条 SQL 更新语句是如何执行的？》

MySQL 使用 WAL, Write-Ahead Logging 技术，“先写日志 redo log，再写磁盘”，要注意的一点是，这里的日志（redo log）是在磁盘上的。

MySQL 还有一个归档日志（binlog），与 Redis 的 AOF 有点类似，首先二者都是追加写，其次 binlog 也可以记录原始的 sql 语句。

MySQL 中 redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

最后补充，redo log 是 InnoDB 引擎特有的，而 binlog 是 MySQL Server 层自带的。