python 分布式服务_[Python]利用ZooKeeper构建分布式定时任务

本文涉及的源代码路径：https://github.com/xiaoquqi/openstackclient-demo/tree/master/tooz

一、目前现状及存在的问题

在实际业务系统中，经常有需要定时执行的任务，例如任务状态的定时更新、定时发送状态信息等。在我们的云迁移产品中，允许用户可以设定周期同步规则，定期执行数据同步并调用云平台接口执行快照操作。在单机版本中，通常在同一时间点并发任务量较少的情况下，问题并不是很突出，但是随着我们将云迁移服务从单机版本改造为平台版本后，当多个用户的多台主机同时触发快照任务时，一方面传统的设计方式就成为了瓶颈，无法保证用户的同步任务在同一时间点被触发(需要排队)；另外一方面，目前Active-Passive(简称AP方式)的高可靠部署方式无法利用集群横向扩展能力，无法满足高并发的要求。

软件架构设计

目前云迁移平台的各个服务模块在设计上使用了OpenStack方式，即大部分模块复用了类似Nova的实现框架。即API层直接集成oslo.service中定义好的WSGI Service基类，Worker采用了olso.service中定义好的Service基类，即Eventlet协程方式，API与Worker通讯使用RabbitMQ，API南向接口除少量直接更新数据库操作采用同步接口外，其余所有接口全部使用异步方式。API发送请求后，得到202 Accepted回复，后续通过GET接口不断轮询任务接口等到任务完成。

高可靠部署

根据OpenStack官方的HA部署文档(https://docs.openstack.org/ha-guide/)，将服务分为无状态和有状态两种。无服务状态只需要直接部署多份即可，有状态服务往往需要通过Pacemaker控制副本数量，来保证高可靠。在云迁移平台部署中，我们将全部服务部署于K8S集群中，所以并不需要Pacemaker+Corosync这样的组件(Pacemaker节点上线为16)。但是，由于需要保持定时任务在单一节点被触发(避免任务被重复执行)，所以承载定时快照的模块只能同时存在一个容器在运行，无法构成Active-Active(简称AA方式)模式。这样的部署方式，也造成了上述提到的AP模式对扩展性的瓶颈。

二、问题思路及解决方案

思路一、利用消息队列解耦任务分配与任务执行

从上述对现状的描述，我们不难看出，现有任务分配与任务执行是在同一个任务中执行的，当存在大量任务时，任务执行会对任务产生产生很大的影响。同时，由于任务执行唯一性的需要，在部署上只能采用上述的AP模式，导致任务无法由多个任务同时执行。

所以，我们可以将任务分解为分配和执行两个阶段。任务分配上，单纯的进行任务生成，由于任务生成相对较快，生成后的任务发送至消息队列，由无状态性的Worker接收后执行。这样就解决了单点执行的效率低下问题。

但是这样的解决方案仍然存在缺陷，我们在任务生成的模块仍然必须需要采用AP模式部署，来保证任务的唯一性。如果在任务数量非常庞大时，该部分仍然是一个瓶颈；另外一方面这样的实现方式，我们需要将任务生成部分单独拆分出一个模块，同时增加了开发和部署上的复杂度，所以我们来看一下第二种解决思路。

思路二、利用Zookeeper构建可扩展的分布式定时任务

为了解决思路一的局限性，我们本质上要解决的是任务执行的分布式问题，即如何让Worker不重复的判定任务的归属后再执行，由被动改为主动。

我们来看以下几种场景：

1、假定我们现在有3个Worker可以用于任务生成，在某一个时间点，将同时产生100个任务。如何由这3个Worker主动产生属于自身负责的任务？

2、我们知道大部分云平台目前都有云原生的弹性扩展服务，如果我们结合云平台的弹性扩展服务自动将我们用于任务生成的Worker动态进行调整时，例如变为6个时，还能保证这100个任务能够被自动的由6个节点不重复的产生呢？

3、当负载降低后，节点数量由6个变为3个后，如何恢复场景1的状态呢？保证任务不漏生成呢？

如果想达到以上场景需求，需要以下几个条件：

1、节点之间能够准确知道其他节点的存在——利用Zookeeper进行服务发现

2、尽量合理的进行任务(对象)分布，同时兼顾节点增加和减少时，降低对象分配时的位移——利用一致性哈希环

三、技术要点

1、Zookee