İLERİ

Quorum Queues & High Availability

Quorum Queue, mesajların birden fazla sunucuda kopyalanarak saklandığı queue tipidir. Bir sunucu çökse bile mesajlar diğerlerinde durur — veri kaybı olmaz.

Seviye: İleri — Raft consensus ve distributed systems bilgisi faydalıdır. Önce Clustering ve Node Discovery sayfasını okuyun.

📖 Teknik detay: Quorum Queue, Raft consensus algoritması kullanır. Her queue'nun bir "leader" ve birden fazla "follower" kopyası vardır. Mesaj, çoğunluğa (majority) yazıldıktan sonra onaylanır. 3 node'luk cluster'da 1 node düşse bile sistem çalışmaya devam eder.

Ne Zaman Kullan / Kullanma

Quorum Queue Kullan	Classic Queue Yeterli	Gerçek Hayat
Mesaj kaybı kabul edilemez	Geçici/ephemeral veriler (cache invalidation)	Fintech: ödeme event'leri → Quorum
Multi-node cluster (3+ node)	Tek node dev ortamı	SaaS: prod 3-node → Quorum, dev → Classic
Auto-failover gerekli	Manual failover tolere edilir	E-ticaret: Black Friday kesinti = gelir kaybı
Poison message koruması lazım	Tüm mesajlar güvenli şekilde işlenebilir	Marketplace: malformed JSON → delivery-limit korur
Consumer timeout kontrolü	Consumer'lar hızlı ve güvenilir	IoT: cihaz offline → timeout ile ack iptal

Önemli kısıt: Quorum Queue exclusive ve auto-delete desteklemez. RPC reply queue'ları veya temporary queue'lar için Classic Queue kullanmalısın.

Fault Tolerance Tablosu

Cluster Size	Quorum (Majority)	Tolere Edilen Kayıp	Partition Safe?	Öneri
1	1	0	—	Sadece dev
2	2	0		Kullanmayın
3	2	1 node		Production min
4	3	1 node	Koşullu	3 ile aynı tolerans
5	3	2 node		Yüksek HA
7	4	3 node		Nadiren gerekir, perf düşer

Neden Tek Sayı? Çift sayı node'da partition oluşursa, iki eşit tarafın hiçbiri majority oluşturamaz. 4 node = 3 node ile aynı fault tolerance (1 kayıp). Kaynak israfı olmadan HA istiyorsanız 3 veya 5 kullanın.

Quorum Queue vs Classic Queue

Özellik	Quorum Queue	Classic Queue
Replication	Raft (N replicas)	Single node
Leader election	Otomatik (Raft)	—
Data safety	Majority write guarantee	Single disk write
Poison message	delivery-limit (default: 20)
Consumer timeout	(4.3+)
Delayed retry	Native (4.3+)
Message priority	0-31 strict (4.3+)	0-255
Exclusive queue
Auto-delete
Memory kullanımı	~32 bytes/msg index + WAL	Değişken
Throughput (4.3)	Yüksek (optimized)	Yüksek (single node)

CMR — Continuous Membership Reconciliation

CMR, quorum queue'ların otomatik olarak target group size'a büyümesini sağlar. Yeni node eklendiğinde veya bir node kalıcı olarak çıkarıldığında, CMR queue membership'i hedef değere getirmeye çalışır.

# CMR'ı aktifleştir
quorum_queue.continuous_membership_reconciliation.enabled = true
quorum_queue.continuous_membership_reconciliation.target_group_size = 3
quorum_queue.continuous_membership_reconciliation.auto_remove = true
quorum_queue.continuous_membership_reconciliation.interval = 3600000

# VEYA policy ile (daha esnek):
# rabbitmqctl set_policy cmr-policy ".*" #     '{"target-group-size": 3}' #     --apply-to "quorum_queues" --priority 0

# Queue member'larını listele
rabbitmq-queues quorum_status payment-processing

# Yeni node'a member ekle
rabbitmq-queues add_member payment-processing rabbit@node4

# Node kaldır (shrink)
rabbitmq-queues delete_member payment-processing rabbit@node2

# Tüm queue'ları yeni node'a grow et
rabbitmq-queues grow rabbit@node4 all

# Leader'ları rebalance et (restart/maintenance sonrası)
rabbitmq-queues rebalance quorum

# Belirli queue pattern'ı rebalance
rabbitmq-queues rebalance quorum --queue-pattern "orders.*"

Node Removal: Bir node'u cluster'dan kalıcı olarak çıkardığınızda (forget_cluster_node), o node üzerindeki tüm quorum queue replica'ları otomatik silinir. Önce rabbitmq-queues shrink ile member'ları başka node'lara taşıyın.

Gerçek hayat senaryosu: SaaS order processing: 5-node cluster, quorum size=3. 2 node aynı anda çökse bile queue'lar available kalır. CMR aktif: yeni node eklendiğinde 10 saniye içinde reconciliation tetiklenir ve under-replicated queue'lar otomatik büyütülür. Ops team müdahalesi gereksiz.

Node Kaybı Senaryoları

Senaryo	3-node cluster (quorum=2)	5-node cluster (quorum=3)	Yapılacak
1 node down	Available	Available	Leader re-election (<10sn), müdahale gerekmez
2 node down	Unavailable	Available	3-node: acil müdahale! 5-node: monotor et
Leader down	New leader elected	New leader elected	Publisher confirm timeout olabilir, retry yeterli
Network partition	Partition handling policy'ye bağlı	Minority side unavailable	`pause_minority` önerilir
Disk full (1 node)	Diğerleri çalışır	Diğerleri çalışır	Alarm tetiklenir, publish durur (o node'da)

Rollback Adımları (Node Kaybı):

rabbitmq-diagnostics cluster_status ile durumu doğrula

Down node recover edilebilir mi kontrol et (systemctl start rabbitmq-server)

Recover edilemezse: rabbitmqctl forget_cluster_node rabbit@dead-node

Under-replicated queue'ları büyüt: rabbitmq-queues grow rabbit@new-node all

Leader'ları rebalance et: rabbitmq-queues rebalance quorum

Cloud Managed RabbitMQ Seçenekleri

Platform	Servis	Max Version	Not
AWS	Amazon MQ for RabbitMQ	3.13.x	Single/multi-AZ, otomatik failover
CloudAMQP	Dedicated/Shared	4.x	En güncel, Tiger plan ile dedicated
Azure	Tanzu RabbitMQ (Marketplace)	3.13.x	Bitnami Helm chart tabanlı
Self-hosted K8s	RabbitMQ Cluster Operator	4.x	En esnek, ops yükü sizde

AWS Amazon MQ kısıtlamaları: Erlang cookie erişimi yok, plugin kurulumu sınırlı, max instance size = mq.m5.4xlarge. Streams desteği henüz yok. Quorum queue kullanılabilir ama cluster resize işlemi manuel ticket gerektirir.

Gerçek hayat senaryosu: Fintech startup — hızlı MVP için CloudAMQP Tiger plan ile başladı (tam kontrol, güncel versiyon). Traffic 10x büyüdüğünde maliyet nedeniyle K8s Cluster Operator'a geçiş yaptı. Geçiş sırasında Shovel ile zero-downtime migration uygulandı.