Günlük 2 milyar verinin işlenmesi, gerçek zamanlı kullanıcı davranışı hizmet sistemi mimarisi uygulaması
Temel bir hizmet olarak, Ctrip'in gerçek zamanlı kullanıcı davranışı hizmeti şu anda, neyi beğendiğinizi tahmin et (Ctrip'in öneri sistemi), dinamik reklamlar, kullanıcı portreleri, göz atma geçmişi vb. Gibi birden çok senaryoda yaygın olarak kullanılmaktadır.
Örnek olarak neyi sevdiğinizi tahmin edin. Tahmin edin neyi beğendiğiniz, uygulama içi kullanıcılara işlem verimliliğini artırmak için potansiyel seçenekler sunar. Seyahat kapsamlı bir taleptir ve kullanıcılar genellikle birden fazla ürüne ihtiyaç duyar. Tek noktadan seyahat hizmeti platformu olarak, çapraz iş hattı önerisi, özellikle gerçek zamanlı öneri, kullanıcıların ihtiyaçlarını gerçekten karşılayabilir.Bu nedenle, çeşitli iş hatlarını birbirine bağlamak için yukarı akış kullanıcı davranış verilerini sağlamak gerekir.
Ctrip'in orijinal gerçek zamanlı kullanıcı davranışı sisteminde aşağıdakiler dahil bazı sorunlar vardır: 1) Eksik veri kapsamı; 2) Veri çıktısının birleşik bir biçimi yoktur, bu da birçok kullanıcı için erişim maliyetlerini artırır; 3) Günlük işleme modülü, desteklenmesi zor bir web hizmetidir Trafik zirvelerinin ihtiyaçlarını karşılamak için çeşitli veri işleme stratejileri ve uygun genişletmenin gerçekleştirilmesi.
Son yıllarda turizm pazarı hızla büyüdü ve veri miktarı gittikçe büyüdü ve hızla büyümeye devam edecek. Giderek daha fazla kullanım gereksinimi vardır ve sistemin gerçek zamanlı ve kararlılığı için daha yüksek gereksinimler ortaya konmaktadır. Genel olarak, mevcut gereksinimler, sistemin gerçek zamanlı / kullanılabilirliği / performansı / ölçeklenebilirliği için yüksek gereksinimlere sahiptir.
1. Mimari
Bu arka plan altında sistemi aşağıdaki yapıya göre yeniden tasarladık:
Şekil 1: Gerçek zamanlı kullanıcı davranışı sisteminin mantıksal görünümü
Yeni mimaride, verilerin iki akış yönü vardır, işleme akışı ve çıktı akışı.
İşleme akışında, davranış günlüğü istemciden (Uygulama / Çevrimiçi / H5) sunucunun Toplayıcı Hizmetine yüklenecektir. Toplayıcı Hizmeti, mesajı dağıtılmış kuyruğa gönderir. Veri işleme modülü, akış hesaplama çerçevesi tarafından tamamlanır, dağıtılmış kuyruktaki verileri okur ve verileri işlemden sonra dağıtılmış bir önbellek ve bir veritabanı kümesinden oluşan veri katmanına yazar.
Çıktı akışı görece basittir. Web Hizmetinin arka ucu, verileri veri katmanından çeker ve arayan kişiye verir. Bazıları öneri sistemi gibi dahili hizmet çağrılarıdır ve bazıları tarama geçmişi gibi ön uca gönderilir. Sistem uygulaması Java + Kafka + Storm + Redis + MySQL + Tomcat + Spring teknoloji yığınını kullanır.
Java: Şu anda, şirketin dahili Java atmosferi nispeten güçlü ve Java nispeten olgun büyük veri bileşenlerine sahip
Kafka / Storm: Dağıtılmış bir mesaj kuyruğu olarak Kafka, şirkette olgun uygulamalara sahiptir.Akım hesaplama çerçevesi Storm da uygulanmıştır ve daha iyi bir işletim ve bakım destek ortamına sahiptir.
Redis: Redis'in HA, SortedSet ve süresi dolan özellikleri sistemin ihtiyaçlarını daha iyi karşılar.
MySQL: Temel bir sistem olarak kararlılık ve performans da sistemin iki ana göstergesidir.HBase ve ElasticSearch gibi NoSQL'in ana seçenekleriyle karşılaştırıldığında, MySQL bu iki açıdan milyarlarca veri düzeyinde daha iyi performansa sahiptir ve iyi olacak şekilde tasarlanabilir Yatay genişleme yeteneği.
Şu anda, sistem her gün yaklaşık 2 milyar veriyi işliyor ve çevrimiçi verilerden kullanılabilir verilere kadar geçen süre yaklaşık 300 milisaniyedir. Sorgu hizmeti, ortalama 6 milisaniye gecikmeyle her gün yaklaşık 80 milyon isteğe hizmet verir. Aşağıda, gerçek zamanlı / kullanılabilirlik / performans / dağıtım gibi çeşitli boyutlardan sistem tasarımı açıklanmaktadır.
İkincisi, gerçek zamanlı
Gerçek zamanlı bir sistem olarak, gerçek zamanlı birincil göstergedir. Çevrimiçi sistem çeşitli anormal durumlarla karşı karşıyadır. Örneğin, aşağıdaki durumlar:
Ani trafik yoğunluğuyla nasıl başa çıkılır;
Başarısız veri veya hatalı modüller durumunda, başarısız verilerin yeniden denenmesinin nasıl sağlanacağı ve aynı zamanda yeni verilerin işlenmesinin nasıl sağlanacağı;
Çevresel sorunlar veya hatalar veri birikimine neden olur, bunların nasıl hızla çözüleceği;
Program hataları, eski verilerin yeniden işlenmesi gerekir, yeni verilerin nasıl hızlı bir şekilde işleneceği ve nasıl sağlanacağı;
Sistem, tasarımın başından itibaren yukarıdaki durumu dikkate almıştır.
Birincisi, ani trafik zirveleri sorununu çözmek için fırtına kullanmaktır. Fırtına şu özelliklere sahiptir:
Şekil 2: Fırtına özellikleri
Bir akış hesaplama çerçevesi olarak, erken büyük veri işlemenin toplu işleme çerçevesinden açıkça farklıdır. Akış işleme çerçevesi sürekli çalışırken toplu işleme çerçevesi, bir görevi gerçekleştirdikten sonra çalışmayı bitirir.Teoride, asla durmaz ve işlem granülerliği mesaj seviyesidir. Bu nedenle, sistem yeterli hesaplama gücüne sahip olduğu sürece, her mesajın işlenmesini sağlayabilir. Bir anda keşfedildi ve işlendi.
Mevcut sistem için, fırtına işleme çerçevesi aracılığıyla, mesajlar Kafka'ya girdikten sonra milisaniye düzeyinde işlenebilir. Ek olarak, Storm'un güçlü bir ölçek genişletme özelliği vardır. Arka planda çalışan parametrelerinin sayısını değiştirdiğiniz ve topolojiyi (fırtınanın görevinin adı) yeniden başlattığınız sürece, ani trafik artışlarıyla başa çıkmak için hesaplama gücünü hemen artırabilirsiniz.
Storm, en az bir kez, en fazla bir kez ve tam olarak bir kez olmak üzere mesaj işleme için birden fazla veri garantisi stratejisini destekler. Gerçek zamanlı kullanıcı davranışı için ilk şey, verilerin olabildiğince az kaybolmasını sağlamaktır.Ayrıca, yeniden denemeler ve eski sürüme geçme dahil olmak üzere birden çok veri işleme stratejisini destekler. Bu, tam olarak bir kez avantaj sağlamaz, bunun yerine işlem desteği nedeniyle performansı düşürür, dolayısıyla gerçek zamanlı kullanıcılar Davranış sistemi tarafından en az bir kez benimsenen strateji. Mesajlar bu strateji altında yeniden gönderilebilir, bu nedenle program işleme idempotent desteğini uygular.
Stormun sürümü nispeten basittir. Güncelleme programı jar paketini yükleyin ve bir sürümü tamamlamak için görevi yeniden başlatın. Ne yazık ki, çok sürümlü gri tonlamalı sürüm için destek yok.
Şekil 3: Fırtına mimarisi
Bazı durumlarda, veritabanı bağlantısı zaman aşımı veya bağlantı hatası gibi veri işlemenin yeniden denenmesi gerekir. Bağlantı zaman aşımı, hemen yeniden denenerek geri yüklenebilir, ancak bağlanamama genellikle ağın veya veritabanının kurtarılmasını beklemek için daha uzun sürer.Bu durumda, işleme programı sonsuza kadar bekleyemez, aksi takdirde veri gecikmesine neden olur. Gerçek zamanlı kullanıcı davranış sistemi, bu sorunu çözmek için çift kuyruklu bir tasarım kullanır.
Şekil 4: Çift sıra tasarımı
Üretici, davranış kaydını Kuyruk1'e yazar (esas olarak verileri taze tutar) ve Çalışan, Kuyruk1'den yeni verileri tüketir. Yukarıdaki anormal veriler meydana gelirse, Çalışan anormal verileri Kuyruk2'ye yazar (çoğunlukla anormal verileri tutar).
Bu şekilde, çalışanın Kuyruk1'deki tüketim ilerlemesi anormal verilerden etkilenmeyecek ve yeni verilerin tüketimi korunabilecektir. RetryWorker, Queue2'yi izleyecek ve anormal verileri tüketecektir.İşleme başarılı değilse, anormal verileri belirli bir stratejiye göre (aşağıdaki şekilde gösterildiği gibi) Queue2'ye bekleyecek veya yeniden yazacaktır.
Şekil 5: Tazminat yeniden deneme stratejisi
Ek olarak, bir veri birikimi durumunda, Çalışanın tüketim imleci, en son verilerin işlenmesini sağlamak için tüketimi en son verilerden yeniden başlatmak üzere ayarlanabilir. Ortadaki işlenmemiş veri parçası backupWorker'ı başlatır ve başlangıç ve bitiş imleçlerini belirtir Belirtilen aralıktaki veriler tüketildikten sonra, backupWorker otomatik olarak durur.
Şekil 6: Bekleme listesi verilerini çözme
Üç, kullanılabilirlik
Temel bir hizmet olarak, kullanılabilirlik gereksinimleri genel hizmetlerden çok daha yüksektir çünkü buna bağlı birçok alt hizmet vardır.Bir arıza meydana geldiğinde, kademeli reaksiyonlara neden olabilir ve çok sayıda işletmeyi etkileyebilir. Proje, sistemin kullanılabilirliğini sağlamak için tasarımdan aşağıdaki konuları ele almıştır:
Sistemin tek bir noktası var mı?
Peki ya DB genişletme / bakım / arıza?
Redis bakım / yükseltme yamaları ne olacak?
Hizmet kapalıysa nasıl hızlı bir şekilde kurtarılır? Aşağı akış uygulamaları nasıl en aza indirilir?
Birincisi, sistem düzeyinde tam yığın kümelemedir. Kafka ve Storm kendileri göreceli olarak olgun bir şekilde kümelenmiş işlem ve bakımı destekler; web hizmetleri, durumsuz işlemeyi destekler ve yük dengeleme yoluyla kümelemeyi gerçekleştirir; Redis ve DB Ctrip zaten aktif / yedek dağıtımı destekler. Ana bilgisayar kullanım sırasında başarısız olursa, yedekleme fırsatı otomatik olacaktır. Hizmeti devralın; tam yığın kümeleme garanti sistemi sayesinde tek bir nokta yoktur.
Ek olarak, sistem, bazı modüller kullanılamadığında sürüm düşürme işlemi yoluyla tüm sistemin kullanılabilirliğini garanti eder. Önce normal veri işleme akışına bakın: (aşağıda gösterildiği gibi)
Şekil 7: Normal veri akışı
Sistemin normal durumunda Storm, Kafka'dan veri okuyacak ve bunları sırasıyla redis ve mysql'e yazacaktır. Hizmet redis'ten çekilir (mevcut değilse db'den telafi edilir) ve istemciye verilir. DB sürüm düşürme durumunda, veri akışı da değişecektir (aşağıda gösterildiği gibi)
Şekil 8: Sistem sürüm düşürme-DB
Mysql kullanılamadığında, db downgrade anahtarını açarak, Storm normalde redis yazacak, ancak artık mysql'e veri yazmayacaktır. Reidlere giren veriler sorgu servisi tarafından kullanılabilir ve müşteriye sağlanabilir. Ek olarak, Storm verilerin bir kopyasını Kafka'nın yeniden deneme kuyruğuna yazacak.Mysql normal hizmete girdikten sonra, db downgrade anahtarını kapatarak Storm, yeniden deneme kuyruğundaki verileri tüketecek ve verileri mysql'e yazacaktır. Redis ve mysql verileri, sürüm düşürme sırasında tutarsız olacaktır, ancak sistem normale döndükten sonra yeniden deneme, verilerin nihai tutarlılığını sağlayacaktır. Redis'in sürüm düşürme işlemi de benzerdir (aşağıda gösterildiği gibi)
Şekil 9: Sistem düşürme-Redis
Tek fark, Redis'in hizmet yeteneklerinin MySQL'i çok aşmasıdır. Bu nedenle, Redis düşürüldüğünde, sistemin verimi düşer. Şu anda, db basıncını izleyeceğiz.MySQL'in yüksek baskı altında olduğunu tespit edersek, sorgu hizmetinin kararlılığını sağlamak için MySQL üzerindeki baskıyı azaltmak için veri yazmayı geçici olarak durduracağız.
Arızanın aşağı akış üzerindeki etkisini azaltmak için sorgu hizmeti, Netflix'in Hystrix bileşeni (aşağıda gösterildiği gibi) aracılığıyla sigorta modunu destekler.
Şekil 10: Devre Kesici Düzeni
Bu modda, servis arızası talebi belirli bir süre içinde bir eşiği aştığında, sigorta anahtarı açılacaktır. Anahtar açıldığında, hizmet sonraki isteklere doğrudan bir hata yanıtı verir ve sunucu üzerindeki baskının daha da artmasını ve çığlara neden olmasını önlemek için istek iş modülü tarafından işlenmez ve uzun yanıt süresi nedeniyle arayanı aşağı sürüklemez.
Anahtar açıldıktan sonra, zamanlamaya başlayacaktır. Zaman aşımından sonra Yarı Açık durumuna girecektir. Bu durumda, bir isteğin iş işleme modülüne geçmesine ve girmesine izin verilecektir. Normal olarak geri dönebiliyorsa, anahtar kapatılacak, aksi takdirde anahtar bir sonraki zaman aşımına kadar açık kalacaktır. Bu şekilde, iş yeniden başladıktan sonra talep normal şekilde karşılanabilir.
Ek olarak, tek bir arayanın yasadışı aramasının hizmeti etkilemesini önlemek için hizmet, arayan AppId / ip akım sınırlaması, hizmet akımı sınırlaması ve arabirim akımı sınırlaması dahil olmak üzere mevcut sınırlamanın birden çok boyutunu da destekler.
Dördüncü olarak, performans artışı
Son yıllarda çevrimiçi seyahat endüstrisinin hızlı büyümesi nedeniyle, endüstri lideri olarak Ctrip de gelişti, bu nedenle ziyaret ve veri sayısı da önemli ölçüde arttı. Şirketin iş gereksinimi, 10 kat kapasite artırımını desteklemektir.Genişlemenin en zor kısmı, mevcut verilerin taşınmasını içerdiği için veri katmanındadır.
Gerçek zamanlı kullanıcı davranışı sisteminin veri katmanı Redis ve MySQL'i içerir.Redis tutarlı bir hash uyguladığından, yalnızca kapasiteyi genişletirken makine eklemeniz ve yeni bölüme tahsis edilen verilerin telafisini okumanız gerekir.
MySQL için, genişletme hazırlığı olarak yatay bölümleme de yaptık.Kırık sayısının n'inci kuvvete göre 2 olduğu düşünülür.Bu, genişlemede bariz avantajlara sahiptir. Ctrip'in mysql veritabanı artık genel olarak bir-ana-bir-yedekleme yöntemini benimsediğinden, yedekleme makinesi genişletilirken doğrudan ikinci (grup) ana bilgisayara seviyelendirilebilir. S0 sunucusuna yerleştirilmiş d0 ve d1 olmak üzere iki kitaplık olduğunu ve s0'ın bir yedek makine s1'e sahip olduğunu varsayalım. Genişletme yalnızca aşağıdaki adımları gerektirir:
Emin olun s0- > s1, önemli bir gecikme olmaksızın sorunsuz bir şekilde senkronize olur
s0, okuma ve yazma izinlerini geçici olarak kapatır
S1'in s0 güncellemesiyle tamamen senkronize olduğunu onaylayın
s1 açık okuma ve yazma izinleri
D1'in dns'si s0'dan s1'e değiştirilir
s0 açık okuma ve yazma izinleri
Geçiş süreci, sıkıcı ve hataya açık manuel senkronizasyon sürecini önlemek için MySQL'in çoğaltma ve dağıtım özelliklerini kullanır, bu da taşıma maliyetini ve süresini büyük ölçüde azaltır. Tüm işlem süreci, DB düşürme işleviyle birlikte birkaç dakika içinde tamamlanabilir, yalnızca birkaç saniye DNS anahtarlaması bir anormallik üretecektir.
Tüm süreç nispeten basit ve kullanışlıdır, işletim ve bakım yükünü azaltır ve bir dereceye kadar, benzer GitLab tarzı trajedilere neden olan aşırı işlem olasılığını da azaltabilir.
Beş, dağıtım
Daha önce de belirtildiği gibi, yükleme ve yeniden başlatma dağıtımı tamamlayabildiği sürece Storm dağıtımı daha kullanışlıdır. Dağıtımdan sonra, programın yeniden başlatılmasının içeriğinin kaybı nedeniyle, önceki işlem konumu Kafka tarafından kaydedilen imleç aracılığıyla bulunabilir ve işleme devam edilebilir.
Ek olarak, bazı durumlarda, programın birden çok sürümde çalışması gerekebilir.Örneğin, geçici olarak davranış kayıtlarının birden çok sürümü vardır Bu durumda, bir backupJob ekleyip geçmiş sürümü backupJob'da çalıştıracağız.
