g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Alibaba mühendisleri, girişimlerin 5 büyük Java hizmeti ikilemini nasıl ortadan kaldırabilir?

Alimei'nin Kılavuzu: Bir startup şirketinin karşılaştığı her sorun bir ölüm kalım meselesi olabilir. İşin başında sektörün ortak sorunlarını özetlemeli ve en uygun çözümü bulmak için çözümleri karşılaştırmalısınız. Alibaba harita teknolojisi uzmanları, genellikle birkaç yıl boyunca teknoloji çemberinde olmayı amaçlamaktadır ve çeşitli Java sunucu mimarilerine maruz kalmıştır. Daha fazla sunucu tarafı sorunu vardır, bu nedenle çeşitli çözümlerin artılarını ve eksilerini daha iyi ayırt edebilirsiniz. Bugün, Chang Yi ilk 5 girişimin Java sunucu sorunlarını özetledi ve referansınız için geçici olarak bazı çözümler sundu.

1. Sistem dağıtılmıyor

1.1. Bağımsız sistem için kapma emri durumları

Yukarıdaki kod bir sunucuda sorunsuz çalışır. GrabOrder (sipariş al) işlevini girerken, tüm işlevi kilitlemek için senkronize edilmiş anahtar kelimeyi kullanın. Ya işleve girmeden önce sipariş alınmadı, bu nedenle sipariş başarıyla alındı ya da işleve girmeden önce sipariş alındı ve sipariş başarısız oldu, kesinlikle İşleve girmeden emrin alınmadığı ancak işleve girdikten sonra emrin tekrar alındığı bir durum olmayacaktır.

Ancak yukarıdaki kod aynı anda iki sunucuda çalıştırılırsa, senkronize edilmiş Java anahtar kelimesi yalnızca bir sanal makinede etkili olduğundan, iki kişinin aynı anda bir sipariş almasına neden olacak, ancak sonuncuyu veritabanına yazacaktır. Veriler geçerli olacaktır. Bu nedenle, çoğu bağımsız sistem dağıtılmış sistemler olarak çalıştırılamaz.

1.2. Dağıtık sistemlerde kapma emirleri vakaları

Kod optimizasyonu için dağıtılmış kilitler ekleyin:

Optimize edilmiş kod, temelde bağımsız sürümün senkronize anahtar kelime kilitleme etkisiyle aynı olan, grabOrderWithoutLock (kilitsiz kapma sırası) işlevini çağırmadan önce ve sonra kilidi kilitlemek ve serbest bırakmak için dağıtılmış kilit sırasını kullanır (dağıtılmış kilit siparişi) aynı.

1.3. Dağıtık sistemlerin avantajları ve dezavantajları

Dağıtık Sistem, dağıtılmış işlemeyi destekleyen bir yazılım sistemidir, Dağıtılmış bir işletim sistemi, dağıtılmış bir programlama dili ve derleme sistemi, dağıtılmış bir dosya sistemi, dağıtılmış bir veritabanı sistemi vb. Dahil olmak üzere bir iletişim ağı ile birbirine bağlanan çok işlemcili bir mimaride görevleri gerçekleştiren bir sistemdir.

Dağıtılmış sistemin avantajları:

Güvenilirlik ve yüksek hata toleransı: Bir sunucunun çökmesi diğer sunucuları etkilemez ve diğer sunucular yine de hizmet sağlayabilir.
Ölçeklenebilirlik: Sistem hizmet kapasitesi yetersizse, daha fazla sunucu yatay olarak genişletilebilir.
Esneklik: Sistem kolaylıkla kurulabilir, uygulanabilir, genişletilebilir ve yükseltilebilir.
Yüksek performans: Tek bir sunucudan daha hızlı olan birden fazla sunucunun bilgi işlem gücüne sahiptir.
Yüksek maliyet performansı: Dağıtılmış sistemler, sunucu donanımı için çok düşük gereksinimlere sahiptir. Ucuz sunucular, daha iyi maliyet performansı elde etmek için dağıtılmış kümeler oluşturmak için kullanılabilir.

