原则：
在title 底下，要弄清有哪些实际功能。
针对功能分析INPUT, OUTPUT；
（USE CASE -> Functionality -> Architecture ...）
准备：
DB/网络/OS
存储：分布式文件系统
分布式数据库
计算： 批处理（map reduce）
流处理 ( storm)
网站应用
基本概念：
数据中心 (放很多机器的超大机房）
集群 （很多机器，分组， 作为一个有机的整体）
机柜 （rack）
rack switch
core switch
分布式文件系统 ：
- 使用文件系统的接口去管理你的数据
- 数据分布在很多机器上 （Durability）
- 什么时候需要分布式文件系统？
设计的出发点+找到系统的bottle neck
一个CLUSTER的BOTTLE NECK l 100+ PB 的存储，可以到几千个SERVER，文件总数的上限在几亿个
文件数据分为2大类， META data + 实际数据
meta data是固定大小
实际数据可能很大，可能没法放在一个机器里
所有路径信息和 META信息都放在NAME NODE
实际的数据存在DATA Node
name node 单点失效怎么办？ 所以一般会有2个NAME NODE， 一个是ACTIVE，一个是STAND BY， 不参与决策。 ACTIVE NAME NODE做什么，它就做什么。
如果ACTIVE DEAD了，STAND BY 就上了。HOT FAIL OVER。
2个NAME NODE SYNC的机制是，通过LOG。
一般NN 一秒会有上万个写请求， 如果是发消息，万一消息发送失败怎么办（如网络，如对方挂了）。所以用LOG 比较好。
LOG 有2种选择，一个是记录操作，一个是记录状态。
记录操作 如 增加了一个文件
记录状态 如 这个文件夹下现在有文件A,B,C。
那么STAND BY 怎么把LOG 从ACTIVE读过来. 会用一个SHARE NODE。
真正的存储单元不再是整个文件，而是一个个BLOCK。这样这个META INFO 会有多个指针。
name node通过心跳机制 去监控data node的健康情况
让DATA NODE 每过几秒 告诉NN 我还活着。
name node 需要维护一个MAP， BLOCK -》 list<data node ids>
当读文件的时候需要查这个MAP
当写文件，删文件，有DATA NODE 挂了 会更新MAP
三个备份应该怎么放？
首先为了写的速度更高，优先选WRITER自己的DATANODE，或者在同一个RACK的DATA NODE。另外2个备份会在另外一个RACK.
写协议
首先告诉NN，NN去查返回给CLIENT 去写哪几个DN。同时NN 会去建立INODE，把META INFO 都放进去了。
当数据量很大的时候，BOTTLE NECK 在带宽上，为了提高吞吐量。应该让CLIENT只发给一个DN，DN在发给其他的REPLICA 的DN。
可以不用等到前面的ACK，可以直接发下一个。 不过有一个上限，当没收到反馈的数目达到这个上限 需要缓一下。
目的是提高吞吐量。
击鼓传花还有一个好处是，可以减少一次RACK的传输。如果由CLIENT 直接发给多个，那么有2个DN 在另外一个RACK上。需要有2次的跨RACK请求，如果击鼓传花是一次。
如何检测失败？
- ack
- checksum (算法 CRC32C）
同时击鼓传花的方式 可以更好的保证CONSISTENCY。
用版本号来鉴别，哪个REPLICA 的数据是正确的。
在一次写失败后，会用版本号++，然后重新发起写。
完整的协议：
https://blog.cloudera.com/blog/2015/02/understanding-hdfs-recovery-processes-part-1/
读协议：
总结：
- 先提条件：普通机器，组件允许FAIL
- 如何分布存储
meta info vs real data
files vs blocks
heart beat protocol - 如何保证durablity: block replication
读，写协议
吞度 VS 延迟
CHECK SUM
副本一致性
