集群任务均衡的一种实践

集群任务均衡的一种实践
场景：
任务多，例如从kafka拉取消息的任务，每个kafka topic的partition是一个任务，每个任务是一个线程，此类任务数量还比较多，拉取也比较频繁。这类任务如何均衡的分散到集群的机器上呢？
目前的任务分配策略如下

● 启动时，执行器从任务池中捞取所有需要执行的任务
● 每个任务启动一个线程执行
● 任务的逻辑如下
○ 抢锁，抢任务执行的锁，抢到锁的执行任务
○ 不断的拉取消息
○ 处理消息
○ 。。。
举例，例如任务A，执行器1抢到了该任务的锁，则其他执行器只能等待，或重试，当执行器1抢到了锁，其他所有的执行器都是任务A的冷备机器，如果执行器1挂了，则其他执行器可以立即上线执行任务。
但这么做会有一些极端的情况，例如集群有三个执行器，执行器1先启动，执行器1就会把任务池中所有的任务全包揽了，执行器2、3启动时，会因为抢不到任何一个任务的锁，一直处于空闲等待状态。执行器1则一直很忙碌，如果任务比较多或重，很有可能导致执行器1直接挂掉，然后由执行器2，执行器3处理所有的任务，对执行器2，执行器3来说仍然会有崩溃的风险。

如何能够将任务均分到集群的各个机器呢？后来我们优化了一版，架构如下

● 配置任务池对应的执行器个数，例如 executor.num=3
● 执行器启动后，会注册到zk，通过zk临时顺序节点机制，得到一个id
● 根据id及executor.num，对任务池中的任务分片，每个执行器只处理自己对应的分片任务

这样任务分布就均衡了。另外为了防止单个执行器宕机，支持增加冷备机器，例如id=4的机器就是id=1的冷备，但每个执行器都有个冷备也是很耗费资源的。（有点类似于redis的集群架构方案）
因此，这里也可以优化，比如id=2的执行器，也注册个虚拟节点id=4，作为id=1的冷备，id=3的机器，注册个id=5的机器，作为id=2的冷备。
我们实际实践中，并没有使用冷备的方案，而是借助运维手段实现的。因为线上所有的机器都是k8s管理的，部署在容器中，k8s中提供了崩溃恢复的能力，可满足我们的需求，这样也减少了我们的成本。