Tarih: Geleneksel e-ticaret platformları, 100,000 eş zamanlı ödeme işlemi aşan ani satış yükleri altında çöken monolitik RDBMS örneklerine dayanıyordu. Sanayi, okuma ve yazma yollarını ayırmak için CQRS ve Olay Kaynağı desenlerine yöneldi, ancak bu, dağıtılmış WMS ve miras ERP siloları arasında envanter doğruluğunu sürdürmeyi karmaşık hale getirdi; çeşitli gecikme özellikleri ile.
Problem: Temel zorluk, ağ parçalanmaları sırasında CAP teoremi kısıtlamalarını karşılarken aşırı satışları önlemektir - katı bir iş kesinliği. Dağıtılmış kilit mekanizmaları, RedLock gibi, gecikme ve kullanılabilirlik riskleri getirirken, tamamen eventual tutarlı modeller, sahte envanter satış riski taşır. Ayrıca, miras SOAP/XML tabanlı WMS sistemleri ile heterojen entegrasyon noktaları, atomik işlem sınırlarını karmaşıklaştıran uyumsuzluk ve zaman aşımı merdivenleri oluşturur.
Çözüm: Envanter delta'larının gerçek kaynağı olarak bir Olay Deposu (örneğin, Apache Kafka veya EventStoreDB) uygulamak, global kilitler olmadan sebep sıralamasını sağlamak için optimist eşzamanlılık kontrolü ile vektör saatleri kullanmaktır. Saga orkestrasyonu ( Temporal veya Camunda kullanarak) aracılığıyla, yerel rezervasyonların hemen olay deposuna kaydedildiği ve WMS'ten gelen asenkron onayın nihai tahsisi veya telafi serbest bırakmalarını tetiklediği çapraz-WMS işlemlerini yönetmek. Okuma ölçeklenebilirliği için, Redis veya Elasticsearch'a projeksiyon yapan Debezium ile CQRS uygulayarak, geçici kararsızlıkların kabul edildiği, ancak 50 ms altı okuma gecikmeleri sağlamak.
2022 Kara Cuma hazırlıkları sırasında, uluslararası bir moda perakendecisi, 50,000 eş zamanlı kullanıcının sınırlı sayıda sneaker satışına yönelmesiyle yıkıcı veritabanı zaman aşımına uğradı. Mevcut MySQL master-slave topolojisi, sıcak envanter satırlarında aşırı yazma rekabeti yaşadı ve bu da 12 saniyelik ödeme gecikmelerine ve çoğaltma gecikmesi nedeniyle yaşanan 300 aşırı satış olayına yol açtı. İşletmenin, satılabilir birimlerin fiziksel depo stokunu asla aşmaması gerektiğini koruyarak ani satış trafiği tsunamilerini absorbe edebilen bir çözüme ihtiyacı vardı.
Mühendislik ekibi, envanter azaltımları sırasında dağıtılan karşılıklı dışlamayı sağlamak için üç kullanılabilirlik bölgesinde Redis RedLock algoritmalarını uygulamayı önerdi. Bu yaklaşım, ekibe aşina olan güçlü tutarlılık garantileri ve hali hazırda oturum yönetimi için kullanılan mevcut Redis kümeleriyle basit entegrasyon avantajı sağladı. Ancak, kritik dezavantajlar, kullanılabilirlik bölgesi hatalarında 500ms’i aşan kabul edilemez gecikme artışları ve kilit güvenlik özelliklerini geçersiz kılabilecek saat kayması teorik riski içeriyordu; bu da en kritik gelir yaratan dönemlerde envanter tahsisini bloke edebilirdi.
Alternatif bir strateji, veritabanını SKU aralıklarıyla yatay olarak parçalamayı ve bölgesel PostgreSQL örnekleri arasında İki Aşamalı Taahhüt protokollerini kullanarak ACID garantilerini sürdürmeyi içeriyordu. Bu çözüm, karmaşık eventual tutarsızlık desenleri olmadan güçlü tutarlılık ve anında envanter doğruluğu sağladı, geleneksel işlem düşünce yapılarına uyuyordu. Ancak, zorluklar caydırıcıydı: 2PC’nin engelleyici doğası, koordinator hatalarının veritabanı kilitlerini sonsuza dek tutabileceği anlamına geliyordu; ayrıca protokolün mesaj karmaşıklığı, trafik zirveleri sırasında ağ tıkanıklığına yol açarak, 24/7 küresel ticaret için gerekli olan kullanılabilirlik gereksinimlerini temel olarak ihlal ediyordu.
Son aday mimari, Apache Kafka ve Saga orkestrasyonu ile Olay Kaynağını benimseyerek, telafi edici işlemler aracılığıyla iş kesinliklerini zorlayarak BASE anlamlarını kabul etti. Artıları, bölünebilen olay akışları aracılığıyla doğal yatay ölçeklenebilirlik, dolandırıcılık analizi için kritik olan değişmez denetim izleri ve idempotent olay tüketicileri aracılığıyla miras WMS ile doğal entegrasyonu içeriyordu. Ana dezavantajlar, değişmez veri desenlerine aşina olmayan geliştiriciler için dik bir öğrenme eğrisi ve olay şeması evrimi ve yeni okuma modeli projeksiyonları için yeniden oynatma stratejilerini yönetme operasyonel karmaşasıydı.
Mimari komite, ani satışların temelde kullanılabilirlik ve parçalanma toleransını hemen tutarlılığın önünde önceliklendirmenin yanı sıra, iş mantığının geçici yumuşak rezervasyonları beş dakikalık TTL ile tahsis edebileceğini belirtti. Kilit alternatiflerin aksine, bu tasarım, sistemin veri merkezleri arasında ağ parçalanmaları sırasında kullanılabilir kalmasını sağladı ve müşterilerin her zaman satın alma girişimlerinde bulunabilmesini sağladı, depo onaylarının gecikme yaşama ihtimali olsa bile. Ayrıca, değişmez olay günlüğü, finans ekiplerinin üçüncü taraf lojistik sağlayıcılarıyla uyuşmazlıkları uzlaştırmak için gereken denetim izini sağladı.
Uygulama, yerel envanter agregat yönetimi için Kafka Streams, SAP ve özel WMS sistemleri arasında saga orkestrasyonu için Temporal, sorgu optimizasyonu için ise yazma üzerinden önbellekleme ile Redis kullandı. Takip eden Siber Pazartesi etkinliği sırasında, platform, p99 gecikmesi 80ms altında ve sıfır aşırı satış olayı ile 120,000 eş zamanlı ödemeyi başarıyla işledi ve önceki monolitik mimarinin felç edeceği, us-east-1 bölgesinde simüle edilen bir kesinti yaşandı bile.
Küresel kilitler kullanmadan, birden fazla Kafka bölümü arasında eş zamanlı rezervasyonları işlerken hayalet envanteri nasıl önlersiniz?
Hayalet envanteri, eşzamanlı komutlar farklı bölümlerden eski stok seviyelerini okuduğunda ve her ikisi de gerçek kullanılabilirliği aşan rezervasyonlar yaptığında ortaya çıkar. Bunu küresel kilitler olmadan önlemek için, Olay Deposunda sürüm numaralarını kullanarak optimist eşzamanlılık kontrolü uygulayın; her envanter agregatı tek yönlü bir sayaç tutar ve komutlar beklenen sürümleri içerir; depo, sürümlerin uyuşmadığı durumlarda eklemeleri reddeder, bu da istemci denemelerine zorlar. Ayrıca, belirli bölümler için SKU’ları hashleyerek bölüm bağlılığını sağlamak, her agregat için tek yazar semantiği sürdürmek ve tamamen bölümler arası koordinasyonu ortadan kaldırmak gerekir.
Yerel olay deposunun, yerel stok azaltımını zaten taahhüt ettikten sonra bir miras WMS SOAP uç noktası zaman aşımına uğradığında telafi edici işlem stratejisi nedir?
Bu senaryo, yerel durumun dış gerçeklikten ayrıldığı kısmi bir hatayı temsil eder; bu, Saga desenini geri almaya ihtiyaç duyar. WMS adapteri bir zaman aşımına uğradığında, saga orkestratörüne bir zaman aşımı olayını yayımlar; bu, envanteri mevcut havuza geri döndürmek için bir Stok_Bırakıldı olayı eklerken, yeniden tahsisleri önlemek için idempotent anahtarlar da saklanmalıdır. Kritik olarak, orijinal azaltım olayını asla silmeyin; bunun yerine, işlem girişiminin tamamı için zamansal geçmişi ve denetim izini korumak için telafi edici olaylar ekleyin.
Yeniden oynatma sürecinde müşteri tutarsız envanter sayılarıyla karşılaşmadan olay yeniden oynatma ve okuma modelini yeniden inşa etmeyi nasıl yönetirsiniz?
Olayları yeniden oynatmak, CQRS okuma modellerini yeniden inşa etmek, projeksiyonlar güncellenirken geçici olarak yanlış stok seviyeleri sunma riski taşır. Çözüm, okuma modelleri için blue-green dağıtımı uygular: mevcut örnek trafiği hizmet ederken olay günlüğünden sıfırdan tüketen bir gölge projeksiyon oluşturun, ardından gölge yetiştiğinde yönlendirmeyi atomik olarak değiştirin. Ayrıca, yeniden oynatma süresini azaltmak için Kafka günlük sıkıştırmasını ve periyodik S3 anlık görüntülerini kullanarak, yeni projeksiyonların yeniden inşa sırasında potansiyel tutarsızlık penceresini en aza indirmesini sağlamak.