【性能优化】9.7 [集群] 多作业负载均衡
9.7 多作业负载均衡
和单机上的多线程并行类似，第一节中讲述的多机并行框架也会等待最慢的分机返回结果后才会继续。我们可以尽量使分机计算的数据量更均衡，但并不能保证各分机执行速度相同，仍然无法避免发生快分机等待慢分机的现象。大多数情况时这个等待并不会太严重，但要追求极致性能时就不能容忍这种浪费了。
理论上我们可以像处理多线程那样，把任务拆得更碎，然后动态分配，从而均衡各分机的负载，以减少等待时间。不过多机的情况要复杂一些，要有数据冗余才能实现动态负载均衡。如果某份数据只在一个分机上保存，那也只有这台分机可以计算这份数据，其它分机即使更快也只能等待，否则要通过网络把数据传送过来，这不仅会有网络延迟，还会消耗数据所在分机的计算资源，结果常常得不偿失。而同一台机器上的多个线程是共享存储的，不存在这个问题。
A |
|
1 |
["192.168.0.101:8281","192.168.0.102:8281",…, "192.168.0.104:8281"] |
2 |
=callx("sub.dfx",to(1000);A1) |
callx 函数可以实现这种机制，参数中的 sub.dfx 是分机上用于计算作业的脚本，以作业号为参数。A2 将会生成 1000 个作业，先发出一部分给分机使每个分机达到极限作业数，然后某个分机完成一个作业后就会再分配一个，从而实现动态均衡。如果某作业用到的数据不在分配的分机上而导致计算错误时，callx 将会把该作业重新分给另一个分机，如果没有分机可以执行该作业，则计算失败。
计算结束时，A2 得到每个 sub.dfx 的返回值构成的序列，以作业号为序。
大量作业时还有一个问题。每个作业完成后都会向主机返回结果，返回的次数就会很多，这同样会带来较沉重的网络负担。而很多运算都可以由分机先进行一轮汇总再返回，这样返回次数就会减少到只有分机个数那么多了。
callx 函数还有个参数指明这个用于先汇总的运算脚本。
A |
|
1 |
["192.168.0.101:8281","192.168.0.102:8281",…, "192.168.0.104:8281"] |
2 |
=callx@m("sub.dfx",to(1000);A1;"reduce.dfx") |
3 |
=A2.sum() |
假设计算任务是将每个 sub.dfx 的返回值求和, 则 reduce.dfx 的代码为：
A |
|
1 |
return p1+p2 |
其中 p1 和 p2 是 reduce.dfx 的两个参数。p2 是每个作业的返回值，p1 是分机当前的汇总值，分机每执行完一次作业，就会调用一次 reduce.dfx，得到新的汇总值来替代当前值。分机完成所有作业后，将最后的分机汇总值作为本分机的返回值传送给主机，这时候 A2 将得到每个分机的返回值构成的序列，以其参数中的分机为序（即 A1）。这里的 p1 和 p2 有点像迭代函数中的 ~~ 和 ~。
分布式计算术语把这个由分机做的汇总动作称为reduce。
分布式计算术语把这个由分机做的汇总动作称为 reduce。
