在RBF出现之前的ViewFS还是现在发布的RBF，目前支持的映射模式都是1对1的。什么意思呢？就是一个虚拟路径地址对一个实际集群地址。这种方式会有个弊端，如果写入的数据量很大，那么这个集群会出现容量用完的情况。针对这种潜在的“大路径”，其实我们可以希望他的目标集群地址可以有多个。这样就可以减轻单一集群的高负载现象了。但是如果支持配置多个地址，那么地址的选择策略将是一个很重要的环节了。因为数据写出去了，你还必须要保证能把这个地址重新找到吧。笔者今天就来聊聊这个有意思的话题，目前在社区中正在实现。
多目标集群支持的目标简单来说，RBF写出支持多目标集群写出就是为了解决一个负载均衡的问题。这样会使得RBF使用起来更具扩展性。
但是在前言中同样提到，这里的难题实质上就变成了目标集群地址的选择策略问题。一种自然联想到的最简单的策略就是随机选择。哪怎么逆向找到这个写出位置呢？每个集群都尝试执行一次RPC请求，因为没有地方保存最好的真实映射关系。Mount table信息仅仅提供虚拟路径对多个地址的映射，仅到这个层面。当然这只是一种最简单不过的策略实现，其实RBF在实现这块逻辑的时候，还是考虑了不同的策略算法的。我们继续往下看。
目标集群选择策略这块内容就是上节提到的目标集群的选择策略部分了。如果一个虚拟路径映射到多个集群路径地址时，当前支持哪几种策略呢？答案有以下5类：
- 随机选择策略。
- 本地优先策略。
- 完全哈希策略。
- 局部哈希策略。
- 基于可用空间的策略（待实现）
下面笔者逐一来解释。
第一种，随机选择策略，这个很简单，调用随机数生成函数即可。因为对于相同路径，每次产生的结果是不可预测的，再对这些文件进行读操作的时候，是通过遍历所有潜在的集群位置来定位实际的位置。
第二种，本地优先策略。这里的“本地优先”，指的是请求发起方与实际目标集群的位置优先关系，优先选择请求发起方所在的集群为首先目标集群。所有此策略，要维护一套 [IP, 集群id]映射关系，然后客户端发起请求时，进行映射判断，选择一个最“近”的集群。
第三种，完全哈希策略。这种策略我们可以理解为是一种随机策略。不过它比随机策略更“高级”一些。它的内部实质上是用一致性哈希算法来做目标集群的选择的，用一致性哈希算法的好处是为了减少未来由于集群的变更（添加或移除）导致目标文件数据的重新定位。
第四种，局部哈希策略。此策略的本质与完全哈希策略一样，继承了上面的策略类。唯一不同的在于“局部”，此策略在哈希生成key的时候，用的是第一层级路径，而不是全路径，这保证了一点，在同一父目录的路径，它们的哈希值是相同的，对应所找到的集群位置也会是相同的。
第五种，基于可用空间的策略。此策略类遵循的一个原则：每次尽可能选择当前目标集群中可用空间最富余的集群，作为目标集群。这在大体上能够保证集群间的数据平衡。
小结以上就是今天笔者分享的内容，详细代码逻辑可前往社区JIRAHDFS-13224:RBF: Resolvers to support mount points across multiple subclusters。写到这里，笔者觉得这种方式的主要创新点在于它打破了人们固有的认为映射关系只能是一对一的形式，笔者朋友可以仔细体会体会。
