İkili yazma problemi  Etibarlı, yüksək əlçatan, miqyaslana bilən paylanmış sistemin qurulması xüsusi texnikalara, prinsiplərə və nümunələrə riayət etməyi tələb edir. Bu cür sistemlərin dizaynı çoxsaylı problemlərin həllini nəzərdə tutur. Ən çox yayılmış və əsas problemlərdən biri   . ikili yazma problemidir    paylanmış sistemlərdə, əsasən sinxron saxlanmalı olan çoxsaylı məlumat mənbələri və ya verilənlər bazası ilə işləyərkən yaranan problemdir. Bu, verilənlər bazası və ya keşlər kimi müxtəlif məlumat anbarlarına məlumat uyğunsuzluğu, ziddiyyətlər və ya performans darboğazları kimi problemlər təqdim etmədən məlumat dəyişikliklərinin ardıcıl olaraq yazılmasını təmin etmək çətinliyinə aiddir. “İkili yazma problemi”  Mikroxidmətlərin arxitekturası və hər bir xidmət üçün nümunə verilənlər bazası sizə müstəqil yerləşdirmə və miqyaslaşdırma, təcrid olunmuş nasazlıqlar və inkişaf sürətinin potensial artımı kimi bir çox üstünlüklər gətirir. Bununla belə, əməliyyatlar çoxlu mikroservislər arasında dəyişikliklər tələb edir və sizi bu problemi həll etmək üçün etibarlı həll yolu haqqında düşünməyə məcbur edir.   Demək olar ki, real nümunə  Domenimizin kredit ərizələrinin qəbulunu, onların qiymətləndirilməsini və sonra müştərilərə bildiriş xəbərdarlıqlarının göndərilməsini əhatə etdiyi ssenarini nəzərdən keçirək.  Vahid məsuliyyət prinsipi, Konvey qanunu və domenə əsaslanan dizayn yanaşması ruhunda, bir neçə hadisə fırtınası seansından sonra bütün domen aydın sərhədləri, domen modelləri və hər yerdə mövcud olan dili olan müəyyən edilmiş məhdud kontekstləri olan üç alt domenə bölündü.    yeni kredit ərizələrini işə salmaq və tərtib etmək tapşırığıdır.   sistem bu müraciətləri qiymətləndirir və verilən məlumatlar əsasında qərarlar qəbul edir. KYC/KYB, fırıldaqçılıq və kredit riski yoxlamaları da daxil olmaqla bu qiymətləndirmə prosesi çox vaxt apara bilər və eyni vaxtda minlərlə müraciəti idarə etmək qabiliyyətini tələb edə bilər. Nəticə etibarilə, bu funksionallıq müstəqil miqyasa imkan verən öz verilənlər bazası olan xüsusi mikroservisə həvalə edilmişdir. Birincisi, İkinci  Bundan əlavə, bu alt sistemlər hər birinin öz buraxılış dövrləri, xidmət səviyyəsi razılaşmaları (SLA) və genişlənmə tələbləri olan iki fərqli komanda tərəfindən idarə olunur.    , müştərilərə xəbərdarlıq göndərmək üçün xüsusi bildiriş xidməti mövcuddur.  Nəhayət Burada sistemin əsas istifadə halının dəqiq təsviri verilmişdir:  Müştəri kredit ərizəsi təqdim edir.  Kredit Müraciət Xidməti yeni müraciəti "Gözləmədədir" statusu ilə qeyd edir və müraciəti Qiymətləndirmə Xidmətinə yönləndirərək qiymətləndirmə prosesinə başlayır.  Qiymətləndirmə Xidməti daxil olan kredit müraciətini qiymətləndirir və sonra qərar barədə Kredit Müraciət Xidmətinə məlumat verir.  Qərarı aldıqdan sonra Kredit Müraciət Xidməti kredit müraciəti statusunu müvafiq olaraq yeniləyir və nəticə barədə müştərini məlumatlandırmaq üçün Bildirişlər Xidmətini işə salır.  Bildirişlər Xidməti bu sorğunu emal edir və müştərinin parametrlərinə uyğun olaraq e-poçt, SMS və ya digər üstünlük verilən ünsiyyət üsulları vasitəsilə müştəriyə bildirişlər göndərir.  Bu, ilk baxışdan olduqca sadə və primitiv sistemdir, lakin gəlin Kredit müraciəti xidmətinin kredit ərizəsi göndərmə əmrini necə işlədiyinə nəzər salaq.  Xidmətin qarşılıqlı əlaqəsi üçün iki yanaşmanı nəzərdən keçirə bilərik:    Bu yanaşmada xidmət yerli məlumat bazasını yeniləyir (təhsil edir) və sonra hadisə və ya mesajı digər xidmətlərə dərc edir. Əvvəlcə Yerli Təhvil ver-Sonra Nəşr et:    Əksinə, bu üsul yerli verilənlər bazasına dəyişikliklər etməzdən əvvəl hadisə və ya mesajın dərc edilməsini nəzərdə tutur. Əvvəlcə dərc et, sonra yerli icra et:  Hər iki metodun çatışmazlıqları var və paylanmış sistemlərdə ünsiyyət üçün yalnız qismən uğursuzluqdan qorunur.     Bu, birinci yanaşmanın tətbiqi ardıcıllığı diaqramıdır.  Bu ssenaridə Kredit Müraciət Xidməti əvvəlcə əməliyyatı həyata keçirən, sonra isə başqa sistemə bildiriş göndərməyə cəhd etdiyi   yanaşmasından istifadə edir. Bununla belə, məsələn, şəbəkə problemləri varsa, Qiymətləndirmə Xidməti mövcud deyilsə və ya Kredit Müraciət Xidməti Yaddaş Kənar (OOM) xətası ilə qarşılaşarsa və qəzalar baş verərsə, bu proses uğursuzluğa həssasdır. Belə hallarda, əlavə tədbirlər həyata keçirilmədikcə, Qiymətləndirmə yeni kredit müraciəti barədə xəbərdarlıq edilmədən buraxılaraq mesaj itiriləcək. İlk Yerli Təhvil ver-Sonra Nəşr et     Və ikincisi.    ssenarisində Kredit Müraciət Xidməti daha əhəmiyyətli risklərlə üzləşir. O, Qiymətləndirmə Xidmətini yeni tətbiq haqqında məlumatlandıra bilər, lakin verilənlər bazası problemləri, yaddaş xətaları və ya kod səhvləri kimi problemlər səbəbindən bu yeniləməni yerli olaraq saxlaya bilmir. Bu yanaşma, Kredit Baxışı Xidmətinin daxil olan müraciətləri necə idarə etməsindən asılı olaraq, ciddi problemlər yarada bilən məlumatlarda əhəmiyyətli uyğunsuzluqlara səbəb ola bilər. İlk Nəşr et-Sonra Yerli Təhvil ver  Buna görə də, hadisələri xarici istehlakçılara dərc etmək üçün möhkəm mexanizm təklif edən bir həll tapmalıyıq. Lakin, potensial həlləri nəzərdən keçirməzdən əvvəl, paylanmış sistemlərdə əldə edilə bilən mesajların çatdırılması zəmanətlərinin növlərini aydınlaşdırmalıyıq.  Mesajların çatdırılmasına zəmanət  Əldə edə biləcəyimiz dörd növ zəmanət var.  Zəmanət yoxdur  Mesajın təyinat yerinə çatdırılacağına heç bir zəmanət yoxdur.   yanaşması məhz bununla bağlıdır. İstehlakçılar bir dəfə, bir neçə dəfə və ya heç vaxt mesaj ala bilərlər. “Birinci-Yerli-Öhdə-Sonra-Nəşr et”  Ən çox bir dəfə çatdırılma  Ən çox bir dəfə çatdırılma mesajın təyinat yerinə ən çox 1 dəfə çatdırılması deməkdir.   yanaşması bir dəyərli cəhdlərin təkrar cəhd siyasəti ilə də bu şəkildə həyata keçirilə bilər. İlkin-Yerli-Tamamla-Sonra-Nəşr et  Ən azı bir dəfə çatdırılma\İstehlakçılar hər mesajı qəbul edəcək və emal edəcəklər, lakin eyni mesajı bir dəfədən çox qəbul edə bilərlər.  Tam bir dəfə çatdırılma\Tam bir dəfə çatdırılma o deməkdir ki, istehlakçı mesajı bir dəfə effektiv şəkildə alacaq.  Texniki olaraq, Kafka əməliyyatları və istehsalçı və istehlakçının xüsusi idempotent həyata keçirilməsi ilə nail olmaq mümkündür.  Əksər hallarda   çatdırılma zəmanətləri mesajların ən azı bir dəfə çatdırılmasını təmin etməklə bir çox problemi həll edir, lakin istehlakçılar iradəsiz olmalıdırlar. Bununla belə, qaçılmaz şəbəkə nasazlıqlarını nəzərə alaraq, istehsalçının zəmanətlərindən asılı olmayaraq, dublikat mesajları emal etməmək üçün bütün istehlakçı məntiqi idempotent olmalıdır. Buna görə də, bu tələb reallığı əks etdirdiyi qədər çatışmazlıq deyil. "ən azı bir dəfə"  Həll yolları  Bu problemin öz üstünlükləri və mənfi cəhətləri olan bir çox həlli var.   İki fazalı öhdəlik  Vikipediyaya görə, İki Mərhələli Öhdəlik (2PC) paylanmış əməliyyatların ardıcıllığını və etibarlılığını təmin etmək üçün kompüter elmləri və verilənlər bazası idarəetmə sistemlərində istifadə olunan paylanmış əməliyyat protokoludur. O, birdən çox resursun (məsələn, verilənlər bazası) bir əməliyyatda iştirak etməli olduğu vəziyyətlər üçün nəzərdə tutulmuşdur və o, ya onların hamısının əməliyyatı həyata keçirməsini, ya da hamısının əməliyyatı dayandırmasını təmin edir və bununla da məlumatların ardıcıllığını qoruyur. Bu, bizə lazım olan kimi səslənir, lakin İki Fazalı Təhlükəsizliyin bir sıra çatışmazlıqları var:  İştirak edən resurslardan biri cavab vermirsə və ya nasazlıq yaranarsa, problem həll olunana qədər bütün proses bloklana bilər. Bu, potensial performans və əlçatanlıq problemlərinə səbəb ola bilər.  İki Fazalı Məsuliyyət daxili nasazlığa dözümlülük mexanizmlərini təmin etmir. Uğursuzluqları idarə etmək üçün xarici mexanizmlərə və ya əl ilə müdaxiləyə əsaslanır.  Bütün müasir verilənlər bazaları İki Fazalı Təhlükəsizliyi dəstəkləmir.   Paylaşılan verilənlər bazası  Mikroservis arxitekturası üçün ən aydın həll nümunə (və ya hətta bəzən anti-naxış) - paylaşılan verilənlər bazası tətbiq etməkdir. Fərqli verilənlər bazalarında birdən çox cədvəl üzrə əməliyyat ardıcıllığına ehtiyacınız varsa, bu yanaşma çox intuitivdir, sadəcə bu mikroservislər üçün bir paylaşılan verilənlər bazasından istifadə edin.  Bu yanaşmanın çatışmazlıqları arasında vahid uğursuzluq nöqtəsinin tətbiqi, müstəqil verilənlər bazası miqyasının qarşısının alınması və xüsusi tələblər və istifadə halları üçün ən uyğun olan müxtəlif verilənlər bazası həllərindən istifadə imkanının məhdudlaşdırılması daxildir. Bundan əlavə, paylanmış əməliyyatın belə bir formasını dəstəkləmək üçün mikroxidmətlərin kod bazalarına dəyişikliklər etmək lazımdır.   Tranzaksiya qutusu  '   ', hətta etibarsız mesajlaşma sistemləri qarşısında belə etibarlı mesajın yayılmasını təmin etmək üçün paylanmış sistemlərdə istifadə edilən dizayn nümunəsidir. Bu, hadisələrin əməliyyatın özü ilə eyni əməliyyat daxilində təyin olunmuş "Gidənlər qutusu hadisələri" cədvəlində saxlanmasını nəzərdə tutur. Bu yanaşma relational verilənlər bazalarının ACID xüsusiyyətləri ilə yaxşı uyğunlaşır. Əksinə, bir çox No-SQL verilənlər bazası ACID xassələrini tam dəstəkləmir, bunun əvəzinə CAP teoreminin və BASE fəlsəfəsinin prinsiplərinə üstünlük verir, hansı ki, mövcudluğu və son ardıcıllığı ciddi ardıcıllıqdan üstün tutur. Transsional poçt qutusu  Tranzaksiya qutusu   verir və bir neçə yanaşma ilə həyata keçirilə bilər: ən azı bir dəfə zəmanət  Tranzaksiya jurnalının saxlanması  Səsvermə naşiri    yanaşması CDC (Change Data Capture) kimi verilənlər bazası üçün xüsusi həllərdən istifadə etməyi nəzərdə tutur. Bu yanaşmanın əsas çatışmazlıqları aşağıdakılardır: Transaction log tailing  Verilənlər bazası üçün xüsusi həllər  CDC tətbiqlərinin xüsusiyyətlərinə görə artan gecikmə  Başqa bir üsul, gedən qutu cədvəlini sorğulayaraq, gedən qutunun yüklənməsini asanlaşdıran   . Bu yanaşmanın əsas çatışmazlığı daha yüksək xərclərə səbəb ola bilən verilənlər bazası yükünün artması potensialıdır. Bundan əlavə, bütün No-SQL verilənlər bazaları xüsusi sənəd seqmentləri üçün səmərəli sorğuları dəstəkləmir. Beləliklə, bütün sənədlərin çıxarılması performansın aşağı düşməsinə səbəb ola bilər. Sorğu Yayımçısıdır  Bunun necə işlədiyini izah edən kiçik bir ardıcıllıq diaqramıdır.    Özünüzü dinləyin  Transaction Outbox modelinin əsas problemi onun verilənlər bazası ACID xüsusiyyətlərindən asılılığındadır. Bu, tipik OLTP verilənlər bazalarında sadə ola bilər, lakin NoSQL sahəsində problemlər yaradır. Bunu həll etmək üçün potensial həll, sorğunun işlənməsinin başlanmasından dərhal sonra əlavə jurnalından (məsələn, Kafka) istifadə etməkdir.  "Kredit ərizəsini təqdim et" əmrini birbaşa emal etmək əvəzinə, biz onu dərhal daxili Kafka mövzusuna göndəririk və sonra müştəriyə "qəbul edilmiş" nəticəni qaytarırıq. Bununla belə, komandanın hələ də işlənməsinə ehtiyac olduğu ehtimalı yüksək olduğundan, nəticə barədə müştəriyə dərhal məlumat verə bilmərik. Bu son ardıcıllığı idarə etmək üçün biz uzun sorğu, müştərinin təşəbbüsü ilə sorğu, optimist UI yeniləmələri və ya bildirişlər üçün WebSockets və ya Server tərəfindən Göndərilən Hadisələrdən istifadə kimi üsullardan istifadə edə bilərik. Ancaq bu, tamamilə fərqli bir mövzudur, ona görə də ilkin mövzumuza qayıdaq.  Mesajı daxili Kafka mövzusunda göndərdik. Kredit Müraciət Xidməti daha sonra bu mesajı istehlak edir - müştəridən aldığı eyni əmri - və emal etməyə başlayır. Birincisi, bəzi iş məntiqini yerinə yetirir; yalnız bu məntiq uğurla icra edildikdən və nəticələr davam etdirildikdən sonra o, ictimai Kafka mövzusunda yeni mesajlar dərc edir.  Gəlin bir az psevdokoda nəzər salaq.   public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }    Narahat olmayın, ofset hələ həyata keçirilmədiyi üçün mesaj yenidən yoxlanılacaq. Biznes məntiqinin işlənməsi uğursuz olarsa nə etməli?    Narahat olmayın, biznes məntiqi idempotent olduğundan, o, dublikat kredit ərizəsi yaratmayacaq. Bunun əvəzinə o, ictimai Kafka mövzusuna mesajları yenidən göndərməyə çalışacaq. Bəs Kafkaya yeni hadisələr göndərmək uğursuz olarsa?    Narahat olmayın, biznes məntiqi qeyri-müəyyən olduğundan, o, dublikat kredit ərizəsi yaratmayacaq. Bunun əvəzinə o, ictimai Kafka mövzusuna mesajlar göndərəcək və bu dəfə ofset öhdəliyinin uğur qazanacağına ümid edəcək. Kafkaya mesajlar göndərilsə, lakin ofset öhdəliyi uğursuz olarsa nə etməli?  Bu yanaşmanın əsas çatışmazlıqlarına yeni proqramlaşdırma üslubu ilə bağlı əlavə mürəkkəblik, son ardıcıllıq (çünki müştəri nəticəni dərhal bilməyəcək) və bütün biznes məntiqinin idempotent olması tələbi daxildir.  Hadisə mənbəyi  Hadisə mənbəyi nədir və onu burada necə tətbiq etmək olar? Hadisə qaynağı, bir sıra dəyişilməz hadisələr kimi verilənlərindəki bütün dəyişiklikləri ələ keçirməklə sistemin vəziyyətini modelləşdirmək üçün istifadə edilən proqram memarlıq nümunəsidir. Bu hadisələr faktları və ya dövlət keçidlərini təmsil edir və sistemin hazırkı vəziyyəti üçün yeganə həqiqət mənbəyi kimi xidmət edir. Beləliklə, texniki olaraq, hadisə qaynağı sistemini tətbiq etməklə, artıq EventStore-da bütün tədbirlərimiz var və bu EventStore istehlakçılar tərəfindən baş verənlər haqqında yeganə həqiqət mənbəyi kimi istifadə edilə bilər. Sifarişlə bağlı bütün dəyişiklikləri və ya narahatlıqları izləmək üçün xüsusi verilənlər bazası həllinə ehtiyac yoxdur, yeganə problem oxuyan tərəfdə oturmaqdır, çünki obyektin faktiki vəziyyətini əldə etmək üçün bütün hadisələri təkrarlamaq lazımdır.  Nəticə  Bu yazıda biz paylanmış sistemlərdə etibarlı mesajlaşma yaratmaq üçün bir neçə yanaşmanı nəzərdən keçirdik. Bu xüsusiyyətlərə malik sistemlər qurarkən nəzərə ala biləcəyimiz bir neçə tövsiyə var  Şəbəkə uğursuzluğu qaçılmaz olduğundan həmişə idempotent istehlakçılar inkişaf etdirin.  Zəmanət tələblərini aydın şəkildə başa düşməklə   diqqətlə istifadə edin. , “Birinci-Yerli-Taahhüd“-Sonra-Nəşr et-dən  Heç vaxt   ver yanaşmasından istifadə etməyin, çünki bu, sisteminizdə ciddi məlumat uyğunsuzluğuna səbəb ola bilər. İlk Yayımla-Sonra Yerli Təhvil  Mövcud verilənlər bazası seçimi qərarı çox güman ki, dəyişə bilərsə və ya texniki strategiya problem üçün ən yaxşı saxlama həllini seçməyi nəzərdə tutursa -   kimi verilənlər bazası həllərinə bağlanaraq ortaq kitabxanalar yaratmayın. CDC  Ən azı bir dəfə zəmanətlərə nail olmaq üçün   yanaşmasını standart həll yolu kimi istifadə edin. Transactional Outbox  No-SQL verilənlər bazası istifadə edildikdə   yanaşmasından istifadə etməyi düşünün. Özünüzü dinləyin  Növbəti dəfə biz Transactional Outbox tətbiqinin daha praktik nümunəsinə baxacağıq. Bax  sən!

Read My Stories

Bu audio hekayənin orijinal dilində hazırlanmışdır!

Çox uzun; Oxumaq

Make resilience your competitive advantage

Paylanmış Sistemlərdə Etibarlı Mesajlaşma

About Author

ŞƏRHLƏR

ETİKET ASIN

BU MƏQALƏ TƏQDİM EDİLMİŞDİR

Related Stories

How Azarus's Technology is Transforming Viewer Engagement on Stream

Optimizing Operations for Real Estate Investors - Interview with Startups of the Year Nominee, Azibo

Women in Tech: Azize Sultan Shares Her Inspiring Journey from Architecture to Tech Leadership

How Azarus's Technology is Transforming Viewer Engagement on Stream

Optimizing Operations for Real Estate Investors - Interview with Startups of the Year Nominee, Azibo

Women in Tech: Azize Sultan Shares Her Inspiring Journey from Architecture to Tech Leadership

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps