Braze, müşterileri adına günde milyarlarca ve milyarlarca olayı işleyerek, son kullanıcılarına gönderilen milyarlarca hiper odaklı, kişiselleştirilmiş mesajla sonuçlanır. Bu mesajlardan birinin gönderilememesi, ister kaçırılan bir makbuz olsun, isterse daha da kötüsü, bir kullanıcıya yemeğinin hazır olduğunu bildiren kaçırılmış bir bildirim olsun, sonuçları vardır. Bu önemli mesajların her zaman doğru ve zamanında olduğundan emin olmak için Braze, iş kuyruklarından nasıl yararlandığımız konusunda stratejik bir yaklaşım benimsiyor.

İş Kuyruğu nedir?

Tipik bir iş kuyruğu, süreçlerin hesaplama işlerini bir kuyruğa gönderdiği ve diğer süreçlerin işleri fiilen yürüttüğü bir mimari modeldir. Bu genellikle iyi bir şeydir - doğru kullanıldığında size geleneksel bir istek-yanıt paradigması ile elde edemeyeceğiniz derecelerde eşzamanlılık, ölçeklenebilirlik ve fazlalık verir. Birçok çalışan, en yüksek eşzamanlılık için birden çok işlemde, birden çok makinede ve hatta birden çok veri merkezinde aynı anda farklı işler yürütebilir. Belirli kuyruklarda çalışmak için belirli çalışan düğümleri atayabilir ve belirli işleri belirli kuyruklara göndererek kaynakları gerektiği gibi ölçeklendirmenize olanak tanıyabilirsiniz. Bir çalışan işlemi çökerse veya bir veri merkezi çevrimdışı olursa, diğer çalışanlar kalan işleri yürütebilir.

Bu ilkeleri kesinlikle uygulayabilir ve bir iş kuyruğu sistemini küçük ölçekte kolayca çalıştırabilirsiniz, ancak milyarlarca işi işlerken dikişler görünmeye (ve hatta patlamaya) başlar. Günde binlerce, milyonlarca ve şimdi milyarlarca işi işlemekten büyürken Braze'in karşılaştığı birkaç soruna bir göz atalım.

Tutarlılık Eksikliği Bir Zayıflıktır

Bir mesaj gönderirsek, ancak o mesajı gönderdiğimizi kaydetmeden önce çökersek ne olur?

Burada birkaç farklı kötü sonuç mümkündür. İlk olarak, başarısız olan işi yeniden planlayabilir ve mesajı yeniden gönderebilirsiniz. Bu… ideal değil: kimse aynı şeyi iki kez almak istemez. Bunun yerine, hiç yeniden planlamamayı düşünün. Bu durumda, dahili muhasebemiz yanlış olacaktır, bu nedenle ilişkilendirmeler, dönüşümler ve diğer her türlü şey ileriye doğru doğru gitmeyecektir.

Bunu nasıl düzeltiriz? İş tanımlarımızı yazarken, yetersizlik ve yeniden deneme davranışı hakkında gerçekten çok düşünüyoruz.

Sıralar hakkında konuşurken, idempotency, tek bir işin keyfi bir noktada sonlandırılabileceği, yeniden kuyruğa alınan işin tamamıyla yeniden çalıştırılabileceği ve sonucun, işi tam olarak bir kez başarıyla çalıştırmışız gibi olacağı anlamına gelir. zaman. Bu, en az bir kez teslimat olan yeniden deneme seçim davranışımızla yakından bağlantılıdır. Tüm işlerimizin en az bir, belki birden çok kez çalıştırılacağını akılda tutarak, rastgele hatalar karşısında bile tutarlılığı sağlayan, yetersiz iş tanımları yazabiliriz.

Mesaj gönderme örneğimize geri dönersek, tutarlılığı sağlamak için bu kavramları nasıl kullanabiliriz? Bu durumda, işi iki parçaya bölebiliriz, birincisi mesajı gönderip ikincisini kuyruğa alır, ikincisi ise veritabanına yazar. Bu senaryoda, her iki işi de istediğimiz kadar tekrar deneyebiliriz - mesaj gönderen sağlayıcı çalışmıyorsa veya dahili muhasebe veritabanı çalışmıyorsa, başarılı olana kadar uygun şekilde yeniden deneyeceğiz!

İyi çitler iyi komşular sağlar

Global Gizmos veri tabanı kapalı olduğunda, örnek şirketimiz Consolidated Widgets'ın veri işlemesine ne olur?

Bu senaryoda, en az bir kez teslim stratejimiz geçerliyse, Global Gizmos'un tüm veri işleme işlerinin başarılı olana kadar tekrar tekrar denenmesini bekleriz. Bu harika—veritabanları kapalıyken bile herhangi bir veri kaybetmeyeceğiz. Ancak Konsolide Pencere Öğeleri için durum o kadar da iyi olmayabilir: çalışanlar sürekli olarak yeniden deniyor ve başarısız oluyorsa, Konsolide Pencere Öğelerinin çalışmalarını zamanında işleme koymak için çok meşgul olabilirler.

Bunu, iyi seçilmiş sıra adlarını kullanarak ve gerektiğinde belirli sıraları duraklatarak düzeltebiliriz. Alet kemerimizde bununla birlikte, cerrahi bir şekilde altyapı parçalarının üzerindeki yükü hafifletebiliriz. Yukarıdaki senaryomuzda, Global Gizmos'un veri tabanının kapalı olduğunu bildiğimizde, veri işleme kuyruğunun tekrar çalıştığını anlayana kadar duraklatabiliriz, böylece belirli bir kesintinin diğer müşterileri etkilememesini sağlayabiliriz!

Beklemek Acıdır

Konsolide Widget'lar ve Global Gizmos, her biri 5 dakika arayla 50 milyon kullanıcıya e-posta kampanyaları gönderirse ne olur? İlk kim gider?

Basit iş kuyruğu sistemlerinde, çalışanların işleri çektiği basit bir "iş" kuyruğu vardır. Çok çeşitli farklı iş ve iş türlerine sahip olduğunuzda, muhtemelen her biri farklı önceliklere veya bu kuyruklardan çeken işçi türlerine sahip birden çok türde sıraya sahip olursunuz. Bu bağlamda, veri işleme, mesajlaşma ve çeşitli bakım görevleri için çeşitli basit kuyruklarımız var.

Günde milyarlarca kişiselleştirilmiş mesaj gönderirken, tek bir "mesajlaşma" kuyruğu bunu kesmeyecektir - yukarıdaki örneğimizde olduğu gibi, bu kuyruk aşırı derecede büyüdüğünde ne olur? İlk gelen işlere öncelik veriyor muyuz?

Dinamik kuyruk sistemimiz, genellikle bir tür öncelik nedeniyle, yürütülmeye hazır bir işin yürütülmeden önce uzun bir süre beklediği, iş açlığı adı verilen bir olguyu ele almaya çalışır. Basit bir "mesajlaşma" kuyruğunda öncelik, işin kuyruğa girdiği zamandır, yani büyük bir kuyruğun sonuna eklenen işler çok uzun bir süre bekleyebilir.

Bir kampanyayı ve tüm mesajlarını sıraya koyduğumuzda, işleri büyük bir "mesajlaşma" kuyruğuna eklemek yerine, sadece bu kampanya için özel bir adla tamamlanan tamamen yeni bir kuyruk oluştururuz, böylece ne olduğunu biliriz ve nasıl bulunur. İşleri kuyruğa ekledikten sonra “dinamik kuyruklar” listemizi alıyoruz ve bu yeni kuyruk adını sonuna ekliyoruz.

Bu stratejiyi kullanarak, çalışanlara “dinamik kuyruklar” listesinden bir dinamik kuyruğun adını almalarını ve ardından o belirli kuyruktaki tüm işleri işlemelerini isteyebiliriz. Bu, mesajların mümkün olduğunca hızlı bir şekilde gönderilmesini VE tüm müşterilerimize eşit öncelikle muamele edilmesini sağlamamızı sağlar.

Sonuç olarak, belirli çalışanlar için iş yerindeki artış nedeniyle bunun daha yüksek önbellek isabet oranları ve daha az veritabanı bağlantısı gibi başka faydaları da vardır. Herkes kazanır!

Daima Yedekleme Planınız Olsun

Bir veritabanı kapalı olduğunda, bazı kuyruklar duraklatıldığında ve iş kuyrukları dolmaya başladığında ne olur?

Bazen önemli altyapı parçaları sizin üzerinizde ölür. Yerinde ikinciller ve yedekler var, ancak yedekleme altyapısını geliştirmek için gereken süre neredeyse hiçbir zaman sıfır değildir. Tüm uygulama altyapısında birden çok sıra katmanına sahip olmak, bu tür olayların etkisini azaltmada çok yardımcı olabilir.

Kullandığımız böyle bir strateji, cihazların kendisinde sıraya girmektir. Milyonlarca cihazın Braze SDK kullanan farklı uygulamaları vardır ve bu uygulamalarda API'lerimize veri göndermek için bir kuyruk kullanırız.

SDK'mız bu verileri göndermeye gittiğinde ve herhangi bir nedenle başarısız olduğunda, SDK başarılı olana kadar üstel bir geri çekilme algoritması kullanarak yeniden denemeyi sıraya koyar. Bu strateji, altyapı veya kod arızalarının etkisini en aza indirir, çünkü cihazlar kendi verilerini kuyruğa alır ve her şey tekrar çevrimiçi olduğunda Braze'e gönderir.

Hızlı Hareket Etmek ve Eşyaları Kırmamak

Günün sonunda hedefimiz, herkesten daha iyi hiper odaklı, kişiselleştirilmiş mesajlar göndermektir ve bu, hızlı hareket etmeyi, esnek olmayı ve her şeyi doğru yapmayı içerir. İş kuyrukları Braze'in altyapısının kalbinde yer alır, bu nedenle her zaman performansımızı izliyor, en iyi uygulamaları kullanıyor ve oyunda en iyisi olmak için yeni stratejiler ve gelişmiş teknikler deniyoruz.

Pazarlama otomasyonu alanında bu tür yüksek performanslı, düşük gecikmeli sistem mühendisliği sizi heyecanlandırıyorsa, iş ilan panomuzu mutlaka kontrol etmelisiniz!