Shopify envanter rezervasyonlarını MySQL'e taşıdı
Shopify, envanter rezervasyon sistemini Redis'ten, envanter defterini zaten tutan MySQL veritabanına taşıdı.
Shopify, envanter rezervasyon sistemini Redis'ten, envanter defterini zaten tutan MySQL veritabanına taşıdı. Bireysel olarak kilitlenebilir birim satırlarından oluşan sınırlı bir havuz, eşzamanlı ödemelerin farklı uygun birimleri seçmek için SKIP LOCKED kullanmasına olanak tanır. Tasarım ayrıca işlem sınırlarına, birincil anahtar düzenine, yenileme kurallarına ve ödeme sırasında bağlantı tutma süresinin gözlemlenmesine de bağlıdır.
Yazılı sürümü oku (İngilizce) ↗
Bu video neleri kapsar
- Eski Redis miktar sayacı modeli eşzamanlılığı ele alıyordu, ancak rezervasyon temizleme ve MySQL defter güncellemesi tek bir yerel atomik işlemi paylaşamıyordu.
- Yedek, her öğe/konum kombinasyonu için 1.000 ile sınırlı bir havuzda mevcut birim başına bir satır kullanır. Boş bir havuz, yenileme kilidinin arkasında bekleyen eşzamanlı isteklerle satır içi yenilemeyi tetikleyebilir.
- Bileşik birincil anahtar (shop_id, inventory_item_id, inventory_group_id, id) şeklindedir. Shopify, prototipinde kilit yükünü azalttı ve yenilemeyi engelleyen boşluk kilitlerinden kaçınmak için READ COMMITTED kullandı.
- Rezervasyon, rezervasyon kayıtlarını eklemeden önce havuz satırlarını siler. İşlemin onaylanması veritabanı kilitlerini serbest bırakırken, depolanan bekleme ödeme boyunca devam eder; başarılı ödeme defteri talep eder ve rezervasyonu daha sonraki bir atomik işlemde kaldırır.
- MySQL, SKIP LOCKED'u kilitli satırları dışlayan tutarsız bir görünüm olarak belgeler. Tam bir stok sayımı veya adil sıra alma sağlamaz, yalnızca satır düzeyindeki kilitler için geçerlidir ve ifade tabanlı çoğaltma için güvensizdir.
- Kaynak örnek expires_at içerir, ancak Shopify MySQL son kullanma-temizleme algoritmasını belgelemez. Videonun yayınlama/son kullanma dalı açıklayıcı bir yaşam döngüsü gereksinimidir.
- Diğer ödeme kodundaki bağlantı tutma süresi son verim darboğazıydı. Shopify her iki sistemi de gölge yazdı, sonuçları karşılaştırdı ve Redis kill-switch geri dönüşüyle kadın kademe geçiş yaptı.
Çevrilmiş deşifre
Orijinal İngilizce anlatımdan çevrilmiştir. Mevcut ses ve altyazılar YouTube tarafından kontrol edilir.
Rezervasyonlar neden MySQL'e taşınsın?
0:00 Bir ödemenin hızlı kalması için Redis'e ihtiyacı var. Shopify, envanter rezervasyonlarını MySQL'e taşıdı ve birimde bir satır kullandı. sınırlı havuz. Neden MySQL'i seçtiniz? Kilitleri güvenli bir şekilde nasıl atlarsınız? Bu, The Daily Diff, perde arkası. Ve neden hızlı sorgular hala tavana çarpıyordu? Shopify, çevrimiçi ve şahsen satış için bir ticaret platformudur. Redis, bellekte bir veri deposudur.
0:21 MySQL bir ilişkisel veritabanıdır ve Shopify envanter defterini zaten burada tutuyordu. Bir rezervasyon, alıcı ödeme yaparken stoku kısa süreliğine tutar.
Neden iki mağaza riskliydi?
0:29 Redis modelleri bir öğe sayacını azaltıyordu. Ödenen bir siparişi talep etmek, MySQL defterini güncellemeyi ve Redis'i temizlemeyi gerektiriyordu. Bu ayrı yazma işlemleri, stokun iki kez satılmasına veya satılabilir olması gerekirken kullanılamamasına neden olabiliyordu. Eski modelde konum farkındalığı da yoktu. Yedek, siparişi yerine getirebilecek bir yerden stok seçmelidir. Yanlış kıtadaki bir depo, mükemmel bir veritabanı girişi ve korkunç bir teslimat sözüdür. Yanlış kıtadaki bir depo, mükemmel bir veritabanı girişi ve korkunç bir teslimat sözüdür. Daha önceki MySQL denemeleri bir miktar satırı kullanıyordu, bu nedenle rekabet eden ödemeler aynı kilitte sıraya giriyordu.
Kilitlenebilir birim ne oluyor?
0:56 Bir elektronik tablo hücresinin etrafındaki kadife bir ip gibi düşünün. Daha fazla çalışan eklemek sadece kuyruğu uzatır. Shopify kilitlenebilir nesneyi değiştirdi. Her mevcut birim kendi satırına sahip olur. Bir kilitleme okuması, başka bir işlemin tuttuğu birimleri atlar ve diğer uygun birimleri seçer. Farklı çalışanlar farklı satırlar edinebilirken, farklı çalışanlar farklı satırlar edinebilirken, sıcak sayaç onların yolundan uzak durur.
Havuz boşaldığında ne olur?
1:15 Bu havuz, öğe ve konum başına bin satırla sınırlıdır. Yenileme defterden çekilir. Boşalırsa, rezervasyon yolu yenileme kilidinin arkasında bekleyen rekabetçi isteklerle birlikte satır içi yenilenir. yenileme kilidinin arkasında bekleyen rekabetçi isteklerle birlikte satır içi yenilenir. Boş havuz, boş depo anlamına gelmez. Rezervasyon, seçilen havuz satırlarını siler, ardından bir işlemde rezervasyon kayıtlarını ekler. Commit, veritabanı kilitlerini serbest bırakır.
1:35 Rollback, değişiklikleri geri alır. Rezervasyon, depolanmış durum olarak ödeme işlemi boyunca hayatta kalır. Başarılı ödeme defteri talep eder ve rezervasyonu atomik olarak kaldırır. Veritabanı kilitlerinin asla ödeme formunu denetlemesine gerek yoktur. Bileşik birincil anahtarları mağaza, öğe, grup ve ardından birim kimliği ile başlar. grup, sonra birim kimliği. Aramayı eşleştirmek, prototiplerinde dizin kilitlemesini azalttı. Ayrıca, havuz yenilemesini engelleyen boşluk kilitlerinden kaçınmak için okuma onayını ve döngüsel beklemeleri önlemek için tutarlı bir tablo sırasını kullanırlar.
1:57 yenilemesini engelleyen boşluk kilitlerinden kaçınmak için okuma onayını ve döngüsel beklemeleri önlemek için tutarlı bir tablo sırasını kullanırlar. Yayınlanan örnek bir son kullanma süresi kaydeder. Terk edilmiş ödemeler sonunda stokun serbest bırakılmasını gerektirir, aksi takdirde alışveriş sepeti bir ev sahibi haline gelir. Shopify'ın gönderisi bu temizleme algoritmasını belirtmez, bu nedenle bu diyagram yaşam döngüsü gereksinimini gösterir. bu nedenle bu diyagram yaşam döngüsü gereksinimini gösterir. İşte püf noktası.
SKIP LOCKED neleri dışarıda bırakıyor?
2:14 Atlanan kilitler kilitli satırları hariç tutar, bu nedenle kılavuz sonucunu tutarsız bir görünüm olarak adlandırır. Ne eksiksiz bir stok sayımı ne de adil sıra alma sağlar. Kullanılabilirlik kararını ve yenileme kurallarını etrafında tutun.
Gerçek tavan neredeydi?
2:26 Ve o tavan? Diğer ödeme kodu veritabanı bağlantılarını çok uzun süre tutuyordu. Shopify arayanları etiketledi ve bağlantı tutma süresini ölçtü, ardından ödeme yolunu temizledi ve iş parçacığı eşzamanlılığını yeniden gözden geçirdi. ardından ödeme yolunu temizledi ve iş parçacığı eşzamanlılığını yeniden gözden geçirdi. Hızlı sorgular hala sorgunun dışında sıraya girebilir.
Bu tasarımı neden göndereyim?
2:38 Her iki sistemi de Redis yetkili olacak şekilde gölge yazdı, sonuçları karşılaştırdı, ardından bir kill switch ile kademeli olarak geçiş yaptı. karşılaştırdı, ardından bir kill switch ile kademeli olarak geçiş yaptı. Kararım SHIP IT. Paylaşılan işlem sınırını ve o geri alınabilir yayını, tüm ödeme yolu enstrümanlı olarak gönderirdim. Paylaşılan işlem sınırını ve o geri alınabilir yayını, tüm ödeme yolu enstrümanlı olarak gönderirdim. Bununla ilgili bir sorunuz var mı? Yorumlara yazın. Ve bugünün farkı bu.
2:54 Ben Axrisi'den Niko. Sorumlu bir şekilde birleştirin.
Kaynaklar
- We replaced Redis with MySQL for inventory reservations—and it scaledShopify Engineering — Emilie Noel
- Simplified reservation SQL embedded in Shopify's articleShopify Engineering / CourtneySymons on GitHub Gist
- MySQL 8.0 — Locking ReadsOracle / MySQL Reference Manual
- MySQL 8.0 — Transaction Isolation LevelsOracle / MySQL Reference Manual
- What Is Shopify and How Does It Work?Shopify
- Redis quick startsRedis documentation
- What is MySQL?Oracle / MySQL Reference Manual



