Postgres FOR UPDATE SKIP LOCKED: Kuyruk Sisteminin Sınırları

Postgres'te görev kuyruğu oluştururken çoğu geliştirici FOR UPDATE SKIP LOCKED kullanıyor. Komut, kilitli satırları atlayıp diğer işçilerin (worker) aynı kaydı işlemesini engellediği için pratik görünüyor. Ama bu yaklaşım ne kadar ölçeklenebilir?

Bir yazılımcı, bu tekniği yoğun trafikte test ettiğinde ilginç sorunlarla karşılaştı. Kuyruk işleri hızlı işlendiğinde başta iyi çalışan sistem, belirli bir noktada performans düşüşü yaşamaya başlıyor. Nedeni basit: her işçi sürekli veritabanını sorguluyor, SKIP LOCKED ile uygun kayıtları arıyor ve bu da CPU ile I/O yükünü artırıyor.

Asıl sorun ise kilitleme stratejisinde ortaya çıkıyor. Çok sayıda işçi aynı anda SKIP LOCKED kullandığında, veritabanı kilitli satırları kontrol etmek için fazla kaynak harcıyor. Basit bir kuyruk için belki sorun değil, ama saniyede binlerce iş işleyen bir sistemde bu ciddi bir병목(병목) olabilir.

Yaşanan diğer sorunlar arasında:

- Ölü görevler: Hata alan işler tekrar kuyruğa giriyor, sonsuza dek dönüp duruyor
- İş sırası garantisi yok: SKIP LOCKED rastgele sırada işlem yapıyor
- Basit kullanım dışında ölçeklenemiyor: Milyonlarca iş varsa çöküyor

Bu bulguların ardından geliştirici, Redis, RabbitMQ gibi özel kuyruk sistemlerine yönelmenin daha mantıklı olduğunu belirtiyor. Postgres harika bir veritabanı ama her problem için ideal değil. Küçük uygulamalar için FOR UPDATE SKIP LOCKED işe yarar, ama büyük sistemlerde başka çözümleri değerlendirmek gerekiyor.