zookeeper
Zookeeper是一个分布式的协调服务框架
（1）主要解决的问题：提供可靠的、可扩展的、分布式的、可配置的协调机制来管理整个集群的状态。
（2）ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
（3） ZooKeeper提供了什么？
- 文件系统
- 通知机制
（4）Zookeeper的特性：
- 数据一致性
- 原子性
- 可靠性
- 实时性
- 过半性
- 顺序性
（5） Zookeeper做了什么？
①实现集群管理（由于它自身的集群通信机制比如说为每一个集群节点建立一个临时节点在这个节点down机· 之后临时节点会销毁），
②集群的统一配置管理（由于它的数据一致性）
③统一命名服务（由于它内部维护的znode树）的节点是不能够重复的。
④实现分布式屏障（这个就像栅栏一样，实时监测就绪的数据节点以便下一步的操作）
⑤实现分布式锁（这个就是在多个客户端发起资源的请求时我们只服务事务id最小的那个，以免造成资源的争抢）
⑥实现数据的订阅和发布（这个就是让客户端监听znode节点当数据更新时就可以自动获取消息）
（6）Zookeeper结构
- Zookeeper默认有一个根节点（ /）；
- 每一个节点都可以拥有子节点每一个节点都可以拥有子节点；
- 每个节点为一个znode节点，每一个znode节点都可以存储数据，多个znode节点共同形成znode树，znode树是维系在服务端内存中的，目的是为了客户端快速查询节点以及节点的数据；
- 每一个znode节点的路径都是唯一的，这个特性实现了统一命名服务；
- zookeeper有事务的概念，可以进行创建、更新、删除节点，每一个事务都会分配一个全局递增的ID；
- 有四个类型节点：1普通持久节点 （create）2临时节点(create -e) 3顺序节点(create -s) 4临时顺序节点(create -s -e)
（7） zookeeper选举，分为两个阶段
1）数据恢复阶段
这个阶段，每一个zk服务器要找自己所拥有最大的事务ID，也就是找到自己拥有的最新事务
2）选举阶段
每台zk服务器都会提交一份选举协议数据包，包含自己的最大事务ID（zxid）、自己选举的id(myid中的数字)、逻辑时钟值（确保每一台zk服务器都在一轮选举中）、所处状态（包括Looking正在选举、leader领导者、follower跟随者、Observer观察者）
原则：首先比较最大的事务id，谁大谁就当Leader，ID越大数据越新 如果事务ID比较不出来，就比较选举id,谁大谁就是Leader
注意：zk服务器数量最好为奇数，可以更好的满足过半要求，也就是过半存活
（8）ZAB协议
ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。采用了过半策略
包括两种模式1）消息原子广播（保证数据的一致性）2）崩溃恢复（解决2pc算法的单点问题）
（9）观察者
如果有大量的Follower，选举就变得比较困难，因为添加了更多的投票成员，写入性能下降。
引入一个新的Zookeeper节点类型叫做Observer(观察者)，它不参与投票，只是监听投票结果，其他的和Follwer类似。大大增加了集群的可扩展性。
Hadoop 之HDFS
HDFS是hadoop的三大组件之一，是Hadoop的分布式文件系统，可以说是一个分余展的大硬盘，分就是分布式，余就是数据有冗余，展就是可以扩展的。HDFS是以数据节点的方式存储数据的，它分为Namenode和Datenode，其中Namenode节点是存放的元数据，也就是一些文件与数据分块的映射以及Datenode之间的映射，也就是目录文件，真实数据存放在Datenode中，
Hadoop是通过两个文件来进行元数据存储的，Fsimage文件存储的是整个元数据信息，Edits文件存储的是操作记录，每次客户端发起的操作会先写入整个Edtis文件中，这个文件会定期（3600s）合并,当edits达到64M同步一次，确保Fsimage文件里的元数据是最新的 第一次使用时使用初始化命令是为了生成新的这俩个文件。还有一个Fstime,记载checkpoint的时间，也就是上一次我的fsimage更新时间，然后就可以计算出下一次更新时间。
每次Hdfs启动时，每一个DN会向NN汇报自身的文件块信息，NN会进行检测，比如文件块达到要求。如何未达到数量要就会进行块的复制，此时HDFS会进入安全模式。安全模式下，只能提供读服务，不能写服务。
NameNode
主要负责元数据的存储和处理用户的请求，在HDFS中存放一个大的文件是需要分块存储的。默认大小为128M，如果文件大于128M就会被分为多块。一条元数据包括文件名，复本数量（备份数量），文件分块，以及每个分块具体在哪个DN（DataNode）上。
DateNode
所有的文件在DN上都是以块来存储的，其中核心概念就是心跳机制,DN每个一段时间（默认是3秒）就会给NN发送一个数据包（心跳报告）。里面包含两种信息，他的存活状态以及他里面的数据信息。NN会根据心跳报告来更新自己的元数据信息。同时NN也会回送一些信息，DN就会根据这些信息来增加删除和移动节点说你干嘛的数据，如果10分钟之内没有发送心跳报告的话那么NN就会认为当前的DN已经lost，并且当前节点上丢失的数据补充到其他节点上，所以说NN并没有主动的管理DN而是DN主动去请求NN的。
Block副本放置策略
第一个副本：放置在上传文件的DN，如果是集群之外提交，就随机选择一台磁盘不太满，cpu不太忙的节点
第二个副本：放置在第一个副本不同机架的节点上
第三个副本：放置在与第二个副本相同机架的不同节点上
更多副本：随机节点(哪个节点比较空闲,就放到哪个节点上)
读写流程
读：①客户端对NN发起rpc请求，告诉自己想要请求的资源。
②NN会更根据客户端的情况返回给用户数据包，包括文件与block的映射以及block与DN的映射关系，如果请求数据过多，NN只会返回给用户一部分元数据
③客户端拿到元数据之后会就近原则的去DN上找数据。如果当前客户端就是一个DN的话而且请求的数据也在本机删，name就会直接读取本机的数据
④每读取完一个块的时候会有一次checksum操作检查，读取到数据与从NN那里拿到的元数据的信息是否一致，如果不一致的话那么就会告诉NN这个块已经损坏，让NN删除该块而自己再去其他的DN上读取该数据块
⑤如果读完这一批的数据块客户端会再次询问有没有其他的数据块，如果有那么就再次进行新的一轮，直到全部数据块都读取完毕
⑥当所有的数据块都读取完毕后，客户端会告知NN全部读完让它关闭不在使用的资源。
写：①客户端首先向NN发起一个RPC请求，告知NN我要写文件了。
②NN收到请求，判断这个要写的文件是不是已经存在，这个客户端有没有权限，都满足的话，就会做一个上传文件记录，否则就抛出异常
③得到看NN的首肯，就开始写文件，首先将文件分成一个个的package，组成一个packages,packages火车一个data queue队列，然后客户端会按照这个队列的顺序依次写到hdfs上
④当package写入一个节点时失败，则会通知NN删除这个残缺的数据，然后继续写到其他完好的DN上
⑤当一个package写入完成之后会使用pipeline的技术将数据复制到其他DN上作为副本。在一个节点完全成功之后DN给客户端恢复一个ack packet。此时在客户端的ack queue中增加当前这条信息，同时在data queue中删除当前传输成功的package转向下一个package的传输
⑥如果在上一步的过程中出现了DN损坏，那么这个DN就会在管道中移除，NN会再次分配一个DN保持冗余节点的一致。
⑦在全部写完之后，客户端就会告诉NN全部传输完毕，然后NN就会关闭其他不在使用的资源。
删：①客户端向NN发起请求，NN判断文件状况和权限
②如果满足条件NN受限在日志中删除这个文件，然后再内存中删除这个文件。此时文件还在DN上存储，并没有删除
③之后DN向NN发起心跳报告，和NN中的元数据做比较，发现元数据中某些文件已经被删除，就在一段时间后删除这个已删除的文件
765
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
