# Çalışanlar

Çalışanlar, bekleyen işleri veritabanında yoklayan, bunları yürüten ve iş akışlarını ilerleten uzun süre çalışan süreçlerdir. `wp queuety work` komutu WP-CLI içinde çalışırken kuyruk doğrudan MySQL üzerinden, kullanılabilir en iyi Queuety DB sürücüsüyle alınır.

Eklenti ayrıca kabuk erişimi olmayan ortamlar için dakikada bir çalışan varsayılan bir WordPress cron geri dönüş seçeneği kurar. Bu sayfada, daha yüksek verim için önerilen dağıtım modu olan özel WP-CLI çalışanları ele alınır.

## Çalışan başlatma

```bash
wp queuety work
```

Bu, `default` kuyruğunda tek bir çalışan başlatır. Döngü halinde çalışır: bir iş alır, yürütür ve yineler. Kuyruk boş olduğunda, yeniden yoklamadan önce `QUEUETY_WORKER_SLEEP` saniye (varsayılan: 1) bekler.

### Seçenekler

| Seçenek | Açıklama |
|---|---|
| `--queue=<queue>` | İşlenecek Queue(s); öncelik sıralaması için virgülle ayrılır (varsayılan: `default`) |
| `--once` | En fazla bir işi işleyip çıkar |
| `--workers=<n>` | N çalışan süreci çatallar (`pcntl` ve `posix` uzantılarını gerektirir) |
| `--min-workers=<n>` | Uyarlanabilir havuz için minimum çalışan sayısı. `--max-workers` gerektirir |
| `--max-workers=<n>` | Uyarlanabilir havuz için maksimum çalışan sayısı |

```bash
# Process a specific queue
wp queuety work --queue=emails

# Process at most one job and exit
wp queuety work --once

# Run 4 concurrent workers
wp queuety work --workers=4

# Scale between 2 and 6 workers as backlog changes
wp queuety work --queue=providers --min-workers=2 --max-workers=6
```

## Çoklu kuyruk öncelikleri

Tek bir çalışan, birden fazla kuyruğu öncelik sırasına göre işleyebilir. `--queue` seçeneğine virgülle ayrılmış kuyruk adları listesi verin:

```bash
wp queuety work --queue=critical,default,low
```

Çalışan, listelenen sırayla her kuyruktan bir iş almaya çalışır. Önce `critical` kuyruğunu kontrol eder. `critical` kuyruğunda iş varsa bu işi işler. `critical` kuyruğu boşsa `default` kuyruğuna, ardından `low` kuyruğuna geçer. Böylece yüksek öncelikli kuyruklar, düşük önceliklilerden önce tamamen boşalır.

### Öncelik sıralaması nasıl çalışır

Her yinelemede çalışan, listedeki ilk kuyruktan bir iş almaya çalışır. Bu kuyruk boşsa veya duraklatılmışsa bir sonrakine geçer ve bir iş bulana ya da listeyi tüketene kadar devam eder. Hiçbir yerde iş bulamazsa bekleyip yeniden dener. Bu katı bir öncelik modelidir; dolayısıyla sürekli gelen `critical` işleri, `default` ve `low` kuyruklarındaki işleri bekletebilir. Düşük öncelikli kuyrukların garantili bir işlem hacmine ihtiyacı varsa bunun yerine özel çalışanlar kullanın.

### PHP içinde çoklu kuyruk kullanımı

`Worker::run()` ve `Worker::flush()` yöntemleri bir dizeyi veya diziyi kabul eder:

```php
// Comma-separated string
Queuety::worker()->run( 'critical,default,low' );

// Array
Queuety::worker()->run( [ 'critical', 'default', 'low' ] );

// flush() also supports multi-queue
$count = Queuety::worker()->flush( 'critical,default,low' );
```

### Dağıtım stratejileri

**Her kuyruk için ayrılmış çalışanlar**, eşzamanlılık ve yalıtım üzerinde tam denetim sağlar. Her kuyruğun kendine ait bir çalışan process(es) vardır ve diğer kuyruklar yüzünden beklemez:

