一.NameNode上存储着最重要的文件（fsimage和edits文件），但是主从结构的，都存在单点故障问题。所以，需要配置HA高可用（Hight Availability）也不知道在哪看到有人写High Available...（笑声）
那么就需要控制其（产生和变化）一致性
fsimage
edits
fsimage 和 editslog 在格式化的时候产生这两个文件一致
fsimage在一台namenode上格式化之后同步发给其他的namenode就ok了
editslog文件，当对hdfs有操作的时候，edits文件就会变化。
怎么保证edits文件的一致性呢？
高并发架构中 session一致性，是通过redis和memcached
edits文件一致性是通过journalnode
二.HDFS
1. Namenode 内存受限 Federation（联邦）
2. 单点故障问题 HA
2.1fsimage 在一台电脑上格式化 hdfs namenode -format 后启动格式化过的namenode，然后在没有进行格式化的namenode上进行 -bootstrap standby 同步fsimage
fsimage变化，当fsimage和edits文件合并，就会变化。交由处于standby状态的namenode合并。
2.2edits -> 有操作，就会使edits改变，交由journalnode集群来管理 >= 3 （n-1）/2 的奇数个数。
NFS 企业不会用。还是存在单点故障问题。
2.3 Zookeeper >= 3 （n-1）/2
(1) zk 对 namenode进行状态监控，通过zk中的HealtMonitor
(2) zk 做通过zk中的ActiveStandbyEletor选举 namenode 的一个工作 交给zkfc
HA 搭建：
1.修改配置文件
2.edits文件交由journal集群管理，则先启动journal集群。（手动）
3.格式化NN （随便找一台就可以），随后启动
4.在另外一台未执行格式化的namenode上同步（hdfs namenode -bootstrapStandby）。
5.配置zookeeper 配置环境变量 修改conf/zoo.cfg文件
6.启动zk zkService.sh start|status|stop (leader|follower)如果启动失败，则需要看你启动命令的当前文件夹下有一个 zk.out 文件 查看错误信息
7.启动dfs 集群 start-dfs.sh
MapReduce（分布式计算，移动计算而不是移动数据）：
四个阶段：
1. split 切割成大文件
2. map 手写代码实现
map task (spilt 切割了多少块，就有多少个task)
map一行一行的读取 ： key value形式
3. shuffle 洗牌 （分区partition，排序sort，分组group，还可以有combiner）
分区 partition （取模，key的hash值 模 reduce的个数）
sort 字典排序（）按照ascii码排序
combiner但需要自己实现,其做了一小部分的reduce操作，但是它不能取代reduce操作，它是为了减少网络传输，减少reduce的操作
4. reduce 手写代码实现
二次排序，根据字典进行排序
reduce拿到的数据，特点，一组key相同的数据，组内的数据都是排好序的。
通过迭代器的方式遍历组内的数据。
整合MapReduce组合到hadoop中。
1.修改配置文件
start-all.sh == start-dfs.sh + start-yarn.sh
二、MapReduce 有两种运行方式
1.本地测试环境
本地使用Java多线程来模拟运行。
2.服务器环境（把文件提交服务端运行）
hadoop jar xxx.jar com.ibm.xxx class文件的全路径