Migration ve kayıt saklama · Consumer

Inbox/outbox şemasını açıkça kurun, startup preflight ve bounded cleanup davranışını ayırın.

Lily, normal Consumer startup’ında inbox/outbox tablolarını veya collection’larını oluşturmaz. Migration deployment’ın açık bir adımıdır; startup, önceden kurduğunuz storage sözleşmesini read-only kontrol eder. Böylece yeni bir binary çalıştırmak sessiz schema değişikliğine dönüşmez.

Deployment sırası#

Seçilen DB veya factory cell için bağlantı yapılandırmasını ve secrets resolver’ı hazırlayın.
Uygulamanın iş tablolarını/collection’larını kendi migration aracınızla kurun.
Aynı DI veritabanı otoritesiyle Lily component migrator’ını çalıştırın.
Migration komutunun container’ını kapatın; başarıdan sonra Consumer’ı başlatın.
Startup preflight sonucunu ve readiness’i izleyin.

Tam PostgreSQL ve MongoDB örnekleri, migrate(&ApplicationContainer) fonksiyonunu içerir. Bu fonksiyonlar derlenebilir migration body’leridir; config yükleyen, container kuran ve kapanışını yöneten bağımsız executable değildir. Deployment komutunuz bu çevreyi sağlamalıdır. Transactional migration yalnız framework storage’ını kurar; örnekteki orders iş tablosunu otomatik oluşturmaz.

Backend’lerin kurduğu storage#

Backend	Public migration API	Sahip olunan alan
PostgreSQL	`PostgresInboxOutboxMigrator::new(database).migrate().await`	`lily_queue` schema’sı; component version 1 ve migration advisory lock
MongoDB	`MongoInboxOutboxMigrator::new(database)?.apply(&operation).await`	`_lily_queue_transactional_schema`, `_lily_queue_inbox`, `_lily_queue_inbox_leases`, `_lily_queue_outbox`

Preflight yalnız version numarasını karşılaştırmaz. PostgreSQL gerçek schema, constraint ve index sözleşmesini; MongoDB marker, fingerprint, validator ve index sözleşmesini de kontrol eder. MongoDB’de deployment’ın transaction desteği ayrıca doğrulanır. Marker’ı elle güncellemek veya gereken index’i kaldırmak uyumlu migration sayılmaz.

Saklama ve cleanup politikası#

[rabbitmq.topology.queues.transactional_inbox]
backend = "postgresql"
inbox_retention_secs = 604800
outbox_retention_secs = 604800
cleanup_interval_secs = 3600

Bu tablo mevcut queue’nun binding’ini gösterir; aynı tabloyu dosyaya ikinci kez eklemeyin. MongoDB için backend’i değiştirin, factory için database_cell ekleyin. Retention değerleri varsayılan olarak 7 gün, cleanup aralığı 1 saattir. Cleanup aralığı iki retention süresinden de uzun olamaz.

Cleanup sınırlı batch’lerle tamamlanmış inbox ve delivered outbox kayıtlarını temizler. MongoDB ayrıca süresi bitmiş lease kayıtlarını ele alır. Henüz yayınlanmamış outbox kayıtları retention süresi doldu diye sessizce atılmaz. CleanupReport temizliğin gözlemidir; bütün uygulama olaylarının eksiksiz audit defteri değildir.

Replay penceresini retention ile tasarlayın#

Inbox kaydı temizlendikten sonra aynı handler/event anahtarı yeni işlem gibi kabul edilebilir. Broker redelivery, manuel replay ve uzak servis retry pencereleri retention kararına dahildir. Uzun süreli iş idempotency’si gerekiyorsa bunu iş verisindeki unique constraint veya idempotency kaydıyla ayrıca kurun; kısa inbox retention’ını kalıcı exactly-once garantisi olarak kullanmayın.

Aynı DB cell’ini kullanan queue’larda retention ve cleanup dahil bütün transactional policy eşit olmalıdır. Farklı saklama gereksinimleri varsa ayrı storage otoritesi/cell tasarımını değerlendirin. Retention’ı değiştirirken mevcut inbox geçmişinin ne zaman silineceğini ve eski event’lerin tekrar işlenip işlenemeyeceğini deployment kararına dahil edin.