Dağıtılmış sistemlerin dezavantajları:

Sorun gidermede zorluk: Sistem birden fazla sunucuya dağıtıldığı için sorun giderme ve sorun teşhisi zordur.
Daha az yazılım desteği: Dağıtılmış sistem çözümleri için daha az yazılım desteği.
Yüksek inşaat maliyeti: Dağıtılmış bir sistem oluşturmak için birden çok sunucu gerekir.

Bir keresinde birçok arkadaş bana sordu: "Mobil uygulamalar için dış kaynak ararken nelere dikkat etmeliyim?"

İlk olarak, dağıtılmış bir sistem kullanmanız gerekip gerekmediğini belirleyin. Yazılım bütçesi nedir? Tahmini kullanıcı sayısı nedir? Tahmini ziyaret sayısı nedir? İşletmenin sadece pilot versiyonu mu? Tek bir sunucu çözülebilir mi? Kısa vadeli kesinti yaşıyor musunuz? Bağımsız sistem kapsamlı bir değerlendirme ile çözülebiliyorsa, dağıtılmış sistemi kullanmayın. Bağımsız sistem ve dağıtılmış sistem çok farklı olduğundan, karşılık gelen yazılım geliştirme maliyetleri de çok farklıdır.

İkinci olarak, bunun gerçekten dağıtılmış bir sistem olup olmadığını belirleyin. Dağıtık bir sistemin en büyük özelliği, sistemin servis kapasitesi yetersiz kaldığında, yatay genişleme ile sunucular ekleyerek servis kapasitesini artırabilmesidir. Ancak, bağımsız sistem yatay genişletmeyi desteklemez ve zorunlu genişletme bir dizi veri sorununa neden olur. Bağımsız sistemlerin ve dağıtılmış sistemlerin Ar-Ge maliyetleri oldukça farklı olduğundan, piyasadaki çoğu dış kaynak ekibi dağıtım için dağıtılmış sistemler yerine bağımsız sistemler kullanır.

Peki, sisteminizin gerçekten dağıtılmış bir sistem olduğunu nasıl belirlersiniz? Yazılım açısından, dağıtılmış bir yazılım çözümünün benimsenip benimsenmediği; donanım açısından, dağıtılmış bir donanım dağıtım çözümünün benimsenip benimsenmediği.

1.4. Dağıtılmış yazılım çözümleri

Nitelikli bir dağıtılmış sistem olarak, gerçek ihtiyaçlara göre ilgili dağıtılmış yazılım çözümlerini benimsemek gerekir.

1.4.1 Dağıtılmış kilit

Dağıtılmış kilit, bağımsız kilidin bir uzantısıdır ve farklı hizmetler arasında mantık ve veri tutarlılığını sağlamak için dağıtılmış bir sistemdeki fiziksel blokları veya mantıksal blokları kilitlemek için kullanılır.

Şu anda, dağıtılmış kilitlerin üç temel uygulaması vardır:

Veritabanı uygulamasına dayalı dağıtılmış kilit;

Redis'e dayalı dağıtılmış kilit;

Zookeeper'a göre dağıtılmış kilit.

1.4.2 Dağıtılmış mesajlaşma

Dağıtılmış mesaj ara yazılımı, dağıtılmış bir sistemde mesaj göndermeyi ve almayı destekleyen bir yazılım altyapısıdır. Yaygın dağıtılmış mesajlaşma ara yazılımları arasında ActiveMQ, RabbitMQ, Kafka, MetaQ vb. Bulunur.

MetaQ (tam adı Metamorphosis), yüksek performanslı, yüksek oranda erişilebilir ve ölçeklenebilir bir dağıtılmış mesajlaşma ara yazılımıdır. Fikir LinkedIn'in Kafka'sından doğmuştur, ancak Kafka'nın bir kopyası değildir. MetaQ, mesaj depolama sıralı yazma, büyük verim ve yerel ve XA işlemleri için destek özelliklerine sahiptir ve büyük verim, sıralı mesaj, yayın ve günlük veri iletimi gibi senaryolar için uygundur.

