挂载表的本质是路由表，不在客户端维护路由表，就只能在服务端了。
HDFS的使用场景满足一个假设——“route table变化频率低”。这很容易理解，HDFS很少承接在线业务，离线业务的使用模式相对稳定，那么各子集群容量的增长速度也相对稳定。本文基于上述假设，参考Tair，简要介绍一种基于ConfigServer的轻量级服务端挂载方案。
HDFS 3.0引入了
Router Based Federation方案。该方案最先被引入Yarn，能够及时进行负载均衡，更适合route table变化频率高的场景，用在目前的HDFS上有点“大材小用”。不过使用统一方案的诱惑太大了。。。
方案
需求case：增加新路由。
定义一个逻辑上的ConfigServer，负责维护路由表。NN与ConfigServer保持心跳，请求中携带负载信息，响应中携带最新的路由表，带有版本号v1。
客户端启动时从ConfigServer同步最新的路由表，带有版本号v2。访问过程如下：
- 按照路由表的信息与NN握手，如果路由表显示NN异常，停止访问。
- 如果
v1 < v2，证明NN更新延迟，回退重试；如果重试多次仍然失败（说明NN活但路由表更新异常），则报告ConfigServer NN异常，停止访问。 - 如果
v1 > v2，证明NN上的路由信息已更新，则客户端重新从ConfigServer同步路由表，然后回到1。 - 否则（
v1 == v2），证明路由信息一致，正常访问。
实际上，不需要单独的握手过程，可以将版本号携带在每一次访问请求中。
如果现在添加一个NN3，为NN3添加多个路由，然后ConfigServer的路由表版本号增大为v3，则直到客户端与NN3都同步到路由表v3后，才能正常访问NN3。
路由删除同理，但路由修改涉及FastCopy修改和元数据管理，暂不讨论。
优缺点
优点：
- 主要的failover处理还在客户端，对服务端的影响较小。
- 尽管ConfigServer逻辑上是单点，但负载很轻、状态简单，且更改不频繁，容易配套实现HA方案。就算ConfigServer短时间不可用，
v1 == v2的客户端也可以继续访问NN。 - 如果NN处理请求的同时，收到更新的路由表，可采取保守策略处理并发冲突，因为这一行为不频繁（如，对diff路由加写锁，暂时拒绝对diff路径的访问）。
缺点：
- 一致性问题：引入新组件，更难保证一致性。
- DOS问题：路由表更新时，还是需要一段时间的拒绝服务（DOS）。如果DOS机制设计不合理，很容易降低集群吞吐。
优化点
- DOS问题：如果简单以挂载点为单位，则DOS时间长，可设计forward机制，重定向已经迁移成功的部分子路径。
- 负载均衡：利用ConfigServer收集的负载信息，实现自动的负载均衡（需要改进FastCopy，涉及NN、DN的修改，如何操作？？？）。
- 延迟：ConfigServer与NN间采用Pull模型（NN向ConfigServer发送心跳）。考虑到路由修改通常希望尽快通知NN，可改为Push模型。
- 独享DN：允许NN拥有独享的DN，只需要修改FastCopy的逻辑，就可以在大集群内部支持小集群。
- 版本号：以版本号管理整张route table的粒度太大，可以细化到每条路由，也更容易实现路由的添加、修改、删除（但管理起来会更困难，暂不深入）。
参考：
