CAP原则

强一致性会破坏可用性

Consistency：一致性

是指在同一时刻,分布式系统中NameNode主备节点里元数据始终是相同值。

Availability：可用性

不会因为NameNode备节点网络延迟导致主节点等待卡顿。
或指NameNode中的某一个节点故障宕机后，集群还能响应客户端请求，并且数据不丢失。

Partition  tolerance：分区容忍性

能不能尽量保证一致性的情况下，将数据拆分开来，分散存储。
例如：
   1.DataNode节点。
   2.系统中一部分节点无法和其他节点进行通信情况下，系统也能够正常运行。

CA

单机情况，很容易满足

CP

两台服务器，分别存储一部分数据。如果一台服务器宕机，一部分数据丢失。

AP

分区容忍性结合一致性会使，数据库数据分散存储，并且要求各个节点数据始终相同。这样就会造成较高的网络延迟等卡顿情况，降低可用性。

Paxos 算法

1. Paxos算法是莱斯利·兰伯特于1990年提出的一种基于消息传递的一致性算法。
2. 这个算法被认为是类似算法中最有效的。
3. 该算法覆盖全部场景的一致性。
4. 每种技术会根据自己技术的特征选择简化算法实现。
5. 传递：NN之间通过一个可靠的传输技术，最终数据能同步就可以
6. 我们一般假设网络等因素是稳定的
7. 类似一种带存储能力的消息队列

简化思路：

1. 分布式节点数量是否明确

2. 节点权重是否明确

例如按照主机名计算权重（条件约束清晰）。

3. 强一致性破坏可用性

4. 过半通过可以中和一致性和可用性

只要集群中过半节点都通过既是真通过，会使集群更可靠。

每一次读取写入数据，都会检查是否过半节点都成功。

否则会导致数据读取写入不一致问题：例如写入到A节点还没来得及复制到B节点，这时备NodeName就去B节点读取数据。

5. 最简单的自我协调实现方式：主从

6. 主的选举：明确节点数量和权重

在条件清晰时可以快速选出主节点。

7. 主从的职能：

主：增删改查
从：查询，如想增删改要将请求传递给主
主与从：过半数同步数据

分布式集群

主从集群

结构相对简单，主与从协作

单点主机

#优点
数据一致好掌握

#缺点
单点故障，集群整体不可用
压力过大，内存受限

HDFS针对不同场景解决方案

单点故障时

#HADOOP 2.x 只支持HA的一主一备
#官方建议：一主三备

高可用方案：HA（High Available）
多个NN，主备切换

压力过大，内存受限时

联帮机制： Federation（元数据分片）
多个NN，分别管理不同的元数据

详细解决方案——单点故障时

JournalNode 元数据共享节点

集群启动时，可以同时启动2个NameNode。

这些NameNode只有一个是active的，另一个属于standby状态。

active状态意味着提供服务也称主节点，standby状态意味着处于休眠状态也称副节点，只进行数据同步，时刻准备着提供服务。

主备NameNode为了数据同步，会通过一组称作JournalNode的独立进程进行相互通信。

当active状态的NameNode有任何添加修改时，会告知一半以上的JournalNodes进程。

standby状态的NameNode可以读取JNs中的数据变更信息，并且一直监控editLog的变化，把变化应用于自己的节点内。

standby可以确保在集群出错时，主节点状态已经被完全同步了。

节点数应大于3台，并且为奇数个。
副节点读取JournalNode日志恢复数据

NameNode如何产生元数据

client客户端交互产生的数据
例如:mkdir /a

DataNode提交的block数据

ZooKeeper(ZK)

可以为我们提供配置管理，名字服务，提供分布式应用程序协调以及集群管理等服务
只同步状态，不同步数据

#配置管理
例如在集群中使用数据库连接等配置文件，多服务器都需要这个配置，这时就需要使用ZK服务来保证这些配置文件的一致性。

#名字服务
同步每台机器里都备的hosts文件

#分布式锁
利用Zookeeper来协调多个分布式进程之间的活动，一台服务器宕机，另一台要顶上去，利用leader选举制。

#集群管理
集群中时常有新的节点加入进来，也有老的节点退出集群，要保证这些节点服务一致性。

ZKFailoverController(ZKFC)

监控某一NameNode节点状态，因为要可靠的监控服务，通常和NameNode在同一主机下。

ZK — ZKFC — NameNode同步流程

ZKFC抢锁竞争

ZK有一个目录树，两个ZKFC向这个节点下创建锁，谁创建成功谁就是NameNode主节点，其他的是NameNode副节点。

创建锁时会自动添加两者ZKFC的回调函数（call back），

主节点宕机

随着时间推移，如果主节点宕机了，同主机的ZKFC进程会把锁删掉，而后触发删除事件，调用回调方法，通知ZKFC进入新一轮抢锁环节。

副ZKFC节点抢锁成功后，他首先会去对方主节点确认是否真的宕机。

ZKFC异常退出

如果ZKFC异常退出了，TCP通信链接会和ZK断开，自动将锁删除。

而后副ZKFC节点抢锁成功后，同样会向主节点确认是否真的宕机，发现主ZKFC进程退出了，会将主节点降级为副节点，自身副节点升级为主节点。

极端情况

主ZKFC节点无法和ZK通信，并且副ZKFC节点也无法连通主节点，然而副节点可以和其他所有节点例如NN，DN成功连接。

这样就无法判断是主节点宕机，还是自己网络延迟，就会无限的报错。

不过发生几率极低。

极端情况解决方案

两台ZKFC利用串口相互连接对方电源，如果副节点抢锁成功后，就将对方主节点电源断电，这样副节点就可以放心升级为主节点。

详细解决方案——压力过大，内存受限时

思路

解决方案

NNa和NNb的元数据是相互独立的，分别存储相同的文件也不会产生冲突。

但是他们共享一个DataNode集群，元数据隔离，DN统一负责存储。

产生的问题

可是问题也随之而来，数据共享度差。

相互之间无法互通数据。

增加抽象层

可以在之上搭建一个"虚拟文件系统代理层"，挂载三个NN的目录，通过三个节点代理分别访问到他们三个的元数据。

客户端直接连接抽象的代理层，使用起来根本感受不到是三个节点。

虚拟文件系统甚至可以访问FTP等各种文件系统。你可以将多种文件系统封装在一个虚拟文件系统里，使用起来感觉就像是一体的。

联邦机制

对于client客户端来说，访问的是虚拟文件系统这个抽象层，用起来就好像a、b、c都在一个节点上一样。

虚拟文件系统这个抽象层不仅可以挂在NameNode，其他文件系统例如FTP都可以挂载，可以更好的整合抽象数据。

题外话

计算机的所有问题都可以加一个抽象层来解决，如果不行就加两层。
操作内核只暴露两百多个接口，而C语言却暴露N多个库