1.4.3 Veritabanı Kırma Grubu

Büyük miktarda veriye sahip veritabanları için, "parçalama gruplama" stratejisi genellikle benimsenir:

Shard: Esas olarak ölçeklenebilirlik sorununu çözer ve yatay bölünmeye aittir. Parçalanmanın tanıtımı, veri yönlendirme ve bölümleme anahtarları kavramlarını tanıtır. Bunlar arasında, alt tablo aşırı veri hacmi sorununu çözer ve alt veritabanı, veritabanı performans darboğazı sorununu çözer.

Grup: Esas olarak, ana-bağımlı çoğaltma ile gerçekleştirilen kullanılabilirlik sorunlarını çözer ve veritabanı performansını iyileştirmek için okuma-yazma ayırma stratejileri sağlar.

1.4.4 Dağıtık Hesaplama

Dağıtılmış hesaplama, "büyük miktarda hesaplama gerektiren mühendislik verilerini, birden çok bilgisayar tarafından hesaplanan küçük parçalara bölme bilimidir; hesaplamaların sonuçlarını yükledikten sonra, sonuçlar birleştirilmiş ve bir veri sonucuna ulaşmak için birleştirilir".

Mevcut yüksek performanslı sunucular büyük miktarda veri işlerken, işlem gücü, bellek kapasitesi ve diğer göstergeler gereksinimleri karşılamaktan uzaktır. Büyük veri çağında mühendisler, dağıtılmış hizmet kümeleri oluşturmak için ucuz sunucular kullanırlar ve bilgi işlem ve depolamadaki tek bir sunucunun darboğazını çözmek için büyük verilerin iş birliğine dayalı bir şekilde işlenmesini tamamlarlar. Hadoop, Storm ve Spark yaygın olarak kullanılan dağıtılmış bilgi işlem ara yazılımlarıdır. Hadoop, gerçek zamanlı olmayan verilerin toplu olarak işlenmesi için bir ara yazılımdır ve Storm ve Spark, gerçek zamanlı veri akışı için ara yazılımlardır.

Ek olarak, burada tanıtılmayacak daha dağıtık yazılım çözümleri vardır.

1.5 Dağıtılmış donanım dağıtım şeması

Dağıtık yazılım çözümünü sunucu tarafında tanıttıktan sonra, sunucu tarafında dağıtılmış donanım dağıtım çözümünü tanıtmam gerekiyor. Burada sadece ortak arayüz sunucusu, MySQL veritabanı, sunucu tarafında Redis önbelleği çizilir ve diğer bulut depolama hizmetleri, mesaj kuyruğu hizmetleri, günlük sistemi hizmetleri ...

1.5.1 Genel bağımsız dağıtım planı

Mimari açıklama: Yalnızca 1 arayüz sunucusu, 1 MySQL veritabanı ve 1 isteğe bağlı Redis önbelleği vardır ve bunların tümü aynı sunucuda konuşlandırılabilir.

Uygulama kapsamı: arıza süresinden korkmayan ve günlük PV değeri 50.000'den az olan gösteri ortamları, test ortamları ve küçük işletme uygulamaları için uygundur.

1.5.2 Küçük ve orta ölçekli dağıtılmış donanım dağıtım planı

Mimari açıklama: SLB / Nginx aracılığıyla bir yük dengeli arayüz sunucu kümesi oluşturulur ve MySQL veritabanı ve Redis önbelleği, bir birincil ve bir yedek (veya çoklu bekleme) dağıtım modunu benimser.

Uygulama kapsamı: Günlük 5 milyon içinde PV ile küçük ve orta ölçekli ticari uygulamalar için uygundur.

1.5.3 Büyük ölçekli dağıtılmış donanım dağıtım şeması

