序言
总有一天你会笑着说出曾经令你痛苦的事情，毕竟有些东西虽然不是你想要的，但是却是你自找的，表面上是无奈，实际上是懒得去做选择，成功的路只有一条，而失败的路则是各种各样的原因。
得不到的时候念念不忘，得到的时候，却不珍惜，这到底是为什么呢？是忘记了出发的初心还是产生了新的欲望而反被其折磨？
高可用
1 高可用架构对比
HDFS的出现，就是为了解决海量数据的存储问题，从而采用分布式架构存储文件，将一个大文件按照block块来切分，然后分布在不同的机器，不同的机架中，数据节点能水平扩容，从而能海纳百川，存储海量数据。
HDFS是为了存储数据的，从而要保证数据的可靠性，从而就有了datanode数据节点的三副本机制，而且在数据写入的时候，是流水线的方式写入，也就是正常情况下三节点数据写入成功才返回客户端成功，特殊情况下，写入一个也成，毕竟她自带了副本复制机制，也就是当副本数不满足设定的时候，会找到距离近的，负载低的，把数据再复制过去。
HDFS是为了支持海量数据的分析计算的，就像MapReduce程序，文件多副本存储，也就意味着当同一份数据被三个任务跑的时候，可以分布在三台机器上，从而充分的发挥机器的算力。
HDFS是分布式存储的，从而需要一个相当于字典的索引数据，有什么数据，有多少块，权限是啥，用户是啥，从而就有了namenode，既然有了名称服务器，那就意味着要持久化存储，需要保存相关的一些数据，保存的就是fsimage和edit日志信息，在客户端上传数据的时候，将操作日志记录在edit中，然后返回给客户端，而fsimage则是相当于内存的数据，可以理解为基线，像基准测试一样。
如上图所示，可以看到很多的组件，包括zkfc，还有QJM集群，再看看yarn集群的高可用。
对比一下就会看到，yarn集群的高可用架构比hdfs的要简单太多了，没有zkfc，没有qjm集群，只需要一个zk集群来负责选举出active的resourcemanager就好了。
为什么差别这么大？这就是持久化数据的高可用和无状态高可用的区别了，hdfs的namenode要保持高可用，必须要保证数据同步，从而需要一个共享存储QJM来存放edits日志，然后同步到standby的节点上去，而对于resourcemanager来说，并不需要持久化啥数据，也就是无状态的，就像容器一样，直接删除，再创建一个完全没问题，所以差别来说，就是因为需要保存一些数据，这就是有状态和无状态之分。
无状态的可以理解为结婚了，没有娃，而有状态的你可以理解为结婚了有了娃，那有了娃怎么办，你得有人看着吧，说分手就分手，对于无状态是可以的，对于有状态的你得找个人看着，就是一个standby了，而另外一个负责赚钱养家，那就是active了，最怕的就是两个都去赚钱了，然后都active了，俗称脑裂split brain，这个时候一般直接打死一个，让你没事就知道赚钱，打死的那个就是standby，只要看着孩子就成，如果两个都看着孩子，就是两个都不去赚钱了，也就是都是standby，其实还好，只是暂时没钱，不会孩子没人管。。。对于无状态的来说，其实还好，都出去赚钱，最多就是钱多了，也就是执行的任务数量多了点，相当于任务重跑了一下，可能会有数据重复，只要任务设计的好，就不会出现这种问题了，那要是两个都不去赚钱，变成了standby，那么就只能喝西北风了，毕竟刚结婚，还有一大堆的task在那等着需要资源resource呢。
2 近看hdfs
近看一朵花，远看豆腐渣，很多东西，看的太深，就忘记了全局层面的东西，埋头看路，低头看天，啥都没有。。。
#数据节点存储的数据，包括block块数据，还有数据的校验码
[root@KEL subdir11]# pwd
/$HADOOP_HOME/$DATADIR/dfs/data/current/BP-184102405-192.168.1.10-1612873956948/current/finalized/subdir0/subdir11
[root@KEL subdir11]# cat blk_1073744840
1,1613991123,admin,admin
[root@KEL subdir11]# cat blk_1073744840_4016.meta
ʗE[root@KEL subdir11]# file blk_1073744840_4016.meta
blk_1073744840_4016.meta: raw G3 data, byte-padded
在查看数据节点存储数据的时候，需要注意的是，这些数据块和校验信息并不会存储在namenode里面，这个是datanode和namenode进行通信获取，在启动的时候，会统一汇报，这个也是所谓的安全模式safemode，此时你只能查，不能修改增加元数据。
再看一下namenode保存的内容：
#namenode保存的内容，包括edits日志和fsimage
edits_0000000000000053943-0000000000000053944
edits_inprogress_0000000000000053945
fsimage_0000000000000053730
fsimage_0000000000000053730.md5
fsimage_0000000000000053930
fsimage_0000000000000053930.md5
edits_0000000000000013106-0000000000000013107 seen_txid
edits_0000000000000013108-0000000000000013109 VERSION
63 edits_0000000000000013110-0000000000000013111
[root@KEL current]# pwd
/$HADOOP_HOME/$DATA_DIR/dfs/name/current
[root@KEL current]# file fsimage_0000000000000053730
fsimage_0000000000000053730: data
[root@KEL current]# file fsimage_0000000000000053730.md5
fsimage_0000000000000053730.md5: ASCII text
[root@KEL current]# cat fsimage_0000000000000053730.md5
2c8359248cbcc504dca7e3020f8bb309 *fsimage_0000000000000053730
可以看到其中有大量的edtis文件，用来记录相关的操作信息，edits的可以理解为历史的，当前正在使用的inprogress。
#使用lsof可以查看当前进程占用的文件
java 2560 root 233u /edits_inprogress_0000000000000053951
[root@KEL current]# jps
2560 NameNode
[root@KEL current]# lsof -p 2560|grep -v jar
可以使用命令查看fsimage和edits的内容：
#将fsimage转换成xml
[root@KEL current]# hdfs oiv -p xml -i fsimage_0000000000000053730 -o fsimage.xml
[root@KEL current]# vim fsimage.xml
<?xml version="1.0"?>
<fsimage>
<NameSection>
<genstampV1>1000</genstampV1>
<genstampV2>1002</genstampV2>
<genstampV1Limit>0</genstampV1Limit>
<lastAllocatedBlockId>1073741826</lastAllocatedBlockId>
<txid>37</txid>
</NameSection>
<INodeSection>
<lastInodeId>16400</lastInodeId>
<inode>
<id>16385</id>
<type>DIRECTORY</type>
<name></name>
<mtime>1392772497282</mtime>
<permission>theuser:supergroup:rwxr-xr-x</permission>
<nsquota>9223372036854775807</nsquota>
<dsquota>-1</dsquota>
</inode>
...remaining output omitted..
查看edits文件内容：
#将edits log转换成xml格式查看，这个里面没内容
[root@KEL current]# hdfs oev -p xml -i edits_0000000000000013122-0000000000000013123 -o edits.xml
[root@KEL current]# vim edits.xml
[root@KEL current]# cat edits.xml
<?xml version="1.0" encoding="UTF-8"?>
<EDITS>
<EDITS_VERSION>-63</EDITS_VERSION>
<RECORD>
<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
<DATA>
<TXID>13122</TXID>
</DATA>
</RECORD>
<RECORD>
<OPCODE>OP_END_LOG_SEGMENT</OPCODE>
<DATA>
<TXID>13123</TXID>
</DATA>
</RECORD>
</EDITS>
查看journal node保存的内容：
#保存的都是edits文件，active写入，standby的读出
[root@KEL current]# cat last-promised-epoch
78
[root@KEL current]# cat last-writer-epoch
78
[root@KEL current]# ls -l edits_*|wc -l
5652
在高可用架构中，zkfc其实就是namenode的zookeeper连接客户端，当namenode进程挂了之后，zkfc进程是第一时间知道的，然后就执行fence程序，把namenode的状态设置为standby，但是当zkfc进程挂了呢，那就要等一段时间了，因为zkfc只负责自己namenode节点的生杀大权。
在进行高可用搭建的时候，还需要进行格式化
最低0.47元/天 解锁文章
2916
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
