CAP原则
强一致性会破坏可用性
Consistency：一致性
是指在同一时刻,分布式系统中NameNode主备节点里元数据始终是相同值。
Availability：可用性
不会因为NameNode备节点网络延迟导致主节点等待卡顿。
或指NameNode中的某一个节点故障宕机后，集群还能响应客户端请求，并且数据不丢失。
Partition tolerance：分区容忍性
能不能尽量保证一致性的情况下，将数据拆分开来，分散存储。
例如：
1.DataNode节点。
2.系统中一部分节点无法和其他节点进行通信情况下，系统也能够正常运行。
CA
单机情况，很容易满足
CP
两台服务器，分别存储一部分数据。如果一台服务器宕机，一部分数据丢失。
AP
分区容忍性结合一致性会使，数据库数据分散存储，并且要求各个节点数据始终相同。这样就会造成较高的网络延迟等卡顿情况，降低可用性。
Paxos 算法
- Paxos算法是莱斯利·兰伯特于1990年提出的一种基于消息传递的一致性算法。
- 这个算法被认为是类似算法中最有效的。
- 该算法覆盖全部场景的一致性。
- 每种技术会根据自己技术的特征选择简化算法实现。
- 传递：NN之间通过一个可靠的传输技术，最终数据能同步就可以
- 我们一般假设网络等因素是稳定的
- 类似一种带存储能力的消息队列
简化思路：
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多个库