Yoğun Saatlerde Bilet Doğrulama: Tek Kullanımlık Biletler İçin Veritabanı Tasarımı
Mehmet Fatih İçin · · 6 dk okuma
Bir biletleme sisteminin en zor anı sıradan bir salı günü değil, bayramın ilk günü sabah açılış saatidir. Gişeler, internet satışı, el terminalleri ve turnikeler aynı veritabanına aynı anda yüklenir. Bu yazıda, yüksek eşzamanlılık altında tek kullanımlık biletlerin hem hızlı hem tutarlı doğrulanması için kullandığım veritabanı ilkelerini paylaşıyorum.
1. Doğrulama sorgusu tek satıra dokunmalı
Doğrulama anında yapılan iş “bu bilet var mı, kullanılmış mı?” sorusudur. Sorgu, bilet kodu üzerindeki benzersiz bir indeksle tek satıra gitmeli; tarih aralığı taraması, metin araması ya da büyük tablolarla birleştirme bu yolda olmamalıdır. Raporlama ihtiyaçları ayrı tablolara ya da ayrı bir okuma veritabanına taşınır.
2. “Oku, sonra güncelle” yerine tek atomik güncelleme
Önce bileti okuyup sonra “kullanıldı” olarak güncellemek, iki kapının aynı anda aynı bileti geçirmesine yol açabilir. Bunun yerine durumu koşullu tek bir güncellemeyle değiştirmek gerekir: UPDATE ... SET durum = 'kullanildi' WHERE kod = @kod AND durum = 'gecerli'. Etkilenen satır sayısı 1 ise geçiş onaylanır, 0 ise bilet zaten kullanılmıştır. Ek kilit mekanizmasına gerek kalmadan yarış durumu ortadan kalkar.
3. Kilit süresini kısa tut
Transaction içinde ağ çağrısı, dosya işlemi ya da başka bir servisi beklemek kilitleri uzatır ve kuyruk oluşturur. Transaction yalnızca veritabanı işini kapsamalı; turnike rölesini tetiklemek, bildirim göndermek gibi işler transaction bittikten sonra yapılmalıdır.
4. Okuma yükünü ayır
Anlık ziyaretçi sayısı, satış panoları ve yönetim raporları aynı tablolara sürekli okuma yaparsa doğrulama sorgularıyla yarışır. Satır sürümlemeye dayalı izolasyon (SQL Server'da read committed snapshot) okuyucuların yazanları beklemesini önler. Ağır raporlar için özet tablolar ya da ayrı bir raporlama veritabanı daha da iyidir.
5. Önceden ısıt, ölç, sınırla
Yoğun günden önce sık kullanılan indekslerin ve sorgu planlarının hazır olduğundan emin olmak, ilk dakikalardaki yavaşlığı azaltır. Bekleme türlerini (wait stats) izlemek darboğazın kilit mi, disk mi, işlemci mi olduğunu gösterir. Son olarak, istemci tarafında akıllı tekrar deneme ve sunucu tarafında oran sınırlama, ani yük dalgalarının sistemi devirmesini önler.
Özet
- Doğrulama yolunu tek satıra, benzersiz indekse indir.
- Durum değişikliğini koşullu tek bir UPDATE ile yap.
- Transaction içinde dış servis bekleme.
- Okuma ve raporlama yükünü ayır.
- Yoğunluktan önce ölç ve hazırla.
Yavaş sorguları bulmak için SQL Server yavaş sorgu analizi yazısına, bu ilkelerin uygulandığı sistem için merkezi e-bilet ve gişe vaka çalışmasına göz atabilirsin.