Veri tabanı üzerinde yapılan işlemlerin her birisi bizim için bir transaction’dır.
Bazı business transaction’lar, birden fazla transactionın çalışmasını gerektirebilir.
Eğer Mikroservis Mimari söz konusuysa, bu aslında birden fazla servisin ard arda çalışması anlamına gelir. Bu arda arda çalışan transaction’lar dizisinin yönetilmeye ihtiyacı vardır.
Örneğin ödeme işlemi ve sonrasında ürünün stoktan düşülmesi süreçlerini ele alalım.
Ödeme işlemi başarılı olmadan, stoktan düşme süreci ve sonraki süreçler işletilemez.
Peki ödeme işlemi başarılı olduktan sonraki süreçlerin birisinde bir hata meydana gelirse ne yapmalıyız?
Yazılım tarafında bu durumu nasıl yöneteceğiz?
Bu hata oluştuktan sonra o ana kadar veri tabanı üzerinde yapılmış olan işlemlerin tümünü geri almak gibi bir sorunumuz var.
İşte bu sorun ve çözümü transaction bütünlüğü/tutarlılığı/yönetimi konusunun temelini oluşturmaktadır.
ACID Prensipler
ACID, değişikliklerin bir veri tabanına nasıl uygulanacağını yöneten 4 adet prensip sunar. Bunlar, Atomicity, Consistency, Isolation ve Durability prensipleridir. Bir kaç cümle ile açıklamak gerekirse;
Atomicity: En kısa ifadesiyle ya hep, ya hiç. Arda arda çalışan transaction’lar için iki olası senaryo vardır. Ya tüm transaction’lar başarılı olmalı ya da bir tanesi bile başarısız olursa tümünün iptal edilmesi durumudur.
Consistency: Veri tabanındaki datalarımızın tutarlı olması gerekir. Eğer bir transaction geçersiz bir veri üreterek sonuçlanmışsa, veri tabanı veriyi en son güncel olan haline geri alır. Yani bir transaction, veri tabanını ancak bir geçerli durumdan bir diğer geçerli duruma güncelleyebilir.X Servisinde karşılığı olmaksızın Y servisinde bir veri varsa tutarsızlık vardır.
Isolation: Transaction’ların güvenli ve bağımsız bir şekilde işletilmesi prensibidir. Bu prensip sıralamayla ilgilenmez.Bir transaction, henüz tamamlanmamış bir başka transaction’ın verisini okuyamaz.
Durability: Commit edilerek tamamlanmış transaction’ların verisinin kararlı, dayanıklı ve sürekliliği garanti edilmiş bir ortamda (sabit disk gibi) saklanmasıdır. Donanım arızası gibi beklenmedik durumlarda transaction log ve alınan backup’lar da prensibe bağlılık adına önem arz etmektedir.
İki farklı şekilde transaction yönetimi yapılabilir.Bunlar Saga ve 2PC
Saga Pattern
Saga,Distributed transaction sağlamamıza imkan verir. Microservis mimaride her bir microservisin kendine ait bir veritabanı vardır. İşte bu birden fazla servise dağıtılmış veritabanı sistemi distributed transaction olarak nitelendirilir. Her servis kendine ait bir veritabanına sahip olduğu için bu veritabanları arasında yapılan işe göre bütünsel bir veri tutarlılığını sağlamamız gerekir.
Bu tasarım kalıbına göre, ilk transaction, dış bir etki ile (kullanıcının kaydet butonuna tıklaması gibi ) tetiklenir ve artık sonraki tüm transaction’lar bir önceki transaction’ın başarılı olması durumunda tetiklenecektir. Transaction’lardan herhangi birisinde meydana gelecek bir hata durumunda ise tüm süreç iptal edilerek Atomicity presibine bağlılık sağlanmış olur.
1- Events/Choreography Yöntemiyle Saga Uygulaması
Bu yöntemde ilk servis işini icra ettikten sonra bir event fırlatır ve bu event’ı dinleyen servis veya servisler tetiklenerek kendi local transaction’larını çalıştırır. Yani her servis aslında bir önceki servisin “ben işimi hallettim sıra sende” demesini bekler. Son servis çalıştıktan sonra artık bir event fırlatmaz ve süreç sonlanır. Fail durumunda geriye dönük fail senryolarını yazmak gerekir.
2-Command/Orchestration
Var olan servislerimize ek olarak ayrı bir servis daha yazıyoruz. Bu yazdığımız servis arkadaki servisleri tek tek çağırıyor ve sonunucu clienta dönüyor.
Two-Phase Commit (2PC)
Hiç yorum yok:
Yorum Gönder