需要考虑策略，机制等。
分布式系统，主要在于容错机制上，
如何避免系统崩溃
运行过程中，某台机器挂掉了，这些副本是在块报告之后进行复制
1、表示dn3这个备份已经没有了，三个变两个了，现在的问题是少的副本何时备份
（用同一个策略）挺到块报告之后来处理，它本身是不作处理的
挂了之后，namenode会知道的，在块报告时候就知道了，在元数据中会对dn3中标志的块是废的
，就被认为是废掉的数据，废掉的就没有用了，就得删除数据，
（集群的启动：启动命令发送到目标机器上是有顺序的，启动的过程是
一个集群从停止到启动，首先是namenode启动，namenode是管理的是元数据，停的话则
内存里面没有数据，进程停了就没有内存了，就没有数据了，重新启动的话，需要还原内存元数据
，如何还原，是先加载镜像文件，将日记在内存上操作一遍就OK，这时元数据就OK了，元数据OK
之后，接着启动namenode,启动之前namenode会进入一个安全模式，安全模式是等待datanode启动，
DataNode启动的时候会向namenode进行注册，安全模式是因为块的完整度的伐值，所以DataNode会向
namenode发送块报告，当累计的块的完整性达到伐值后，就会退出安全模式，正常对外服务。）
在元数据中会对dn3中标志的块是废的，再启动的时候，会让被标志的废掉的块要删除掉。
2、 连接断了，会报告namenode，连接不了，需要重新给我分配，因为是高并发的，
负载不一样，所以要重新分配三台机器，而不是分一台
3、丢包是已经是错误的文件，数据是错的，无效的包，这个要从客户端来处理
加调度队列，先加入等待调度的队列中，(可以先进先出)，然后将待调度的调到
正在调度的队列，包就是数据，等待正在调度的包成功传完了，则待调度那个块就可以删除
。如果失败，则重新将待调度的那个块重新上传。
（重传也会有次数的限制，如果几次不成功则，则整个上传过程就是失败的， ）
4、传输链都已经没了，导致整个上传是失败的，失败了之前的blk1,blk2是被视为废的了，、
则会在快报告的时候会删除掉(清除垃圾数据)，上传失败了，返回失败的结果给客户端，要不要重新上传
看客户端要不要再一次发请求连接。
5、 无论上传成功还是失败，都会给namenode返回结果，如果客户端挂了
就不能向namenode发送状态了，超时了，此刻，namenode可以判断客户端上传
失败了，namenode就可以标记一个状态日记，这个数据是失败的，客户端再连接上了
会返回一个东西给客户端，提示你上次失败。
这几个问题，主要是副本机制，出错的时候如何解决，还有如何完善副本数。
==============================
namenode机制
块的信息从哪里来，不是从镜像文件来的，镜像文件是不包含块的信息，哪个块存储在哪个节点上是
不包含的，则启动的时候块的信息从哪里来呢，是从块报告而来，启动的时候，DataNode都要向namenode
报告，报告的就是块的信息，将这些报告加载起来，写到内存里面，块有几个，存储在哪个节点上，则都
知道了
数据是从内存里面写到磁盘里面
如果namenode宕机了，如果只有内存元数据是搞不定的，虽然可以启动起来，但是关机了
就是没数据了，所以需要解决宕机的问题，
（每一个小时或者一百万个操作，来一个镜像文件，镜像文件是存放在name.dir里面）
有内存+镜像，但是镜像是有跨度的，如果在做镜像文件之前的那一瞬间宕机了，则就需要
日记文件，（日记文件是有回滚策略）
随着系统的运行，内存的数据就越来越大，则考虑用什么来做镜像，如果直接从内存做镜像
则肯定有一段时间被占用，不能对外提供服务，
两层不够，则需要加一层，secondary namenode ，只是辅助namenode进行合并镜像文件
检测点的测试，检查是由secondary namenode来检查，来确定，来检查数据，
由点开始-> 到日记的合并-->最终的删除
======================
namenode的问题机制：
2、可以从secondary namenode，
完全恢复的话，则可以多挂几个磁盘
3、考虑一个存储（配置namenode时），一个是整体的计算（考虑DataNode时），
围绕着移动计算，而不是移动数据，看考虑那个为主，存储为主可以调大，计算为主可以调小。
在配置层尽量做到合适的配置
