当前位置：网站首页>分布式定时器

分布式定时器

2022-07-28 11:26:00 【InfoQ】

本文介绍了一种基于时间轮数据结构思想，采用redis存储，构建分布式定时器的方案

1 定时器应用场景

定时器在企点系统中应用的非常广泛。比如以下场景:

场景1) 企点使用了云的trtc服务，trtc系统会给业务方推送各种事件。这些事件可能是乱序的，而且事件可能会丢失。为了解决这些问题，业务需要做一些事情来保障业务逻辑。企点的做法是为每个事件设置一个定时器，如果事件在规定的时间内正常达到，则删除定时器；如果事件丢失，会触发对应的超时逻辑。

场景2) 质检功能需要对电话录音进行智能语音识别。运营商是先给url到业务方，但是此时录音的数据并没有ready，业务方需要在收到录音通知后启动一个定时器，等待一段时间后才能处理录音的内容。

2 分布式定时器具备的功能

相信大部分人都实现过单机定时器。比如STL的map，自身就是有序的，这个数据结构非常适合实现定时器。实现一个单机定时器相对比较简单，但是，单机定时器不具备可扩展、数据持久化、数据的可靠性。如果业务要使用分布式定时器，一般的诉求会包含以下几点要求.

1: 基本操作: 支持定时器的添加、更新、删除操作等操作.

2: 事件回调可靠性: 定时器事件超时之后，要保证业务至少能被获取一次

数据可靠性: 定时器事件需要持久化，不能丢失.

4: 实时性: 定时器支持秒级的延迟。考虑到网络延时，如果1秒内有大量定时器到期，定时器系统需要最大可能的准时达到。接入的业务需要能容忍秒级左右的回调通知偏差。

5: 高性能: 在保证实时性的情况下，系统要能满足大量业务的接入.

6: 高可用: 任何实例挂掉之后，后续实例继续提供服务，避免单点故障的影响。

7: 多租户: 能供多个业务使用

3 业界实现方案

由于redis的zset天然具备排序功能，本身就是一个定时器的数据结构。直接采用zset，并配合分布式锁来轮询zset。该架构比较简单，但是缺点是面对海量定时器超时场景，并发的上限只能在单机，不能水平扩展，容易造成定时器事件的积压，实时性不高。

类似一些分布式消息队列，自带延时队列的功能。但是缺乏删除和修改定时器的能力.

开源界的方案不能很好的满足企点的场景，于是我们设计了一套分布式定时器，来满足业务的需求.

4 企点分布式定时器设计

4.1 定时器数据结构:

定时器实现技术里面，有一种时间轮的思想。定义一个时钟周期和步长，当指针每走一步，会执行当前时钟上的所有定时事件。每一个时钟刻度到期之后，时钟刻度上的这些定时事件如何最快的执行对应的操作，我们可以采用并发的技术来提高执行效率。因为该数据结构对大量定时器过期非常友好，所以我们采用该数据结构作为我们定时器的方案。

如何在分布式场景下存储时间轮是定时器的设计核心。一种办法是自己设计一个数据结构存储在磁盘，但是带来的问题是太复杂了。需要考虑数据复制、存储、数据分片等等一系列分布式系统需要考虑的问题。那么我们能不能采用云上存储系统来存储这种数据结构呢？我们采用腾讯云提供的redis来存储这样的数据结构。

时间指针: 对于每个定时器的时间指针，采用string结构。key是每个定时器租户的id，value指向当前时间轮的轮盘位置。

时间轮：时间轮上的每一个刻度上保存着这一秒所有的定时器事件，如何让这个列表能分段读取，是选择数据结构的关键。我们选择了redis的zset，每一秒刻度指向一个redis zset结构，redis zset存储这一秒定时事件ID的列表。zset支持通过zrange取一个范围，每个范围可以变成一个可以并发执行的任务。

用户数据: 使用string结构，key是定时器ID，value是业务数据。在定时器到期之后，会将这个业务数据带给业务.

4.2 架构

1. 接入层:

接入层主要负责定时器协议解析，提供增加、删除、更新定时器等基本操作。

2. 调度器:

功能

定时器里面有大量租户，每个租户里面又有大量定时器事件到期，如何将这些事件从redis存储里面，快速的发送到消息队列。需要引入调度器这个角色，调度器负责统一调度这个过程，将哪些过期的定时器事件变成任务，交给work执行。

实现细节

任务分配

调度器通过配置中心，拿到所有租户的appid，通过zookeeper协调到本实例需要处理的appid。对于每个appid，开启一个协程执行如下流程。

调度过程。调度器取当前时间刻度，获取当前时间刻度有多少任务。如果任务过大，会将任务拆分成子任务。比如一秒钟有10万个事件超时，会分成10个1万个事件的小任务。调度器将这些子任务投递到任务排队队列，同时设置好任务的状态。work从任务排队队列里面将任务取走，执行完成之后，设置任务状态。调度器定时器扫描任务状态是否都已经执行完成。如果执行完成，会将当期时间刻度向后拨动一秒。

机器时间不准容错。腾讯内部的每台机器，都会使用ntp来做了时间校准。但是如果access所在的机器和调度器所在机器的时间有偏差，会导致调度器已经调度到下一秒了，access却将这个事件写入成功了。这样会导致定时器事件丢失。对于这种情况，在调度器这块，每次取当前时间刻度的定时器事件数量的时候，会取前5秒，如果前面5秒还有数据，会将时间刻度往回拨。同时，如果access判断用户设置的时间比调度器当前时间刻度的时间减去5秒还要小的话，会拒绝该事件写入。所以即使机器上的时间有些许偏差，数据也不会丢。

