Teknik Rehber · Veritabanları
Transaction Isolation: Lost Update, Write Skew ve Retry Tasarımı
Isolation, eşzamanlı işlemlerin birbirinin ara veya tamamlanmış etkilerini nasıl gördüğünü belirler. Aynı isolation adı farklı veritabanlarında aynı uygulama davranışını garanti etmez.…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Isolation, eşzamanlı işlemlerin birbirinin ara veya tamamlanmış etkilerini nasıl gördüğünü belirler. Aynı isolation adı farklı veritabanlarında aynı uygulama davranışını garanti etmez. PostgreSQL Read Committed her statement için snapshot kullanır; Repeatable Read ve Serializable farklı tutarlılık koşulları sunar.
Lost update, uygulamanın eski okunan değere göre yeni değeri yazmasıyla oluşabilir. Atomic UPDATE veya uygun kilit uygulama koşuluna göre çözüm olabilir. Write skew iki işlemin ayrı satırları değiştirip birlikte bir iş kuralını bozmasıdır; sadece tek satır kilidi bütün kuralları korumaz.
Serializable işlem serialization failure ile geri dönebilir; uygulama tüm transaction’ı kontrollü yeniden denemelidir. Retry sırasında dış servise ödeme veya mail gibi yan etkileri tekrarlamayın; idempotency anahtarı veya outbox tasarımı gerekir. Daha yüksek isolation gereksiz uzun transaction’ı düzeltmez.
- 1İş kuralı
- 2Eşzamanlı transaction
- 3Isolation/kilit kararı
- 4Commit veya bounded retry
Tasarım parametreleri
- İş kuralı
- Örneğin stok negatif olamaz veya en az bir nöbetçi kalmalı kuralını açık yazın.
- Retry bütçesi
- Serialization/deadlock için sınırlı deneme, jitter ve hata raporu tanımlayın.
- İşlem süresi
- Kullanıcı yanıtı veya uzak API beklerken DB transaction’ını açık bırakmayın.
Hesap ve uygulama örneği
Stok 5 iken iki istek dörder adet istesin. “SELECT ardından stok=1 yaz” yaklaşımı ikisini de kabul edebilir. UPDATE inventory SET qty=qty-4 WHERE id=1 AND qty>=4 tek atomik koşuldur; etkilenen satır sayısı 0 ise stok yetersizliğini uygulamada işleyin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
BEGIN;
UPDATE inventory SET qty = qty - 4 WHERE id = 1 AND qty >= 4;
-- Application checks affected-row count before COMMIT.
COMMIT;
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Bakiye beklenenden farklı | Eski okuma ile overwrite. | İki oturumlu aynı senaryoyu tekrar üretin. |
| 40001 hatası | Serialization conflict. | Tüm transaction’ı idempotent bounded retry ile tekrar edin. |
Kabul ve doğrulama kontrolleri
- İş kuralını yazın.
- İki oturumla yarışı üretin.
- Atomic update sonucunu kontrol edin.
- Retry yan etkilerini ayırın.
- Uzun transaction’ı azaltın.
- Isolation davranışını motor sürümünde doğrulayın.
İlgili kavramlar
Transaction sınırı
Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Kilit, bekleme ve deadlock
Eşzamanlı işlemler veri bütünlüğü için kilit veya sürümleme mekanizmaları kullanır. Uzun açık transaction, diğer işleri bekletebilir; deadlock ise birbirini bekleyen işlemler arasındaki döngüdür. Ürün bazı işlemlerden birini sonlandırabilir ve uygulamanın güvenli tekrar deneme yapması gerekebilir. Bekleyen sorgu ile onu bloke eden sorguyu birlikte inceleyin. İzolasyon seviyesini rastgele düşürmek veri tutarlılığını değiştirebilir. Transaction süresini kısaltma, tutarlı erişim sırası ve uygun indeks gibi seçenekleri aynı iş yükünde doğrulayın.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
İzolasyon ile sanallaştırma ayrımı
Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.