写点什么

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

用户头像
escray
关注
发布于: 2021 年 03 月 18 日
《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 层自带的。


发布于: 2021 年 03 月 18 日阅读数: 11
用户头像

escray

关注

Let's Go 2017.11.19 加入

在学 Elasticsearch 的项目经理

评论

发布
暂无评论
《Redis 核心技术与实战》学习笔记 03