Workerman如何实现定时器？Workerman定时任务怎么写？
|
7
|
php框架

3911 字
|
15 分钟

Workerman定时器通过Timer::add()方法实现高精度、事件循环内的周期或延时任务，支持毫秒级调度，与Cron相比精度更高、性能更好，但依赖进程存活。为避免阻塞，应拆分任务、使用Task Worker或消息队列异步处理。定时任务默认不持久化，需结合数据库或Redis存储配置，并在onWorkerStart中重新注册以实现持久化。多实例部署时，通过Redis分布式锁防止重复执行，确保高可用。混合使用Workerman定时器与Cron可兼顾实时性与系统级任务调度。

Workerman如何实现定时器？Workerman定时任务怎么写？

Workerman实现定时器主要通过其内置的

Timer

类，这使得在Workerman进程内部进行周期性或延时任务变得非常便捷。编写Workerman定时任务，本质上就是利用

Timer::add()

方法来注册一个在指定时间间隔后执行的回调函数，或者一个在特定时间点只执行一次的函数。这种机制与传统的系统定时任务（如Cron）有所不同，它直接运行在Workerman的事件循环中，因此能实现毫秒级的精度，并且能够直接访问Workerman应用内的上下文和资源。

解决方案

在Workerman中，实现定时器主要依赖于

WorkermanLibTimer

类。它的核心方法是

add()

和

del()

。

1. 注册一个定时器：

Timer::add(float $interval, callable $callback, array $args = [], bool $persistent = true)

  • $interval

    : 定时器触发的间隔，单位是秒，可以是浮点数（例如0.1表示100毫秒）。

  • $callback

    : 定时器触发时执行的回调函数。

  • $args

    : 传递给回调函数的参数，一个数组。

  • $persistent

    : 是否持久化。如果为

    true

    （默认），定时器会持续执行直到被手动删除或进程退出；如果为

    false

    ，定时器只执行一次。

Timer::add()

方法会返回一个定时器ID，这个ID可以用于后续删除定时器。

示例代码：

