HazelcastAPI CP SubSystem vs Transaciton Yapılar

Giriş

Bu yazının yazılma sebebi bu soru

1. Transactional Yapılar

Hazelcast TransactionalMap, birden fazla veri değişikliğinin tek bir işlem (transaction) olarak atomik şekilde yapılmasını sağlar.

A = 100 -> 50

B = 50  -> 100

Transfer sırasında hata olursa tüm değişiklikler geri alınır.

Ancak bu, cluster'daki tüm düğümlerin aynı anda aynı veriyi gördüğü anlamına gelmez. Ağ bölünmeleri (split-brain), replikasyon gecikmeleri veya node arızalarında bazı düğümler geçici olarak eski veriyi görebilir.

Amaç:

- Atomic commit

- Rollback

- Isolation

2. CP SubSystem

CP Subsystem'in amacı transaction değil, dağıtık tutarlılıktır.

Burada Raft konsensüs algoritması kullanılır ve tüm CP üyeleri işlemlerin sırasını aynı şekilde kabul eder.

Örneğin:

counter = 5

counter = 6

counter = 7

Bir istemci 7'yi gördükten sonra başka bir istemcinin tekrar 6 görmesi mümkün değildir.

Ağ bölünmesi olursa sistem gerekirse isteği reddeder veya bekletir; yanlış/stale veri döndürmez.

3. CP Map vs Transaction doğru ayrım

3.1 CP Map:

Tekil operasyonlar için global doğruluk ve sıra garantisi

- “Herkes aynı sonucu aynı sırada görür”

- rollback yok

- her operation consensus’tan geçer

3.2 TransactionalMap:

Transaction başlatıldığında Hazelcast bir transaction context oluşturur. Bu context cluster genelinde coordinator + participant nodes üzerinden yönetilir. Ama, Hangi node’ların dahil olacağı senin seçtiğin bir liste değildir.

Kim belirler?

Hazelcast bunu otomatik belirler: Veri hangi partition’larda ise O partition’ların owner / backup node’ları transaction’a dahil olur. Transaction coordinator bunu yönetir

Yani birden fazla operation’ı atomik grup yapar

- “Ya hepsi olur ya hiçbiri”

- ama global ordering / linearizability garantisi yok

Linearizability olmadığı için 

Transaction commit:

x = 6

Durum:

Node A → 6 görüyor

Node B → 5 (eski değer) görüyor

Bu mümkündür.