任务数据结构

任务的分配、任务的状态在调度过程中非常关键，目前zookeeper没有云上托管服务，所以我们没有采用zookeeper作为存储，而是使用redis作为任务管理和分配的存储。任务的数据结构如下：

高可用

appid的分配: 定时器的实例并不是只有一个干活，而是每个实例都可以调度appid。调度器的实例注册到zookeper的路径。通过zk，获取当前有多少个调度器节点。如果hash(appid) % 节点个数 = 注册到zk的数组下标，该appid就被调度器实例执行。

高可用: 像大多数经典的架构一样，定时器采用zookeeper来保持高可用。当一个实例挂了，定时器通过watch zookeeper的path感知到实例的变化，该故障机器所执行的appid将被分配到其它实例的机器。

3.worker执行器

功能

负责将scheduler分发的到期任务投递到kafka消息队列。效率和可靠性是worker的核心考量。

实现细节

流程:

a) 任务polling协程通过SPOP + LUA脚本定期扫描Redis中排队任务，对任务进行认领。将任务更新为执行中，并定时上报任务执行心跳，当scheduler发现任务无心跳并没有执行完成则会重试此任务。

b) 认领后的任务会被再划分为进程级别的子任务进行并发执行。

c) 工作协程通过子任务队列进行子任务抢占。

d) 抢占到的工作协程会拉取Redis中TimerID列表以及对应的UserData，写入kafka进行到期事件投递。

e) kafka client在投递成功后在回调协程中进行计数统计，计数统计用于监控父任务执行进度，当父任务中所有事件执行成功则标识任务执行成功。当父任务执行成功或者失败则同步更新redis中任务状态。Scheduler基于任务状态进行任务重试或者任务成功确认。

实时性:

因为定时器的时间精度为秒级，当1s内大量定时事件到期时，work需要尽量保证在1s内处理完成全部到期事件。worker采用了如下优化手段:

a) 提升并发: 如果每秒有1百万定时器到期，scheduler分发给work的任务，可能是10万个定时器事件，在worker进程里面对这10万个定时器事件做并发处理是满足实时性的必要手段？worker会对一个任务再次拆分成子任务，每一个子任务顺序投递300个到期事件，子任务与子任务可以并发处理，达到提升并发的目的。

b) 降低延时: 事件投递的耗时主要消耗在kafka的生产，保证kafka的高性能生产是保证投递时效的核心。kafka生产高性能主要依赖producer的批量、压缩机制来降低I/O频次，broker的顺序读写、文件分段、pagecache、零拷贝机制来提高消息处理速度。worker基于kafka client提供的异步生产接口进行到期事件投递，可以很好的满足性能要求，但是带来的副作用是异步生产会将数据在client的进程中进行缓存、批量发送，这样会带来当机器宕机时导致的事件丢失，需要采用回调确认的机制来确保消息的可靠投递。

c) 快速失败: 当kafka生产失败或者redis读取失败时，任务已经执行异常，为保证到期事件的可靠投递，快速将任务置为失败，触发scheduler的任务重调度，加快重试速度。

d) Redis请求耗时: 在worker投递过程中，每一个到期事件都需要拉取redis中timerid对应的userdata, 通过redis pipeline的使用，可以极大提高redis的响应速度。

可靠性:定时器服务中到期事件是业务数据，在保证实时性的同时，如何保证到期事件不丢失和尽量保证事件不重复，支持投递at least once语义。worker借助如下手段来支持:

a) kafka服务端数据可靠:

kafka提供partition维度的容灾机制，我们将topic副本数设为3，最小同步副本数量(min.insync.replicas)设为2，即是:除了每个partition的leader外，至少要有1个副本同步完成才算消息生产成功。unclean.leader.election.enable参数设为false，即是: 非ISR(与leader保持同步的副本列表)中的副本不能够参与partition选主。

b) kafka生产端数据可靠:

kafka producer对消息写入提供三种机制, request.required.acks = 1标识，client等待leader写本地日志成功则认为生产成功。request.required.acks = 0标识，client不等待服务端返回即认为生产成功。request.required.acks = -1标识，client等待follower副本确认接收数据成功则认为生产成功。worker选择request.required.acks = -1满足数据的可靠生产。kafka client的异步生产，发送缓存区中数据会被批量压缩发送到broker端，在服务宕机情况下发送缓存区数据有概率丢失导致到期事件丢失。好在kafka client提供了异步发送结果回调机制，worker基于此机制在异步回调协程中对事件投递结果进行确认统计，确保事件被正确投递。

c) kafka消费端数据可靠:

kafka提供commit机制，可以保证数据在未commit时，在client重连时会从未commit位置继续消费，借此机制，定时器client可以确保消息至少被消费一次。

因为定时器任务重试，重复生产等原因会有小概率导致定时事件在client端被重复消费到，timer client基于带过期时间LRU缓存对timerID进行去重，尽量确保事件不重。

d) 任务竞争问题:

Redis的任务认领通过SPOP，确保一个taskID只会被一个worker进程拉取从而减少少竞争。

在极端情况下可能发生，一个taskID被scheduler重复分配，为确保任务被worker进程独占，基于redis单线程特性，借助LUA脚本可以满足redis的事务，worker使用LUA脚本在更新任务状态时，将任务状态表中workerID与本进程进行绑定认领，其它进程无法再认领此任务，确保竞争发生后任务不会重复执行。