<?php use WorkermanWorker; use WorkermanLibTimer;  require_once __DIR__ . '/vendor/autoload.php';  $task = new Worker(); $task->onWorkerStart = function($worker) {     // 每2.5秒执行一次，打印当前时间     $timer_id_periodic = Timer::add(2.5, function() {         echo "周期性任务执行了，当前时间：" . date('H:i:s') . " ";         // 假设这里执行一些数据清理、状态检查等任务     });     echo "注册了一个周期性定时器，ID: " . $timer_id_periodic . " ";      // 5秒后执行一次，然后自动停止     $timer_id_once = Timer::add(5, function() {         echo "单次任务执行了，只执行一次，当前时间：" . date('H:i:s') . " ";         // 比如，延时发送一个通知，或者在某个条件满足后执行一次特定操作     }, [], false); // 注意这里的 false，表示非持久化     echo "注册了一个单次定时器，ID: " . $timer_id_once . " ";      // 假设我们想在某个时刻手动删除一个定时器     // 比如，10秒后删除上面注册的周期性定时器     Timer::add(10, function() use ($timer_id_periodic) {         if (Timer::del($timer_id_periodic)) {             echo "周期性定时器 " . $timer_id_periodic . " 已被手动删除。 ";         } else {             echo "尝试删除定时器 " . $timer_id_periodic . " 失败或已不存在。 ";         }     }, [], false); };  Worker::runAll();

2. 删除一个定时器：

Timer::del(int $timer_id)

  • $timer_id

    : 

    Timer::add()

    方法返回的定时器ID。

  • 如果成功删除，返回 
    true

    ；否则返回

    false

    。

通过这种方式，你可以在Workerman的任何Worker进程中灵活地创建和管理定时任务。需要注意的是，这些定时器是与当前的Worker进程绑定的，如果Worker进程重启，所有未持久化到外部存储的定时器都会丢失。

Workerman定时器与传统Cron任务有何不同，我该如何选择？

在我看来，Workerman的定时器和传统的Linux Cron任务，虽然都能实现“定时执行”的目的，但它们的设计哲学和适用场景却有着本质的区别。理解这些差异，对于我们选择合适的工具来解决具体问题至关重要。

Workerman定时器：

  • 优点：
    • 精度高： 可以达到毫秒级甚至微秒级的精度，这对于需要精确控制时间间隔的应用（比如实时数据推送、秒级数据统计）非常有用。
    • 内存驻留，性能好： 定时器直接运行在Workerman的内存中，没有额外的进程启动开销，上下文切换成本低，执行效率非常高。
    • 应用内集成： 能够直接访问Workerman应用中的全局变量、数据库连接池、缓存等资源，无需额外的进程间通信。
    • 事件驱动： 与Workerman的事件循环无缝集成，可以与其他异步I/O操作（如网络请求、数据库查询）协同工作。
  • 缺点：
    • 与Workerman进程耦合： 如果Workerman进程崩溃或重启，所有在内存中注册的定时器都会丢失，除非你做了额外的持久化处理。
    • 单进程阻塞风险： Workerman的单个Worker进程是单线程的。如果定时任务执行时间过长，会阻塞整个Worker进程的事件循环，影响其他请求的处理。
    • 资源消耗： 如果定时任务过多或过于频繁，可能会增加Workerman进程的内存和CPU负担。

传统Cron任务：

  • 优点：
    • 独立性强： Cron任务与应用程序完全解耦，即使应用程序崩溃，Cron也能独立运行。
    • 系统级调度： 适合执行系统维护、日志清理、数据备份等与应用逻辑关联不大的任务。
    • 鲁棒性： 广泛应用于生产环境，稳定可靠，管理工具成熟。
    • 长时间任务友好： 即使任务执行时间很长，也不会直接影响其他应用的运行，因为它通常是独立进程。
  • 缺点：
    • 精度低： 通常只能精确到分钟级别，无法满足高精度定时需求。
    • 资源开销： 每次执行都需要启动一个新的进程，存在一定的资源开销。
    • 上下文隔离： 无法直接访问应用程序的内存状态，如果需要与应用交互，通常需要通过文件、数据库或API进行通信。
    • 管理复杂： 对于大量的、动态变化的定时任务，管理Cron条目可能会变得繁琐。

我该如何选择？

在我看来，选择哪种方式，关键在于你的任务性质和对系统稳定性的要求。

  • 如果你的任务需要高精度、与Workerman应用深度集成、且执行时间短（不阻塞事件循环），那么Workerman定时器是首选。 比如，你需要每隔几百毫秒检查一次某个队列状态，或者在用户会话过期后立即清理相关资源。
  • 如果你的任务是系统级的、对时间精度要求不高、执行时间可能较长、或者需要与应用完全解耦，那么Cron任务更合适。 比如，每天凌晨进行数据库备份，每周清理一次旧日志文件，或者每小时同步一次第三方数据。
  • 混合策略： 实际上，很多复杂的系统会采用混合策略。Workerman定时器负责应用内部的实时、高精度任务，而Cron则处理系统级的、周期性较长或计算密集型任务。甚至，你可以让Workerman定时器触发一个异步任务，然后通过消息队列将其发送给一个独立的Cron消费者进程来处理，这样既利用了Workerman的实时性，又避免了阻塞。

如何处理Workerman定时器中的长时间任务，避免阻塞？

这是一个非常关键的问题，也是我在实际开发中经常遇到的挑战。Workerman的Worker进程是单线程的（在PHP层面），这意味着在一个Worker进程中，任何一个任务如果执行时间过长，都会阻塞整个事件循环，导致该Worker无法处理其他客户端请求或执行其他定时任务，进而影响整个服务的响应速度和用户体验。

要避免这种阻塞，我总结了几种行之有效的方法：

1. 任务拆分与分批处理：

如果你的长时间任务可以被分解成多个小任务，那么这就是一个很好的解决方案。例如，你需要处理100万条数据，不要在一个定时器回调中一次性处理完。你可以：

  • 分批处理： 每次定时器触发时，只处理其中的一小部分（比如1000条），然后更新一个偏移量或状态，等待下一次定时器触发时继续处理下一批。
  • 利用异步I/O： 如果任务涉及大量数据库查询或外部API调用，确保这些操作是非阻塞的。Workerman本身对数据库和网络I/O有很好的异步支持。

示例（伪代码）：

Workerman如何实现定时器？Workerman定时任务怎么写？

Animate AI

Animate AI是个一站式AI动画故事视频生成工具

Workerman如何实现定时器？Workerman定时任务怎么写？75

查看详情 Workerman如何实现定时器？Workerman定时任务怎么写？ 

// 假设有一个全局变量或存储来记录处理进度 $currentOffset = 0; $batchSize = 1000;  Timer::add(1, function() use (&$currentOffset, $batchSize) {     // 从数据库中获取一批数据     $data = getDataFromDB($currentOffset, $batchSize);      if (empty($data)) {         // 数据处理完毕，可以停止定时器或重置         echo "所有数据处理完毕。 ";         // Timer::del($currentTimerId); // 如果需要停止         $currentOffset = 0; // 重置以便下次重新开始         return;     }      foreach ($data as $item) {         // 处理单条数据，确保这里的处理是快速的         processSingleItem($item);     }      $currentOffset += count($data);     echo "已处理到偏移量: " . $currentOffset . " "; });

2. 任务委托给独立的Worker进程（Task Worker）：

Workerman本身提供了

Task

机制，你可以创建一个专门的

TaskWorker

进程组来处理耗时任务。当一个定时任务需要执行长时间操作时，它不直接执行，而是将任务数据发送给

TaskWorker

。

TaskWorker

会在独立的进程中执行任务，完成后可以将结果返回给主Worker（如果需要）。

  • 优点： 主Worker进程不会被阻塞，可以继续处理其他请求。
  • 缺点： 增加了进程间通信的开销，需要额外的 
    TaskWorker

    配置。

3. 引入消息队列（Message Queue）：

这是处理长时间任务和高并发场景的黄金法则。当定时任务触发时，它仅仅是将一个“任务消息”推送到消息队列（如Redis List、RabbitMQ、Kafka）中，然后立即返回。接着，由独立的消费者进程（可以是另一个Workerman Worker，也可以是其他语言编写的服务）从队列中拉取消息并执行实际的耗时操作。

  • 优点：
    • 完全解耦： 任务的生产者和消费者完全分离。
    • 异步处理： 生产者无需等待任务完成。
    • 削峰填谷： 能够平滑处理突发的高负载。
    • 高可用与扩展性： 消费者可以横向扩展，队列本身也具有持久化和容错能力。
  • 缺点： 增加了系统的复杂性，需要部署和维护消息队列服务。

示例（使用Redis作为消息队列）：

// 在定时器回调中 Timer::add(60, function() use ($redis) { // 假设 $redis 是一个 Redis 客户端实例     $taskData = [         'type' => 'heavy_report_generation',         'params' => ['user_id' => 123, 'date' => date('Y-m-d')]     ];     $redis->rPush('heavy_task_queue', json_encode($taskData));     echo "已将报告生成任务推送到队列。 "; });  // 在另一个独立的消费者Worker进程中（或一个独立的PHP脚本） // 循环从 'heavy_task_queue' 中 lPop 消息并处理

4. 

pcntl_fork()

（谨慎使用）：

对于CPU密集型任务，理论上可以使用

pcntl_fork()

在定时器回调中创建子进程来执行。子进程执行完毕后退出，不会阻塞父进程。

  • 优点： 可以在同一台机器上利用多核CPU。
  • 缺点： 非常复杂！ 需要处理子进程的生命周期管理（避免僵尸进程）、进程间通信、资源共享（数据库连接等）以及错误处理。如果处理不当，容易引入新的问题，我个人不推荐在Workerman的定时器中滥用此方法，除非你对进程管理有非常深入的理解。

在我看来，对于大多数场景，任务拆分、Task Worker和消息队列是更安全、更推荐的解决方案。它们能有效避免Workerman主进程的阻塞，同时提供良好的可扩展性和稳定性。

Workerman定时任务如何实现持久化和高可用？

Workerman的

Timer

类默认是内存级别的，这意味着一旦Workerman进程重启，所有通过

Timer::add()

注册的定时任务都会丢失。这在生产环境中是不可接受的，因为我们希望定时任务能够稳定、不间断地运行，即使服务重启也能恢复。同时，为了应对单点故障，实现高可用也是必不可少的。

要解决这两个问题，我们需要跳出Workerman进程本身，引入外部存储和分布式协调机制。

1. 持久化定时任务：

核心思想是：将定时任务的配置信息存储在外部，并在Workerman启动时重新加载和注册。

  • 存储介质：
    • 数据库： 最常见的选择。你可以创建一个表来存储定时任务的ID、执行间隔、回调函数名（或类名方法名）、参数、上次执行时间、下次执行时间、是否启用等信息。
    • Redis： 适合存储一些简单的、需要快速读写的定时任务配置。可以使用哈希表或JSON字符串来存储任务详情。
    • 配置文件： 对于少量、不经常变化的定时任务，也可以直接写入配置文件。
  • 加载与注册：
    • 在Workerman的 
      onWorkerStart

      回调中，从数据库或Redis中读取所有已启用的定时任务配置。

    • 遍历这些配置，为每个任务调用 
      Timer::add()

      方法进行注册。

  • 状态管理： 对于需要跟踪进度的任务（比如上面提到的分批处理），也需要将任务的当前状态（如已处理的偏移量）持久化到数据库或Redis中。这样即使进程重启，任务也能从上次中断的地方继续。

示例（概念性代码）：

// 假设有一个函数从数据库加载任务 function loadScheduledTasksFromDB() {     // 模拟从数据库加载任务列表     return [         ['interval' => 10, 'callback' => 'AppTasksCleanCache::run', 'args' => [], 'persistent' => true],         ['interval' => 300, 'callback' => 'AppTasksGenerateReport::run', 'args' => ['type' => 'daily'], 'persistent' => true],     ]; }  $worker = new Worker(); $worker->onWorkerStart = function($worker) {     $tasks = loadScheduledTasksFromDB();     foreach ($tasks as $taskConfig) {         $callback = $taskConfig['callback'];         // 这里需要动态解析回调函数，例如通过反射或简单的类方法调用         $callable = function() use ($callback, $taskConfig) {             list($className, $methodName) = explode('::', $callback);             (new $className())->$methodName(...$taskConfig['args']);         };         Timer::add($taskConfig['interval'], $callable, [], $taskConfig['persistent']);         echo "从数据库注册了任务: " . $callback . " ";     } };

2. 实现高可用（避免重复执行与单点故障）：

当你有多个Workerman进程（甚至多个服务器上的Workerman实例）都在运行相同的定时任务时，就可能出现重复执行的问题。高可用性要求即使某个进程或服务器挂掉，任务也能被其他健康的实例接管。

  • 分布式锁（Distributed Lock）： 这是解决重复执行问题的核心手段。在每个定时任务的回调函数中，在执行实际业务逻辑之前，尝试获取一个分布式锁（例如，使用Redis的 
    SETNX

    命令，或者ZooKeeper、etcd等）。

    • 如果成功获取锁，则执行任务，并在任务完成后释放锁。
    • 如果未能获取锁，说明其他实例正在执行该任务，当前实例就跳过本次执行。
    • 锁应该设置一个合理的过期时间（TTL），防止因任务崩溃导致死锁。

示例（Redis分布式锁）：

use WorkermanLibTimer; use Redis; // 假设你已经配置好了 Redis 客户端  $redis = new Redis(); $redis->connect('127.0.0.1', 6379);  // ... 在 Worker::onWorkerStart 中注册定时器 Timer::add(60, function() use ($redis) {     $lockKey = 'lock:task:generate_report';     $lockValue = uniqid(); // 唯一的锁值，用于防止误删     $expireTime = 55; // 锁的过期时间，略小于定时器间隔      // 尝试获取锁：SET lock_key unique_value NX EX expire_time     if ($redis->set($lockKey, $lockValue, ['nx', 'ex' => $expireTime])) {         echo "成功获取锁，开始执行报告生成任务... ";         try {             // 这里执行实际的耗时任务             // generateDailyReport();             sleep(10); // 模拟任务执行             echo "报告生成任务完成。 ";         } catch (Exception $e) {             echo "任务执行失败: " . $e->getMessage() . " ";         } finally {             // 确保只有自己设置的锁才能被自己释放             if ($redis->get($lockKey) === $lockValue) {                 $redis->del($lockKey);                 echo "锁已释放。 ";             }         }     } else {         echo "未能获取锁，任务已被其他实例执行或正在执行中。 ";     } });
  • **集中式调度

以上就是Workerman如何实现定时器？Workerman定时任务怎么写？的详细内容，更多请关注php linux redis js json app 工具 ai workerman 区别 api调用 php脚本 php rabbitmq 分布式 json kafka Float Array 全局变量 回调函数 字符串 bool int 循环 委托 线程 并发 事件 异步 redis zookeeper etcd 数据库 linux Workerman

php linux redis js json app 工具 ai workerman 区别 api调用 php脚本 php rabbitmq 分布式 json kafka Float Array 全局变量 回调函数 字符串 bool int 循环 委托 线程 并发 事件 异步 redis zookeeper etcd 数据库 linux Workerman

事件
上一篇
下一篇

推荐文章

如何通过JavaScript实现图片预览功能？
在 React 中加载第三方脚本并在加载后调用其函数
PostgreSQL连续登录查询怎么写_PostgreSQL连续登录SQL实现方案
XML格式的证券交易数据标准
HTML文档主体怎么定义_HTMLbody标签使用教程
如何用WebVTT实现自定义的视频字幕系统？
composer如何创建自己的包_创建并发布一个Composer包到Packagist的流程
HTML与AJAX交互：实现异步数据加载的详细步骤
如何用JavaScript实现一个支持多端同步的笔记应用？
Composer如何自定义命令脚本_在composer.json中创建快捷指令