Mimari açıklama: SLB / Nginx aracılığıyla bir yük dengeli arayüz sunucu kümesi oluşturulur ve parçalanma gruplama stratejisi kullanılarak bir MySQL veritabanı kümesi ve Redis önbellek kümesi oluşturulur.

Uygulama kapsamı: Günlük 5 milyonun üzerinde PV ile büyük ölçekli ticari uygulamalar için uygundur.

2. Çoklu iş parçacığının yanlış kullanımı

Çoklu okumanın temel amacı, seri süreci paralel bir sürece dönüştürebilen ve böylece programın yürütme verimliliğini artıran "CPU kaynaklarının kullanımını en üst düzeye çıkarmaktır".

2.1 Yavaş bir arayüz durumu

Diyelim ki, kullanıcı oturum açtığında, yeni bir kullanıcıysa, kullanıcı bilgilerinin oluşturulması ve yeni kullanıcı kuponlarının verilmesi gerektiğini varsayalım. Örnek kod aşağıdaki gibidir:

Bunların arasında, bağlama Kuponu, kullanıcıya yeni bir kullanıcı kuponu bağlamak ve ardından kullanıcıya bir push bildirimi göndermektir. Kupon sayısı artarsa, işlev yavaşlar ve yavaşlar, yürütme süresi 1 saniyeyi bile geçebilir ve optimizasyona yer kalmaz. Şimdi, oturum açma işlevi gerçek bir yavaş arayüz haline geldi ve arayüz optimizasyonu gerektiriyor.

2.2 Çok iş parçacıklı optimizasyonu benimseyin

Analiz sayesinde, bindCoupon işlevinin eşzamansız olarak çalıştırılabileceği bulundu. Akla gelen ilk şey problemi çözmek için multithreading kullanmaktır, kod aşağıdaki gibidir:

Şimdi, bindCoupon işlevi, kullanıcı oturum açma işlevinin performansını büyük ölçüde artıran yeni bir iş parçacığında yürütülür. Bununla birlikte, sistem yeni kullanımda bağlama kupon fonksiyonunun yürütülmesi sırasında yeniden başlar veya çökerse ve kullanım işlemi başarısız olursa, kullanıcı yeni kullanıcı kuponunu asla almayacaktır. Kullanıcıya kuponları manuel olarak almak için bir sayfa sağlanmadıkça, programcının kuponları arka planda manuel olarak bağlaması gerekir. Bu nedenle, yavaş arayüzü optimize etmek için çoklu iş parçacığı kullanmak mükemmel bir çözüm değildir.

2.3 Mesaj kuyruğu optimizasyonunu kullanın

Bağlı kupon işlevinin yürütülmesinin, yürütme başarısız olduktan sonra yeniden başlatılabilmesini sağlamak istiyorsanız, veritabanı tabloları, Redis kuyrukları ve ileti kuyrukları gibi birden çok çözümü kullanabilirsiniz. Alan önceliği nedeniyle, burada yalnızca MetaQ ileti kuyruğu çözümü tanıtıldı ve MetaQ ile ilgili yapılandırma atlandı ve yalnızca çekirdek kod verildi.

Mesaj üretici kodu:

Not: Mesaj başarısız olabilir, ancak bu olasılık nispeten düşüktür.

Mesaj tüketici kodu:

Çözüm avantajları: MetaQ mesaj kuyruğu optimizasyonu yavaş arayüz çözümünün avantajlarını toplayın:

Sistem yeniden başlarsa veya çökerse, mesaj işleme işlevinin yürütülmesinin başarısız olmasına neden olur, mesajın tüketildiğini onaylamaz; MetaQ aynı kuyruğa abone olmak için birden fazla hizmeti desteklediğinden, mesaj tüketim için başka bir hizmete aktarılabilir veya hizmet normale dönene kadar beklenebilir. Tüketim yapın.

Tüketiciler, birden çok hizmet ve birden çok iş parçacığı içeren iletileri tüketebilir.İleti işleme süresi uzun olsa bile, bir ileti birikimine neden olmak kolay değildir; bir ileti birikimine neden olsa bile, hizmet örneklerini genişleterek çözülebilir.