```ini
[program:queuety-critical]
command=wp queuety work --queue=critical
numprocs=4

[program:queuety-default]
command=wp queuety work --queue=default
numprocs=2

[program:queuety-low]
command=wp queuety work --queue=low
numprocs=1
```

**Tek çalışanla öncelik sıralaması** yönetimi kolaylaştırır ve düşük öncelikli kuyrukların gecikmeyi tolere edebildiği durumlarda iyi çalışır:

```ini
[program:queuety-worker]
command=wp queuety work --queue=critical,default,low
numprocs=2
```

İki yaklaşımı birleştirebilirsiniz: işlem hacmini garanti etmek için `critical` için ayrılmış çalışanlar, geri kalan her şey için öncelik sıralı bir çalışan kullanın:

```ini
[program:queuety-critical]
command=wp queuety work --queue=critical
numprocs=2

[program:queuety-fallback]
command=wp queuety work --queue=default,low
numprocs=2
```

## Kaynak farkındalıklı kabul

Çalışanlar yalnızca bekleyen sıradaki satırı almakla kalmaz. Alınan bir iş başlamadan önce Queuety, işin eşzamanlılık grubuna ve bu işleyicinin yakın tarihli yürütme profiline dayalı genel kabul denetimleri uygulayabilir.

Daha kapsamlı modelin ve bunun iş meta verileriyle iş akışı bütçeleriyle nasıl bir araya geldiğinin açıklaması için [Kaynak Yönetimi](https://queuety.inline0.dev/tr/docs/features/resource-management) sayfasına bakın.

Eşzamanlılık grubu, birkaç işleyici veya iş sınıfı için ortak bir üst sınır belirler. Pahalı birkaç sağlayıcıyı aynı grup ve sınıra bağlarsanız grup kapasitesi dolduğunda çalışan, yeni alınan işleri başlatmak yerine kuyruğa geri bırakır. Böylece birden fazla boşta çalışan olması, bağımsız kuyrukların aynı alt sistemi birden fazla istekle bunaltmasını önler.

Yakın tarihli yürütme günlükleri basit bir kabul profilini de besler. Kaynak kabulü etkinleştirildiğinde Queuety, çalıştırmak üzere olduğu işleyicinin yakın tarihli ortalama süresine ve en yüksek bellek kullanımına bakar. Mevcut çalışan yapılandırılmış bellek sınırına yaklaştıysa, bir kuyruk veya sağlayıcı grubu ağırlıklı bütçesine ulaştıysa, mevcut kapsayıcıda işleyicinin gözlemlenen profili için yeterli kullanılabilir bellek görünmüyorsa ya da `--once` tarzı bir çalıştırma zaman sınırına yaklaştıysa Queuety, sorunsuz tamamlanması olası görünmeyen işi başlatmak yerine erteler.

İlkeyi çalışan komutundan değil, iş tanımından etkinleştirirsiniz:

```php
class CallProviderStep implements \Queuety\Step {
    public function handle( array $state ): array {
        // ...
    }

    public function config(): array {
        return [
            'concurrency_group' => 'providers',
            'concurrency_limit' => 3,
            'cost_units' => 5,
        ];
    }
}
```

Aynı meta veriler, herkese açık özellikleri olan dağıtılabilir iş sınıflarına veya `PendingJob::concurrency_group()` ve `PendingJob::cost_units()` aracılığıyla tek bir dağıtıma eklenebilir.

Çalışan tarafındaki kabul profili şu sabitlerle denetlenir:

| Sabit | Açıklama |
|---|---|
| `QUEUETY_RESOURCE_ADMISSION` | Profil tabanlı kabul denetimlerini etkinleştirir veya devre dışı bırakır |
| `QUEUETY_RESOURCE_PROFILE_WINDOW_MINUTES` | Yakın tarihli işleyici profillerini oluştururken geriye dönük incelenecek süre |
| `QUEUETY_RESOURCE_PROFILE_TTL` | Yakın tarihli işleyici profillerinin önbellek TTL değeri |
| `QUEUETY_RESOURCE_MEMORY_HEADROOM_MB` | Yeni bir işi kabul etmeden önce ayrılan bellek payı |
| `QUEUETY_RESOURCE_SYSTEM_MEMORY_AWARENESS` | Kapsayıcı veya ana makine belleği için en iyi çabaya dayalı denetimleri etkinleştirir veya devre dışı bırakır |
| `QUEUETY_RESOURCE_SYSTEM_MEMORY_HEADROOM_MB` | Yeni bir işi kabul etmeden önce ayrılan sistem belleği payı |
| `QUEUETY_RESOURCE_QUEUE_COST_BUDGETS` | Kuyruk adına göre anahtarlanan ağırlıklı maliyet bütçeleri |
| `QUEUETY_RESOURCE_GROUP_COST_BUDGETS` | `concurrency_group` anahtarına göre anahtarlanan ağırlıklı maliyet bütçeleri |
| `QUEUETY_RESOURCE_TIME_HEADROOM_MS` | Tek seferlik çalışan çalıştırmaları için ayrılan süre payı |

## Çalışan yaşam döngüsü

Aşağıdaki koşullardan herhangi biri karşılandığında çalışan, o anki işini bitirdikten sonra düzgün biçimde durur:

| Koşul | Yapılandırma |
|---|---|
| İşlenen maksimum iş sayısı | `QUEUETY_WORKER_MAX_JOBS` (varsayılan: 1000) |
| Maksimum bellek aşımı | `QUEUETY_WORKER_MAX_MEMORY` (varsayılan: 128 MB) |

Durduktan sonra çalışan sorunsuz biçimde çıkar. Üretimde bir süreç yöneticisi onu otomatik olarak yeniden başlatır.

Sinyaller henüz düzgün biçimde işlenmiyor ([#4](https://github.com/inline0/queuety/issues/4)). Tek bir `wp queuety work` süreci herhangi bir sinyal işleyicisi kurmaz; bu nedenle `SIGTERM` veya `SIGINT` (Ctrl+C), işin ortasında bile süreci hemen sonlandırır. İş, eski iş kurtarma işlemi `QUEUETY_STALE_TIMEOUT` saniye sonra durumu sıfırlayana kadar `processing` durumunda kalır; bu yüzden işleyicilerin yeniden denenmeye uygun olmasını sağlayın. Çalışan havuzu `SIGTERM` sinyalini alt süreçlerine iletir, ancak alt süreçler buna tepki vermez. Bu nedenle havuz, yukarıdaki nedenlerden biriyle durana kadar çalışmayı sürdürür. Bir havuzu durdurmanız gerektiğinde süreç yöneticiniz için, ardından `SIGKILL` sinyalini göndereceği bir durdurma zaman aşımı belirleyin.

## Çok çalışanlı eşzamanlılık

`--workers=N` bayrağı, `pcntl_fork()` kullanarak N alt süreç çatallar. Her alt süreç kendi veritabanı bağlantısını oluşturur ve işleri bağımsız olarak işler. Üst süreç alt süreçleri izler ve çökenleri yeniden başlatır.

```bash
wp queuety work --queue=default --workers=4
```

Gereksinimler:
`pcntl` ve `posix` PHP uzantıları kurulu olmalıdır (`pcntl` olmadan komut "pcntl extension is required for --workers=N." hatasıyla başarısız olur). Her alt süreç kendi veritabanı bağlantısını kullandığından MySQL `max_connections` ayarınızın havuz için yeterli olması gerekir. Uyarlanabilir havuzlar (`--min-workers`/`--max-workers`) da aynı gereksinimlere sahiptir.

## Uyarlanabilir çalışan havuzları

Uyarlanabilir havuzlar, en az sayıda çalışanı hazır tutar ve ardından yapılandırılmış aralık içinde büyüyüp küçülür:

```bash
wp queuety work --queue=providers --min-workers=2 --max-workers=6
```

Üst süreç, seçili kuyruk kümesinde iş alınabilir durumdaki birikimi izler ve yapılandırılmış üst sınırı aşmadan alt süreç sayısını bu birikime göre ayarlar. Kuyruk sakinleştiğinde havuz küçülmeden önce boşta kalma tolerans süresinin dolmasını bekler. Böylece kısa süreli yoğunluklar süreç listesinin hemen değişmesine yol açmaz.

Ölçek artırımı yine temkinlidir. Queuety, kapsayıcı veya ana makine bellek ölçümlerini okuyabildiğinde, başka bir tam çalışan için yeterli kullanılabilir bellek yoksa yeni alt süreç eklemeyi reddeder.

Üst süreç tarafındaki ölçeklendirme döngüsü şu sabitlerle denetlenir:

| Sabit | Açıklama |
|---|---|
| `QUEUETY_WORKER_POOL_SCALE_INTERVAL` | Üst sürecin havuz boyutunu ne sıklıkla uzlaştıracağı |
| `QUEUETY_WORKER_POOL_IDLE_GRACE` | Ölçek küçültmeden önce birikimin ne kadar süre sakin kalması gerektiği |

## Eski iş kurtarma

Bir çalışan bir işi işlerken çökerse iş, `processing` durumunda kalır. Uzun süre çalışan bir çalışan, `processing` durumunda `QUEUETY_STALE_TIMEOUT` saniyeden uzun süredir bulunan işleri yaklaşık dakikada bir kontrol eder. Deneme hakkı kalan eski bir iş, yeniden deneme gecikmesinden sonra tekrar denenir; tüm deneme hakları tükenmiş olan ise kuyruğun en arkasına atılır ve iş akışı başarısız olarak işaretlenir. `--once` çalışanları ve WP-Cron geri dönüş seçeneği bu denetimi çalıştırmaz.

Eski işleri elle kurtarın:

```bash
wp queuety recover
```

## Boşaltma modu

Bekleyen tüm işleri işleyip çıkın. Testler veya tek seferlik toplu işlemler için kullanışlıdır:

```bash
wp queuety flush
wp queuety flush --queue=emails
```

## Üretim dağıtımı

Üretimde çalışanları çalışır durumda tutmak için bir süreç yöneticisi kullanın. İşte yaygın iki yaklaşım.

### Supervisord

```ini
[program:queuety-default]
command=wp queuety work --queue=default
directory=/var/www/html
autostart=true
autorestart=true
numprocs=2
process_name=%(program_name)s_%(process_num)02d
stdout_logfile=/var/log/queuety-default.log
stderr_logfile=/var/log/queuety-default-error.log

[program:queuety-emails]
command=wp queuety work --queue=emails
directory=/var/www/html
autostart=true
autorestart=true
numprocs=1
stdout_logfile=/var/log/queuety-emails.log
stderr_logfile=/var/log/queuety-emails-error.log
```

### Systemd

```ini
[Unit]
Description=Queuety Worker (default queue)
After=mysql.service

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/html
ExecStart=/usr/local/bin/wp queuety work --queue=default
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
```

Etkinleştirip başlatın:

```bash
sudo systemctl enable queuety-worker
sudo systemctl start queuety-worker
```

### Dağıtım ipuçları

Daha güçlü bir yalıtım gerektiğinde her kuyruk için ayrı çalışanlar çalıştırın. İş yükü CPU ağırlıklıysa `--workers=N` kullanın; iş yükü çoğunlukla G/Ç ağırlıklıysa ayrı ayrı denetlenen çalışanları tercih edin. Belleği boşaltmak için düzenli yeniden başlatma istiyorsanız `QUEUETY_WORKER_MAX_JOBS` değerini ayarlayın ve `buried` sayısını [webhook'lar](https://queuety.inline0.dev/tr/docs/features/webhooks) veya [metrikler](https://queuety.inline0.dev/tr/docs/features/metrics) aracılığıyla izleyin.