关于oracle的缓冲区机制与HDFS中的edit logs的某些关联性的思考

可能大家会问，oracle和HDFS属于不同场景的存储系统，它们之间为什么会有联系呢？确实，从技术本身来看，他们确实无关联，但利用“整体学习”的思想，跳出技术本身，可以发现Oracle的缓冲区和HDFS的edit logs都是为了解决频繁IO而出现的，可以解决因频繁读写磁盘而导致性能低的问题。如下图所示：

一、Oracle的缓冲区机制

Oracle的缓冲区主要有两种：数据库缓冲区缓存（data buffer cache，后面简称DB chche）和日志缓冲区（redo log）（对oracle实例内存结构感兴趣的同学可自行百度，此处不再过多介绍）。

1.数据库缓冲区缓存（DB Cache）

DB Cache是执行SQL的工作区域，用户会话所有操作数据都是在此缓存中进行，而不是直接操作磁盘。举例来说，当执行select操作时，会先查找DB Cache，如果找到，则直接返回，如果未找到，会再从磁盘加载数据到DB Cache中来，然后再返回。再举个例子，当执行update操作时，其实也只是更新了DB Cache中的数据。如果DB Cache中数据和磁盘中数据不一致，则称此数据为脏数据。

 那么DB Cache的脏数据往磁盘中写入的机制是怎样的呢？Oracle中为此专门有一个数据库写入器的后台进程DBWn，会把DB Cache中的数据写入到磁盘中，当出现以下情况之一时，DBWn会执行写入磁盘操作：

1）没有任何可用DB Cache；

2）脏数据过多； 

3）到达3秒的超时时间； 

4）遇到checkpoint； 

可以看到，DBWn这样写入方式是极懒的，目的就是为了减少IO。

2.日志缓冲区

日志缓冲区是一块小的内存区域，用于存储重做日志文件中的变更向量。当数据库出现故障，导致大量脏数据未来得及写入磁盘时，会根据重做日志文件进行恢复（注意：重做redo和撤销undo是有区别的，不要混淆）。与DBWn一样，重做日志缓冲区也有专门的后台进程LGWR，进行磁盘的写入操作，写入的时机有以下几种情况：

1）commit操作（注意此commit，执行的是重做日志的写入磁盘操作，而不是DB Cache的写入磁盘操作）； 

2）日志缓冲区已用超过1/3； 

3）DBWn要写入脏数据（可以想想为什么要这样？原因就在于DBWn可能会将未提交的事务数据写入到磁盘，为了保证这些已写入磁盘的数据可以进行回滚，所以必须也要把对应的重做日志也写入到磁盘中去，其实就是为了事务回滚用的）； 

综上，这两类缓冲区都是为了最大限度的减少IO而出现的机制。

二、HDFS的edit logs

 熟悉HDFS namenode启动过程的同学们应该知道，在HDFS namenode启动时，会把fsimage和edit logs加载到namenode的内存中，当namenode需要重启时，会先把内存中的fsimage与edit logs合并写入磁盘后，再重复执行上面的操作（此处edit logs可以认为是namenode的缓冲区，类似于oracle的缓冲区，只是一般不会轻易写磁盘）。因此就会面临如下的问题：

1）当edit logs文件很大时，则namenode的重启时间会过长； 

2）当namenode意外挂掉时，则eidt logs会丢失很多改动；

此时，Secondary namenode就出现了，可以通过定时查询edit logs，然后将edit logs更新到fsimage，再由secondary namenode将更新后的fsimage写入到namenode磁盘，以便下次重启时使用。当然随着Hadoop 2.0以后HA的出现，secondary namenode也被其它HA方案替代了，后面有机会再深入介绍。

综上，oracle的缓冲区与hdfs中的edit logs类似，都是为了防止IO影响性能而出现的，只是写入磁盘的机制不同，但思想可以认为是一致的。

原文出处