Mesajı tekrar kullanmanız gerekirse, MetaQ yönetim platformunda "Mesaj Doğrulama" yı tıklamanız yeterlidir.

3. Mantıksız süreç tanımı

3.1. Orijinal tedarik süreci

Bu basit bir tedarik sürecidir, depo yönetim sistemi satın alma işlemini başlatır, alıcı satın almaya başlar ve alıcı satın almayı tamamlar, aynı zamanda tahsilat emri depo yönetim sistemine iade edilir.

Bunların arasında, satın alma işlemini tamamlamak için gereken temel kod aşağıdaki gibidir:

BackflowPurchaseOrder (geri akış satın alma siparişi) işlevi HTTP arayüzünü çağırdığından, aşağıdaki sorunlara neden olabilir:

Bu işlev uzun zaman alabilir ve tedarik arayüzünün tamamlanmasının yavaş bir arayüz haline gelmesine neden olabilir;

Bu işlev başarısız olabilir ve bir istisna atarak müşterinin tam satın alma arayüzünü aramamasına neden olabilir.

3.2. Optimize edilmiş tedarik süreci

Talep analizi yoluyla, "satın alan satın alma işlemini tamamlar ve iade toplama siparişi" eylemi iki ayrı eyleme bölünür, "alıcı satın almayı tamamlar" ve "iade toplama emri" ve "satın alma tamamlandı", "satın alma tamamlandı" ve İki bağımsız "yeniden akış tamamlandı" durumu, tedarik sürecinin yönetilmesini ve uygulanmasını kolaylaştırır.

Tedarik sürecinin eylemlerini ve durumlarını böldükten sonra, temel kod aşağıdaki gibidir:

Bunların arasında executeBackflow (yürütme geri akışı) işlevi, işin yürütülmesinin zamanlaması tarafından tetiklenir. Yeniden akış satın alma siparişi başarısız olursa, satın alma emri durumu "yeniden düzenlenmiş" olarak değiştirilmez; bir sonraki zamanlanmış iş yürütüldüğünde, yeniden akış satın alma siparişi başarılı olana kadar yeniden düzenleme eylemi devam eder.

3.3. Sonlu Durum Makinelerine Giriş

3.3.1 Konsept

Sonlu durum otomatı veya kısaca durum makinesi olarak da bilinen sonlu durum makinesi (Sonlu durum makinesi, FSM), bu durumlar arasındaki geçişler ve eylemler gibi sonlu sayıda durumu ve davranışı temsil eden matematiksel bir modeldir.

3.3.2 Öğeler

Durum makinesi 4 unsur halinde özetlenebilir: mevcut durum, durum, eylem ve ikinci durum.

Mevcut durum: başlangıç, orta ve bitiş durumları dahil olmak üzere mevcut işlemin durumunu ifade eder.

Koşul: Aynı zamanda bir olay olarak da adlandırılabilir; bir koşul karşılandığında, bir eylem tetiklenecek ve bir durum geçişi gerçekleştirilecektir.

Eylem: Koşul karşılandığında yürütülecek eylem. Eylem yürütüldükten sonra yeni bir duruma taşınabilir veya orijinal durumunda kalabilir.

İkinci durum: Koşul karşılandığında taşınacak durum. "İkinci durum", "mevcut durum" ile ilgilidir Aktive edildiğinde, "ikinci durum" yeni bir "mevcut duruma" dönüşür.

3.3.3 Durum

Durum, süreçteki kalıcı durumu temsil eder ve akış şemasındaki her daire bir durumu temsil eder.

Başlangıç durumu: sürecin başında belirli bir durum;

Orta durum: sürecin ortasındaki durum;

Son durum: İşlemin tamamlandığı durum.

Öneriler:

Devlet, geçici bir devlet değil, kalıcı bir devlet olmalıdır;

Nihai durum bir ara durum olamaz ve sürecin akışı devam ettirilemez;

