做设计外包的网站常用的网络推广方法
目录
理论知识点
角色功能
元数据持久化
安全模式
SecondaryNameNode(SNN)
副本放置策略
HDFS写流程
HDFS读流程
HA高可用
CPA原则
Paxos算法
HA解决方案
HDFS-Fedration解决方案（联邦机制）
理论知识点
角色功能
元数据持久化
另一台机器就是SecondaryNameNode(SNN)
安全模式
不保存位置信息的原因，是因为当机器重启恢复后，DN会和NN建立心跳，汇报块信息。这个过程叫安全模式。
SecondaryNameNode(SNN)
非HA模式下才有，SNN跟版本没有关系，企业一般不用SNN，而用高可用HA方式。
副本放置策略
塔式服务器：竖的，价格便宜
机架服务器：扁的，价格中等，最上面放一个交换机，ups(电源，电池防断电)
刀片服务器：插入的，价格较贵
2.x修正为第二个副本立即出机架，因为有可能把副本数修改为2
HDFS写流程
某个时间点，传其中一个block的时候状态图
client向NN请求创建文件，这个时候NN返回副本放置策略，按距离排序
HDFS读流程
HA高可用
主从：单点故障、压力过大、内存受限
2.x匆匆上线HA，只实现了一主一备，3.0之后一周多备，可以支持5个，官方推荐3个
一份为二，上面蓝色是故障切换自动化，下面是手动的HA模式
CPA原则
分区容忍性：即脑裂，
Paxos算法
帕克索斯算法：Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。
主从+过半
参考：https://www.cnblogs.com/crazymakercircle/p/14341015.html
强一致、弱一致都能做，区块链中也是基于该算法
ZooKeeper中使用的是Paxos的简化版本ZAB，ZK做分布式协调
早期用的多，后来大家都把他剔除了，最多用zk选个主，做配置的同步，或者唯一性。因为zk解决是解决的是事件的触发，解决决策之间某一种事件的调用，不适合存东西。
JournalNodes(Journal杂志、期刊) 跟ZK不是一个东西，JournalNodes做分布式存储
JournalNodes是为了解决节点之间数据同步的。
HA解决方案
FalioverController是用来做健康检查的。
跟NN在同一个节点，它们是不同的进程，FalioverController会监控NN是否活着。
ZK维护一个目录树结构，主备FalioverController会在ZK同时申请在X节点下抢锁，谁抢到谁就是active，否则是standby。
当FalioverController进程监控到了Active的NN挂了，然后FalioverController会把ZK当中抢到的锁删掉。锁删除是一种事件机制，会有callback。
ZK Watch监控：FC抢锁时还在ZK的锁上注册了自己的地址还包括回调函数，当FC删除锁时，产生删除事件，这个删除事件就会触发callback，就会回调FC里的方法，在fc的进程里执行，这是FC发现锁没有了会重新抢锁。
如果是轮询查询锁在不在，会存在轮询间隔，所以会用事件callback机制。
NN还活着，FC挂了，与ZK节点挂了，FC临时节点随着TCP连接的消失，会触发删除事件。
FC会去检查之前Active的NN是不是真死了，没死就把它降级为standby，再把自己升级为active。当网络不通或者什么异常导致无法判断对方是不是真的挂了，此时不会把自己升级为active，这种情况出现的几率很低。（两台主机通过串口相连，这个连接可以当成可靠的）
HA模式下，SNN的角色被Standby替代了，不承担服务，滚动生成FsImage，并把生成的FsImage推回去，以便宕机后的快速恢复。
HDFS-Fedration解决方案（联邦机制）
联邦机制：各个联邦，属于同一个国家，统一一套资源
