1 Block管理模块的组件和功能
-
BlockManager：BlockManager源码解析
- Driver和Executor都会创建
- Block的put、get和remove等操作的实际执行者
-
BlockManagerMaster：BlockManagerMaster源码解析
- 作为BlockManagerMasterEndpoint的代理类，隐藏实体类
- 执行BlockManager中注册等操作
-
BlockManagerMasterEndpoint：BlockManagerMasterEndpoint源码解析
- 响应远程调用的实体类
- 维护BlockManager的元数据
- 拥有移除RDD、获取Block和更新BlockInfo等功能
-
BlockManagerSlaveEndpoint：BlockManagerSlaveEndpoint源码解析
- Executor端响应远程调用的类
- 内部实际调用BlockManager执行具体操作
-
BlockManagerInfo： BlockManagerInfo源码解析
- 维护着每个BlockManager中所管理的Block
- 持有BlockManagerSlaveEndpoint的实例
-
BlockManagerId：BlockManagerId源码解析
- 作为每个BlockManager的唯一标识
-
StorageLevel： StorageLevel源码解析
- 用来描述Block的存储级别（存储位置、是否序列化和副本数）
-
MemoryStore
- 内存读写实际执行者
-
DiskStore
- 磁盘读写实际执行者
2 整体框架
3 我的思考
在一开始分析BlockManager（BM）、BlockManagerMaster(BMM)、BlockManagerMasterEndpoint(BMME)和BlockManagerSlaveEndpoint(BMSE)时我就感觉它们之间的功能定义和关系不是特别的清晰。
1）BMM作为BMME的代理类，隐藏了BMME的实现，由BMME来完成实际响应远程调用的动作，这个还是比较清晰的，因为BMME维护着BlockManager的元数据信息，由它来完成信息的增删查这个是完全没有问题的。
2）我的疑惑就在于BlockManager的定位是什么？
首先从类设计原则来看，类的功能单一且清晰是比较重要的，因为这样可以清楚地看到类的定位
- 完成实际数据的put、get和remove？这个在BM源码中我们可以看到putBytes、getBytes等方法，这是没有问题的
- BlockManager向Driver注册等
那么BlockManager的定位就是处理一切跟Block读写等有关的工作和注册等工作
3）但是我想来想去这个BlockManager就是处理Slave端的实际Block读写，那么应该叫做BlockManagerSlave更贴切，但是作为一个优秀的开源项目，不应该会出现这样的问题。那么可能是我的理解问题，于是我又进行下面的思考：
Driver和Executor都有BlockManager，那么Driver端BlockManager的作用仅仅是维护Executor端的BlockManager元数据的话，那么Driver根本就没必要创建BlockManager，使用BlockManagerMaster就可以。所以很可能设计目的就是这样的：
- BlockManager的设计目的是作为slave端的实际block管理类
- Driver端的BlockManager实际由两部分功能组成：
- 拥有Slave端BlockManager实际操作Block的功能
- 用BlockManagerMaster来实现Slave端所有BlockManager元数据的维护