Eyalet bölünmesi makuldür, birden çok eyaleti tek bir eyalete zorlamayın;

Durum olabildiğince kısadır ve aynı durumun farklı durumları başka alanlarla temsil edilebilir.

3.3.4 Eylem

Üç eylem öğesi: rol, mevcut durum ve ikinci durum Akış şemasındaki her satır bir eylemi temsil eder.

Rol: Bir kullanıcı, zamanlanmış bir görev vb. Olabilen bu işlemi kim başlattı;

Mevcut durum: Eylemin gerçekleştirilmesi için bir ön koşul olan, eylemin tetiklendiği mevcut durum;

İkinci durum: Eylemin gerçekleştirilmesinin nihai amacı olan eylemi tamamladıktan sonra ulaşılan durum.

Öneriler:

Her eylem yürütülmeden önce, mevcut durum ile tetikleme eyleminin durumu arasındaki tutarlılık kontrol edilmelidir;

Durum makinesinin durumu yalnızca eylemler yoluyla değiştirilebilir ve diğer işlemler spesifikasyona uygun değildir;

Eylemlerin atomikliğini sağlamak için dağıtılmış kilitler eklemeniz ve veri tutarlılığını sağlamak için veritabanı işlemleri eklemeniz gerekir;

Benzer eylemler (çalışan kullanıcılar, istek parametreleri, eylem anlamları vb.) Tek bir eylemde birleştirilebilir ve eylemin sonucuna göre farklı durumlara geçilebilir.

4. Sistemler arasındaki etkileşim bilimsel değildir

4.1. Veritabanı aracılığıyla doğrudan etkileşim

Bazı projelerde, sistemler arasındaki etkileşim, arayüz çağrıları ve mesaj kuyrukları aracılığıyla değil, doğrudan veritabanı üzerinden gerçekleşir. Nedeni soruldu ve cevap verdi: "Proje programı çok sıkı. Veritabanına doğrudan erişim basit ve hızlı."

Yukarıdaki tedarik sürecini örnek olarak alın - satınalma siparişi depo yönetim sistemi tarafından başlatılır ve satın alma sistemi satın alma işleminden sorumludur.Satın alma işlemi tamamlandıktan sonra depo yönetim sistemine bildirilir ve depo yönetim sistemi depo operasyonuna girer. Satın alma sistemi satın almayı tamamladıktan sonra kütüphane yönetim sistemi veri tabanına bildirimde bulunacak kod aşağıdaki gibidir:

Bunlar arasında, kütüphane yönetim sisteminin veritabanı tablosuna rawPurchaseOrderDAO (orijinal satın alma siparişi DAO) aracılığıyla doğrudan erişin ve orijinal satın alma siparişinin durumunu tamamlandı olarak ayarlayın.

Normal şartlar altında, doğrudan veri erişiminde sorun yoktur. Ancak, bir yarış durumu oluştuğunda, veriler senkronize olmayacaktır. Bazı insanlar, bu sorunu çözmek için aynı dağıtılmış kilidi kullanmayı düşünebileceğinizi söyleyecektir. Evet, bu çözümde bir sorun yok ancak dağıtılmış kilitler sistemler arasında paylaşılıyor.

Doğrudan veritabanı üzerinden etkileşimde bulunmanın dezavantajları:

Veritabanı tablolarının doğrudan açığa çıkması, kolayca veri güvenliği sorunlarına neden olabilir;

Aynı veritabanı tablosunu çalıştıran birden çok sistem, veritabanı tablosu verilerinde kolaylıkla karışıklığa neden olabilir;

Aynı veritabanı tablosunu çalıştırma kodu, yönetim ve bakım için uygun olmayan farklı sistemlere dağıtılmıştır;

Veritabanı tabloları gibi güçlü ilişkiler ile sistemler arasında izolasyon ve dekuplaj sağlanamaz.

4.2. Dubbo arayüzü üzerinden etkileşim

Tedarik sistemi ve kütüphane yönetim sisteminin her ikisi de dahili sistemler olduğundan, Dubbo'ya benzer RPC arayüzleri üzerinden etkileşim kurabilirler.

