@shiziwen
啊，对不起 我也搞混了一点

首先要说明的一点是，重写时并不影响aof持久化正常执行也不影响现有的aof缓存区跟aof文件。

如果我们简化aof持久化的正常过程是新命令->缓存区->aof文件的顺序

那么在执行重写时，而又有新命令的话
就只是在新命令->缓存区
这一过程的之间把命令复制一份到重写缓存区中
事实上每次缓存区写入文件时都会检查是否在重写以判断需不需要写多一份到重写缓存区。
所以我早上说的缓存区冲洗到aof文件之后再写到重写缓存区是错的

但是两个缓存区依然是很难保持一致的
虽然两个缓存区在新命令->缓存区这一步之后看上去是一致的(？)，但是这是暂时的
因为aof缓存区在写到aof文件中之后，会被清空或者直接指向一片新的内存空间，以便确保有足够的空间继续接受新的命令。显然，这之后两个缓存区就不再一致了。

aof重写缓存区会一直保持从重写开始到结束所有写命令
而aof缓存区会不断 写入-冲洗到aof文件-清除-写入 这一过程，因而只会保存一部分的命令
他们并不一致

假如只保留一个缓存区，就可能有以下麻烦
没有办法很好分离两个功能互不影响
标识重写过程中新增命令变得麻烦
内存利用不够充分

最后继续推荐《Redis 设计与实现 第二版》这本书，以及作者对源码的中文注释版

@shiziwen
不对，并不是在重写完成后，将AOF重写缓冲区的内容，同步到AOF缓冲区中。
实际上的过程应该是
开始aof重写
主程继续处理命令请求。
将写命令追加到现有的 AOF 文件中。
将写命令追加到 AOF 重写缓存中
（这时aof缓存的内容由于已经写到aof文件和重写缓存中,不再需要保留，已经被释放了）。
重写完成后将缓存写入到重写文件尾
将文件改名覆盖原来的aof文件

重写缓存主要是为了记录重写过程中的不同（主要是新增写/删等命令），并不会和缓存区保持一致，要保持一致的重写前的aof文件，aof重写文件还有数据库本身

要了解redis设计与实现除了读官方源码以外，我无脑推荐《Redis 设计与实现 第二版》这本书，以及作者对源码的中文注释（对新手更友好）

草鸡棒

2333唱起来

说起国人开源项目我就想起一件事
A站跟土豆还有几家公司用dfm用的好好的，突然一下作者入职B站了就变成了
他们技不如人还得用用竞争对手公司的开源项目╮(╯▽╰)╭简直炫酷，换我该心塞好一阵子
嘛，虽然认真计较起来并没有什么不妥，我只是觉得开源项目这样一搞变得很有专利竞争的感觉

虽然提到广州但是好像都在说苏州？广州方面如何？因为我人在那边，作为学生也不太可能转移阵地过去

@morethansean
那么我就不是知道了，难道你其实不用中文社区？反正我跟我的几个朋友都表示g+热门推送根本跟自己的关注无关，太烦了。

@morethansean
只要打开了热门信息推送，就跟你关注什么没太大关系了，那些你不关住的一样会推
一股脑的推都是轮子和愤青简直不忍直视

@Andiry
啊，谢谢指教，参考了你的代码
终于知道哪里出了问题，才发现自己对边际条件的检查还不够

@cnbeining
⊂彡☆))∀`)专心cf看什么视频啦
其实我觉得如果整合不足的话，小学生会嫌麻烦连看都不看
@schezuk
然后对于弹幕质量，如何避免简单举报机制被恶意利用是否也会相应的成为一个问题？
例如劣质弹幕被强行推高，而好的弹幕被恶意举报，或者被用于刻意推送特定信息

55