hdfs的元数据辅助关联和redis数据持久化汇总对比

hdfs的元数据辅助关联

在Hadoop的集群当中，NameNode的所有元数据信息都保存在了FsImage（镜像文件）与Eidts（日志文件）文件当中，这两个文件就记录了所有的数据的元数据信息，元数据信息的保存目录配置在hdfs-site.xml中。

edits:
edits存放了客户端最近一段时间的操作日志
客户端对HDFS进行写文件时会首先被记录在edits文件当中
edits修改时，元数据也会更新

fsimage
NameNode中关于元数据的镜像，一般称为检查点，fsimage存放了一份比较完成的元数据信息，因为fsimage 是NameNode 的完整的镜像，如果每次都加载到内存，非常消耗内存和CPU，所有一般开始对NameNode的操作都存放在edits中。
fsimage内容包含了NameNode关理下的所有DataNode 文件及文件block及block所在的DataNode的元数据信息。随着edits内容增大，就需要在一定的时间点和fsimage合并。

SecondaryNameNode定期合并fsimage 和edits，把edits控制在一个范围内
在core-site.xml中配置多久同步一次HDFS镜像，一次记录多大

1、SecondaryNameNode通知NameNode切换editlog
2、SecondaryNameNode从NameNode中获得fsimage和editlog
3、SecondaryNameNode将fsimage载入内存，然后开始合并editlog，合并之后新城新的fsimage
4、SecondaryNameNode将新的fsimage发回给NameNode
5、NameNode用心的fsimage替换旧的fsimage

Redis数据持久化

Redis 将内存存储和持久化存储相结合，即可提供数据访问的高效性，又可以保证数据存储的安全性，主要是在文件中配置实现

Rdis数据持久化机制介绍
1、RDB（快照）持久化：
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
2、AOF（日志append only file）持久化：
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保障启动之后数据库中的数据是完整的。
3、同时应用AOF和RDB。

Redis会将数据集的快照dump到dump.rdb文件中，dump.rdb文件的位置设置在redis.conf文件中的dir./…

RDB快照方式配置在redis.conf文件中
save 900 1
#在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10
#在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10
#在60秒(1分钟)之后，如果至少有10个key发生变化，则dump内存快照。

AOF日志文件方式：在redis.conf文件中
AOF日志持久化机制的开启：将APPendonly no 改成 appendonly yes

AOF同步方式的配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
#appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
#appendfsync no #从不同步。高效但是数据不会被持久化。

RDB和AOF对比：
RDB优势：1、数据备份和恢复方便，一个数据库只有一个持久化文件
2、性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
3、相比AOF机制，数据集大，RDB的启动效率会更高。
劣势：
1、系统如果突然宕机，还未写入磁盘的数据都将丢失
2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF的优势：
1、该机制可以带来更高的数据安全性，即数据持久性。
2、对日志文件的写入操作采用的是append模式，因此在写入过程中及时出现宕机信息也不会破话日志中已经存在的内容。
3、如果日志过大，redis可以自动启动rewrite机制“瘦身”
4、AOF日志格式清晰，很容易用AOF日志文件完成数据的重建。

AOF的劣势：
1、对应相同数量的数据集而言，AOF文件通常要大于RDB文件
2、根据通报策略的不同，AOF在运行效率上往往会慢于RDB

一般都是2种机制同时存在