Kütüphane yönetim sistemi kodu:

Bunların arasında, kütüphane yönetim sistemi, Satınalma Siparişi Hizmeti (satınalma siparişi hizmeti uygulaması) Dubbo aracılığıyla Satınalma Sipariş Hizmeti (satın alma siparişi hizmeti arabirimi) tarafından tanımlanan arayüz hizmeti aracılığıyla Satınalma Sipariş Hizmeti Hizmet Uygulamasını (satınalma siparişi hizmet uygulaması) tedarik sistemine sunar. Burada, Dubbo geliştirme hizmeti arayüzünün ilgili yapılandırması atlanmıştır.

Satın alma sistem kodu:

Bunların arasında, satın alma siparişi hizmeti (satın alma siparişi hizmeti), kütüphane yönetim sisteminin hizmet arabirimi işlevi finishPurchaseOrder (tam satın alma sipariş işlevi) çağrıldığı, satın alma sistemindeki kitaplık yönetim sistemi PurchaseOrderService'in (satın alma sipariş hizmeti) Dubbo hizmet istemci saplamasıdır.

Bu şekilde, satın alma sistemi ile kütüphane yönetim sistemi arasındaki güçlü bağlantı, Dubbo aracılığıyla basitçe sistem izolasyonu ve ayrıştırmayı sağlayabilir. Tabii ki Dubbo arayüzüne ek olarak HTTPS, HSF ve WebService gibi senkronize arayüz çağırma yöntemleri de kullanılabilir ve MetaQ gibi asenkron mesaj bildirim yöntemleri de kullanılabilir.

4.3 Sistemler arasında ortak etkileşim protokolleri

4.3.1 Senkron arabirim çağrısı

Senkronize arayüz çağrısı, engelleyen bir arayüz çağrı mekanizmasıdır. Yaygın etkileşim protokolleri şunlardır:

HTTP / HTTPS arayüzü;

Web Hizmeti arayüzü;

Dubbo / HSF arayüzü;

CORBA arayüzü.

4.3.2 Eşzamansız mesaj bildirimi

Eşzamansız mesaj bildirimi, bildirim tarzı bir bilgi alışverişi mekanizmasıdır. Sistemde belirli bir olay meydana geldiğinde, ilgili sistemi aktif olarak bilgilendirecektir. Yaygın etkileşim protokolleri şunlardır:

MetaQ mesaj bildirimi;

CORBA mesaj bildirimi.

4.4. Sistemler arasında ortak etkileşim yolları

4.4.1 İstek-Yanıt

Uygulama kapsamı: Dubbo arayüz senkronizasyon çağrısı gibi basit ve zaman alan arayüz senkronizasyon çağrı senaryoları için uygundur.

4.4.2 Bildirim-Onay

Uygulama kapsamı: MetaQ mesaj bildirimi gibi basit asenkron mesaj bildirim senaryoları için uygundur.

4.4.3 İstek-Yanıt-Sorgu-Geri Dönüş

Uygulama kapsamı: İş görevlerini göndermek ve görevlerin sonuçlarını düzenli olarak sorgulamak gibi senaryoları çağıran karmaşık ve zaman alan arayüz senkronizasyonu için uygundur.

4.4.4 İstek-Yanıt-Geri Arama

Uygulama kapsamı: Karmaşık ve zaman alan arayüz senkron çağrıları ve Alipay sipariş ödemesi gibi asenkron geri çağrı senaryoları için uygundur.

4.4.5 İstek-Yanıt-Bildirim-Onay

Uygulama kapsamı: Karmaşık ve zaman alan arayüz senkron çağrılarını ve bir iş görevi göndermek ve tamamlanma mesajı bildirimini beklemek gibi asenkron mesaj bildirimlerini birleştiren senaryolar için uygundur.

4.4.6 Bildirim-Onay-Bildirim-Onay

