İçeriğe geç

Tek Başına Kullanım

Queuety bir WordPress eklentisi olarak paketlenmiştir, ancak çalışma zamanının büyük bölümü canlı bir WordPress isteğine gerek duymaz.

Kuyruk, iş akışı altyapısı, durum makineleri, sinyaller, yapıtlar, toplu işlemler, zamanlama, günlükleme, ölçümler ve kaynak yönetimi aynı MySQL tabloları üzerinde çalışır. Başka bir PHP süreci aynı veritabanını açabiliyorsa çekirdeği doğrudan kullanabilir.

Bu, Queuety içindeki tek başına kullanım sınırıdır. Veritabanı destekli orkestrasyon altyapısı WordPress dışında kullanılabilir. WordPress köprüleri ise WordPress içinde kalır.

WordPress dışında çalışanlar

Doğrudan bir Connection ile tek başına çalışan bir süreç Queuety'i başlatabilir ve eklentinin temel çalışma zamanı için kullandığı aynı arayüz yöntemlerini kullanabilir:

  • iş dağıtma
  • çalışanları ve çalışan havuzlarını çalıştırma
  • iş akışları oluşturma ve dağıtma
  • sinyal, onay ve iş akışı girdisi gönderme
  • durum makineleri oluşturma ve dağıtma
  • iş akışı ve makine durumunu inceleme
  • yapıtları saklama ve okuma
  • toplu işlemleri, zincirlemeyi ve yinelenen zamanlamaları yürütme
  • günlükleri, ölçümleri, kuyrukları ve çalışma zamanı durumunu sorgulama

Böylece harici bir ürün, aynı veritabanını ve tablo adlarını kullandığı sürece önce WordPress'i başlatmadan aynı orkestrasyon durumuna erişebilir.

Çalışan havuzları şu an için tek istisnadır: Queuety::run_worker_pool() ve Queuety::run_auto_scaling_worker_pool(), başlatılmış bağlantı yerine WordPress DB_HOST, DB_NAME, DB_USER ve DB_PASSWORD sabitlerini okur. Bu nedenle tek başına çalışan bir süreç havuzu başlatmadan önce bu sabitleri tanımlamalıdır (#5).

WordPress içinde kalanlar

WordPress'e özgü köprü katmanı, WordPress'in yüklenmiş olmasına bağlıdır.

Bunlara şunlar dahildir:

  • queuety.php içindeki eklenti önyüklemesi ve etkinleştirme davranışı
  • Queuety::on_action(); add_action() gerektirir
  • Queuety::replace_wp_cron() ve Queuety::restore_wp_cron(); WordPress cron filtrelerine ve do_action()'e bağlıdır
  • gerçek wp queuety ... komut kayıt yolu; WP-CLI'in WordPress yüklemesine bağlıdır

Bu parçalar, temel çalışma zamanı çevresindeki bağdaştırıcılardır. Çalışma zamanının kendisi değildirler.

Başlatma

Tek başına kullanım yolu özellikle basit tutulmuştur. Veritabanı destekli bir Connection açın, arayüzü başlatın ve şemanın mevcut olduğundan emin olun.

PHP
use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();

Bundan sonra normal çalışma zamanı API kullanılabilir:

PHP
Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();

Tablo Adlandırma

Tek başına kullanımda özellikle WordPress tablo adlarının kullanılması gerekmez. Yalnızca kararlı bir önek stratejisi gerekir.

Queuety'i bir WordPress veritabanına yönlendiriyorsanız eklentinin orada kullandığı önekin aynısını kullanın. Ayrı bir veritabanında Queuety kullanıyorsanız bağlantı öneki, ana uygulamanızın beklentilerine göre belirlenebilir. Queuety'e özgü tablo bölümü yine QUEUETY_TABLE_PREFIX ve tablo başına geçersiz kılmalarla denetlenir.

Tek bir veritabanını paylaşan gömülü çalışma zamanları, bağlantı başına bu Queuety'e özgü bölümü ayarlayabilir:

PHP
$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);

Böylece WordPress veritabanı öneki değişmeden kalır ve queuety_jobs gibi tablolar wp_themequeue_jobs olarak çözümlenir.

Kavramsal Model

Bu ayrımı düşünmenin en yalın yolu şudur:

  • Queuety çekirdeği = kuyruk, çalışanlar, iş akışları, durum makineleri, sinyaller, yapıtlar ve çalışma zamanı meta verileri
  • WordPress bağdaştırıcısı = eklenti önyüklemesi, kanca köprüleri, WP-Cron değişimi ve WP-CLI kaydı

Böylece tek bir orkestrasyon altyapısı korunurken WordPress'e özgü olay ve istek bütünleştirmesi ait olduğu yerde kalır.