Veritabanı transaction tasarımı: Eşzamanlı işlemlerde tutarlılık
· PoolByte Technology
Bir sipariş kaydı oluşup satırları oluşmazsa veya bir kullanıcı işlemi iki ayrı kaydı çelişkili bırakırsa sorun her zaman yavaş sorgu değildir. Bazen uygulama, birlikte tamamlanması gereken değişiklikleri ayrı işler gibi yürütüyordur. Veritabanı işlemleri, yani transaction yapısı, bu tutarlılık sınırını tanımlamak için kullanılır.
İşlemin sınırını iş kuralı belirler
Bir fatura taslağı ve ona ait kalemler aynı işin parçaları olabilir. Ya gerekli kayıtlar birlikte tamamlanmalı ya da eksik bir taslak kullanılabilir hâle gelmemelidir. MySQL COMMIT ve ROLLBACK dokümanı, değişiklikleri onaylama ve geri alma davranışını açıklar. Depolama motorunun ve kullanılan komutların bu davranışa uygunluğu ayrıca kontrol edilir.
Transaction başlatmak bütün hataları çözmez. Dışarıdaki bir servisin yaptığı işlemi yerel veritabanı geri alamaz. Örneğin belge servisine gönderim ile yerel kayıt güncellemesinin sınırı farklıdır. Uygulama bu iki sonucu ayrı durumlarla takip etmeli; birinin belirsiz kalmasını diğerinin başarılı görünmesiyle örtmemelidir.
İki kullanıcı aynı kaydı değiştirirse
Bir ekip üyesi proje bütçesini düzenlerken diğeri aynı eski ekranı açık tutabilir. Son kaydedenin diğer değişikliği sessizce ezmesi istenmiyorsa sürüm alanı veya uygun kilitleme yaklaşımı gerekir. İyimser eşzamanlılık kontrolünde uygulama, kaydın kullanıcı okuduğundan beri değişip değişmediğini kontrol ederek yeniden değerlendirme isteyebilir.
Satır kilidi gereken durumlarda kapsamı kısa tutun. InnoDB locking read açıklaması, normal okuma ile kilitleyen okuma arasındaki farkı gösterir. Kilitli bir işlem içinde kullanıcıdan yanıt beklemek veya uzun bir ağ isteği yapmak diğer işlemlerin beklemesine yol açabilir. Tasarımın neyi koruduğu ve ne kadar süre koruduğu açık olmalıdır.
Deadlock bir ürün davranışı gerektirir
İki işlem kaynakları farklı sırayla kilitlediğinde karşılıklı bekleme oluşabilir. Kaynaklara tutarlı sırayla erişmek ve işlemleri kısa tutmak bu olasılığı azaltır. Yine de uygulamanın ilgili veritabanı hatasını tanıyıp güvenli sınırlar içinde yeniden denemesi gerekebilir. Her hatayı sınırsız tekrar etmek çözüm değildir.
Yeniden denenen işin dış etkilerini düşünün. Kullanıcıya iki bildirim gitmesi veya aynı dış talebin tekrar oluşması, veritabanındaki kaydın tek olmasına rağmen yaşanabilir. İşin yerel değişikliklerini ve dış teslimini ayrı izlemek, hata durumunda neyin tekrar edileceğini netleştirir. Günlüğe yalnız “başarısız” yazmak inceleme için yetersizdir; iş kimliği ve durum geçişi daha kullanışlıdır.
Gerçek bir tutarlılık testi
- İşin ortasında hata üretip kısmi kayıt kalıp kalmadığını inceleyin.
- İki ayrı bağlantıyla aynı kaydı eşzamanlı güncelleyin.
- Kilit beklemesi ve yeniden deneme sınırını doğrulayın.
- Başarılı işlemden sonra okunabilen sonucun iş kuralını karşıladığını kontrol edin.
- Dış servis yanıt vermediğinde yerel kaydın anlaşılır durumda kaldığını görün.
İndeks optimizasyonu süreyi iyileştirmeye yardımcı olabilir; transaction tasarımı ise kayıtların hangi koşulda doğru sayılacağını belirler. Bir uygulamanın yalnız hızlı değil, eşzamanlı kullanımda da tutarlı olması için iki konu ayrı değerlendirilmelidir.