Uygulama kapsamı: Karmaşık ve zaman alan eşzamansız mesaj bildirim senaryoları için uygundur.

5. Veri sorgusu sayfalı değil

Veri sorgusunda, gelecekteki veri hacminin doğru bir şekilde tahmin edilememesi nedeniyle, çoğu durumda verilerin sayfalama sorgusu dikkate alınmaz.

5.1. Genel sorgu durumu

Aşağıdaki, süresi dolmuş siparişleri sorgulamak için koddur:

Süresi dolan emir sayısı az olduğunda yukarıdaki kodda herhangi bir sorun yaşanmayacaktır. Ancak, süresi dolan siparişlerin sayısı yüz binlerce veya on milyonlara ulaştığında, yukarıdaki kodda aşağıdaki sorunlar olacaktır:

Veri miktarı çok fazla, bu da sunucunun belleğinin taşmasına neden oluyor;

Veri miktarı çok fazla, bu da sorgu arayüzünün zaman aşımına uğramasına ve verilerin zaman aşımına uğramasına neden oluyor;

Veri miktarı çok fazla, bu da istemcinin belleğinin taşmasına neden oluyor.

Bu nedenle, verileri sorgularken, özellikle veri miktarı tahmin edilemediğinde, verilerin sayfalama sorgusu dikkate alınmalıdır.

Burada temel olarak iki yöntem tanıtılmaktadır: "Maksimum sayıyı ayarla" ve "Çağrı sorgusu kullan".

5.2 Maksimum sayıyı ayarlayın

"Maksimum sayıyı ayarla" en basit sayfalama sorgusudur ve bu, verilerin yalnızca ilk sayfasını döndürmeye eşdeğerdir. Örnek kod aşağıdaki gibidir:

Sayfalama gerektirmeyen, ancak çok fazla verinin neden olduğu bellek taşmasından endişe duyan ve veri miktarının çok fazla olduğu sorgular için uygundur.

5.3 Sayfalama sorgusu kullanma

"Sayfalama sorgusu kullanmak", veri sorgusu için startIndex (başlangıç sıra numarası) ve pageSize (sayfa boyutu) veya veri sorgusu için pageIndex (sayfa sıra numarası) ve pageSize (sayfa boyutu) belirtmektir. Örnek kod aşağıdaki gibidir:

Gerçek sayfalama sorgusu için uygundur.Sorgu parametreleri startIndex (başlangıç sıra numarası) ve pageSize (sayfa boyutu) arayan tarafından belirtilebilir.

5.4 Sayfalama sorgusu gizleme sorunu

Zamanlanmış bir işte (her 5 dakikada bir yürütülen) zaman aşımına uğramış (durum = 5, 30 gün içinde oluşturma süresi) siparişler için bir zaman aşımı kapatma (durum = 10) gerçekleştirmemiz gerektiğini varsayalım. Uygulama kodu aşağıdaki gibidir:

İlk bakışta bu kodla ilgili bir sorun yok. 100 kez döngüye girmeye çalışın, her seferinde süresi dolan 1000 sipariş alın ve sipariş kalmayana veya 100 kez ulaşana kadar siparişi zamanla kapatın. Bununla birlikte, sipariş durumuna birlikte bakarsanız, ikinci sorgudan başlayarak, önceki startIndex (başlangıç seri numarası) çubuğunda işlenmesi gereken süresi dolan siparişlerin her seferinde göz ardı edildiğini göreceksiniz. Bu, sayfalama sorgusunun gizli sorunudur:

Sorgu koşullarını karşılayan veriler artık işlemdeki sorgu koşullarını karşılamadığında, sonraki sayfalama sorgularındaki koşulları karşılayan verilerin ilk startIndex (başlangıç sıra numarası) atlanmasına neden olur.

"Maksimum sayıyı belirleyerek" çözülebilir, kod aşağıdaki gibidir:

Yazılım tasarımında kıt yetenekler kimlerdir?

0 ila 10 milyon DAU arasında, Xianyu mimarisi son beş yılda nasıl gelişti?