PostgreSQL işlem günlüklerine bağlı Debezium bağlayıcıları kullanarak bir Değişiklik Veri Yakalama (CDC) katmanı uygulayın. Olayları Kafka'dan geçirilen akışlarla iletin ve mesaj kalıcılığını ve saklanmasını sağlamak için log sıksama etkinleştirin.
S3 veya GCS'ye kontrol noktaları aracılığıyla tam olarak bir kez anlamını koruyarak durum bilgisini sürdüren Apache Flink veya ksqlDB'yi dağıtın. Geriye dönük ve ileriye dönük uyumluluk kurallarını zorunlu kılmak için Confluent Şema Kaydı ile Avro veya Protobuf formatlarını kullanın, evrim sırasında tüketici kırılmalarını önleyin.
Çakışma çözümlemesi için, bölgeler arası nedenselliği izlemek amacıyla metadata katmanında Vektör Saatleri veya Sürüm Vektörleri uygulayın. Son-Yazma-Kazanır (LWW) yalnızca kritik olmayan alanlar için uygulanırken, sayaçlar ve kümeler için CRDT-tabanlı birleştirme fonksiyonları kullanın. Nihai görünümleri analitik için ClickHouse veya Apache Druid'e malleştirin, görünüm deposunda sonlu tutarlılık için Narayana veya Saga desenleri gibi dağıtık işlem yöneticileri aracılığıyla ACID özelliklerini garanti edin.
GlobalMart, uluslararası bir e-ticaret platformu, Kara Cuma etkinlikleri sırasında kritik veri stalenliği ile karşılaştı. Gecelik toplu ETL işleri, MySQL işlem kayıtları ile BigQuery analiz panelleri arasında 4 saatlik gecikme yarattı, bu da envanterin fazla satılmasına ve fiyat güncellemelerinin başarısız olmasına neden oldu.
Çözüm A: Doğrudan CDC'den Arama İndeksine. MySQL binlog'unu doğrudan Elasticsearch'e Logstash kullanarak akıtmaları düşünüldü. Bu, düşük gecikme ve basit kurulum sundu. Ancak, tablolar arasında karmaşık birleştirme işlemleri imkansız hale geldi ve şema değişiklikleri tam bir Elasticsearch yinelemesi gerektiriyordu, bu da 6 saatlik kesintiye neden oldu.
Çözüm B: Komut Sorgu Sorumluluğu Ayrımı (CQRS). Bu yaklaşım, okuma ve yazma modellerini ayırmak için Axon Framework'ü kullandı. Üstün denetim izleri ve esneklik sağlasa da, tam bir uygulama yeniden yapılandırması gerektirdi. Ekibin mevcut monolitik Spring Boot uygulamasının olay kaynaklı bir sisteme geçişi kolay değildi ve öğrenme eğrisi 2 aylık son tarih için fazla dikti.
Çözüm C: Şeması Olan Akış Malleşmiş Görünümler. Debezium'u PostgreSQL'den yakalayarak, Kafka'ya akıtıp, iş mantığını uygulayan Flink ile işleyip, ClickHouse'a bıraktılar. Confluent Şema Kaydı'ndaki Avro şemaları CI/CD sırasında uyumluluk kontrollerini zorladı. Çakışma çözümlemesi için, bölgesel promosyonların farklı envanter sayıları oluşturduğu durumlarda otomatik birleştirmeyi sağlayan Kafka başlıklarında gömülü Vektör Saatleri kullandılar.
Çözüm C'yi seçtiler çünkü mevcut SQL şemalarını korurken gerçek zamanlı yetenekler sağladı. Şema Kaydı, uyumsuz şema değişikliklerini kabul etmeyerek dağıtım hatalarını önledi.
Sonuç olarak, 120 ms uçtan uca gecikme elde edildi, 50,000 işlem/saniye desteklendi ve us-east-1 bölgesi kesildiğinde sıfır RPO sağlandı, bu da ikinci bölgedeki Kafka ayna yapısı 2'ye geçiş yaparak gerçekleştirildi.
CDC, malleşmiş görünümlerde kısmi güncellemeleri önlemek için çok tablolu işlem tutarlılığını nasıl sağlıyor? Debezium'un otomatik olarak tablolar arasında atomikliği garanti ettiğini varsayan birçok kişi vardır. Gerçekte, CDC, her tablo için ayrı olaylar iletir. Tutarlılığı korumak için Transactional Outbox desenini uygulamanız gerekir: iş olaylarını, iş mantığınızla aynı veritabanı işlemi içinde bir dış kutu tablosuna yazın. Debezium yalnızca dış kutu tablosunu yakalar, atomik olay yayılımını sağlar. Alternatif olarak, Debezium'un transaction.metadata özelliğini kullanarak, tüketicide işlem kimliğine göre olayları gruplayabilir, ilgili tüm olaylar gelene kadar güncellemelerini bekletirsiniz.
Bölge aşırı görünümler için gelişmiş tutarlılığı ne zaman tercih edersiniz ve belirli uygulama ticaretleri nelerdir? Adaylar genellikle gecikme maliyetlerini düşünmeden güçlü tutarlılığa varsayıyorlar. Güçlü tutarlılık, bölgeler arasında İki Aşamalı Taahhüt (2PC) veya Paxos/Raft uzlaşması gerektirir, her yazım için 100-300 ms gecikme ekler. Bu, finansal defterler veya envanter tahsisi için gereklidir. Öneri motorları veya analiz panelleri için, CRDT'ler veya son-yazma-kazanır ile Vektör Saatleri kullanmalısınız. Ticaret, müşteri tarafı birleştirme mantığı ile sunucu tarafı koordinasyonu arasında karmaşıklık içerir. CRDT'ler, iş mantığı esnekliğini sınırlarken, veri yapıları ve komütatif işlemler gerektirir, bölünmeler sırasında kullanılabilirliği sağlar (AP CAP teoremi içinde).
Eski alanları kaldırırken şema evriminin aşağı akış tüketicilerini kırmamasını nasıl önlersiniz? Çoğu, ileri uyumluluğu (yeni kodun eski verileri okuması) anlar, ancak geri uyumluluğu (eski kodun yeni verileri okuması) kaçırır. Bir alanı kaldırırken, asla hemen silmeyin. Bunun yerine, SSH'de default değerleri kullanın, yeni şemayla tüketicileri dağıtın, ardından iki sürüm döngüsü sonra üreticilerde alan yazmayı durdurun. Kırıcı değişiklikler (örneğin, tür değişiklikleri) için Ayrı Konular Vasıtasıyla Şema Evrimi uygulayın: events-v2 konusuna yazarken, events-v1'i koruyun ve yavaş bir geçiş imkanı tanıyan bir köprü tüketiciyle devam edin.