namenode是一个主节点，它包含fsimage方面的元数据，还包含编辑日志。编辑日志在namenode的命名空间中包含最近添加/删除的块信息。fsimage文件包含永久存储中整个hadoop系统的元数据。每次需要在fsimage中永久性地进行更改时，我们都需要重新启动namenode，以便可以在namenode中写入编辑日志信息，但这样做需要花费大量时间。
辅助名称节点用于更新fsimage。辅助名称节点将访问编辑日志并永久地在fsimage中进行更改，以便下次名称节点可以更快地启动。
基本上，辅助namenode是namenode的助手，并为namenode执行内务管理功能。

当namenode启动时，它加载fsimage并重放编辑日志以创建最新更新的名称空间。如果编辑日志文件的大小很大，则此过程可能需要很长时间，从而增加启动时间。secondary name节点的任务是定期检查编辑日志和重播，创建更新的fsimage并存储在持久存储中。当name节点启动时，它不需要重放编辑日志来创建更新的fsimage，它使用由secondary name节点创建的fsimage。

即使在hdfs高可用性中，有两个namenode而不是一个namenode和一个secondarynamenode，也没有严格意义上的可用性。它只适用于namenode组件，即使有一个网络分区将客户机与两个namenode分开，集群也实际上不可用。

这些年来情况发生了变化，尤其是Hadoop2.x。现在namenode具有高可用性和故障转移功能。
辅助namenode现在是可选的&备用namenode已用于故障转移过程。
备用namenode将与活动namenode所做的所有文件系统更改保持最新。
hdfs的高可用性有两种选择：nfs和quorum journal manager，但quorum journal manager是首选。
看看apache文档
幻灯片8：http://www.slideshare.net/cloudera/hdfs-futures-world2012-widescreen
当活动节点执行任何名称空间修改时，它会将修改的记录持久地记录到这些jn中的大多数。备用节点从jns读取这些编辑并应用到自己的名称空间。
在发生故障转移的情况下，备用服务器将确保在将自身提升到活动状态之前，它已读取journalnodes中的所有编辑。这样可以确保在发生故障转移之前完全同步命名空间状态。

请看一下有关se问题中的故障转移过程：
hadoop namenode故障转移过程是如何工作的？
关于您对hadoop的cap理论的疑问：
它可以是强一致的
hdfs几乎是高可用的，除非你遇到了一些坏运气（如果一个块的三个副本都坏了，你就得不到数据）
支持数据分区

如果我用简单的方式来解释它，假设name node为men（working/live），secondary name node为atm machine（storage/data storage）
所以所有的功能都是由nn或men执行的，但是如果它发生故障，那么snn将是无用的，它不工作，但是稍后它可以用来恢复数据或日志

名称节点是一个主节点，其中所有元数据定期存储到fsimage和editlog文件中。但是，当名称节点关闭时，辅助节点将联机，但此节点仅对fsimage和editlog文件具有读取权限，而没有对它们的写入权限。所有辅助节点操作都将存储到temp文件夹中。当name node恢复联机时，这个临时文件夹将被复制到name node，并且namenode将更新fsimage和editlog文件。

namenode将hdfs文件系统信息存储在名为fsimage的文件中。对文件系统的更新（添加/删除块）不是更新fsimage文件，而是登录到一个文件中，因此i/o是快速的仅附加流，而不是随机文件写入。重新启动时，namenode读取fsimage，然后应用日志文件中的所有更改，使内存中的文件系统状态更新。这个过程需要时间。
secondarynamenode作业不是name节点的辅助作业，而是定期读取文件系统更改日志并将其应用到fsimage文件中，从而使其更新。这允许namenode下次更快地启动。
不幸的是，secondarynamenode服务不是备用的secondarynamenode，尽管它的名称是。具体来说，它不为namenode提供ha。这在这里有很好的说明。
请参阅了解hdfs中的namenode启动操作。
注意，最近的发行版（当前的hadoop2.6）引入了使用nfs（共享存储）的namenode高可用性和/或使用quorum日志管理器的namenode高可用性。