EditsLog同步机制优化：Pull模型与BackupNode实现策略.pdfVIP

BackupNode同步editslog的代码基本上写完了，pull模型，他觉得自己可以的时候就去pull

editslog，而不要去让NameNode主动push，editslog就存在于N多个磁盘文件里，要么就

是存在于内存缓冲里

push模型去写，更加的复杂，更加的，对NameNode这一块的影响更大。pull模型下，

在NameNode端，仅仅是在内存中会缓存比如说一小块数据，比如就内存缓冲里的数据会

缓存起来，或者是某个磁盘文件里的数据，会缓冲起来

NameNode而言，内存缓存占用其实是不多的，而且是的，每次就缓存一小段数据，让

人家来拉取就可以了，如果拉完了这一小段数据，再次缓存下一段数据就可以了，比如说下

一个磁盘文件的数据

push模型，代码一样很的；如果BackupNode万一宕机了，此时你要自动感知到，还要

进行各种内存级别的缓冲啊什么的，内存缓冲不下了，此时还要落地磁盘；还要尝试自动感

知到BackupNode什么时候恢复了；还要可能从磁盘和内存里去加载数据发送给BackupNode

继续去同步

NameNode这一块可能会积压很多editslog在内存里，弄不好还有内存溢出的风险

如果说用push模型，一般来说应该怎么做会比较健壮一些，BackupNode要部署3个或者