Бәріңе сәлем. Владислав Родин байланыста. Мен қазір OTUS-те бағдарламалық жасақтаманың архитектурасы және жоғары стресстік бағдарламалық жасақтаманың архитектурасы бойынша курстарды оқытамын. Жаңа курс ағынының басталуын күтумен Мен сіздермен бөліскім келетін түпнұсқа материалдың қысқаша бөлігін жазуды шештім.
Кіріспе
HDD секундына шамамен 400-700 операцияны ғана орындай алатындығына байланысты (бұл жоғары жүктемелі жүйедегі әдеттегі rps-мен салыстыруға келмейді), классикалық дискілік деректер базасы архитектураның тар жолы болып табылады. Сондықтан бұл қойманың масштабтау үлгілеріне ерекше назар аудару қажет.
Қазіргі уақытта дерекқорды масштабтаудың 2 үлгісі бар: репликация және бөлшектеу. Бөлшектеу жазу әрекетін масштабтауға мүмкіндік береді және нәтижесінде кластердегі әр серверге жазу үшін rps санын азайтады. Репликация бірдей әрекетті орындауға мүмкіндік береді, бірақ оқу операцияларымен. Бұл мақала осы үлгіге арналған.
репликация
Егер сіз репликацияны өте жоғары деңгейде қарасаңыз, бұл қарапайым нәрсе: сізде бір сервер болды, онда деректер болды, содан кейін бұл сервер бұл деректерді оқу жүктемесіне төтеп бере алмайды. Сіз тағы бірнеше сервер қосасыз, деректерді барлық серверлер бойынша синхрондаңыз және пайдаланушы кластеріңіздегі кез келген серверден оқи алады.
Көрінетін қарапайымдылығына қарамастан, осы схеманың әртүрлі іске асырылуын жіктеудің бірнеше нұсқасы бар:
- Кластердегі рөлдер бойынша (шебер-шебер немесе басты-құл)
- Жіберілген нысандар бойынша (жолға негізделген, мәлімдемеге негізделген немесе аралас)
- Түйінді синхрондау механизмі бойынша
Бүгін біз 3-тармақпен айналысамыз.
Транзакциялық міндеттеме қалай жүзеге асады?
Бұл тақырып репликациямен тікелей байланысты емес, оған жеке мақала жазуға болады, бірақ транзакцияны орындау механизмін түсінбестен әрі қарай оқу пайдасыз болғандықтан, сізге ең негізгі нәрселерді еске түсіруге рұқсат етіңіз. Транзакцияны орындау 3 кезеңде жүзеге асырылады:
- Мәліметтер журналына транзакцияны тіркеу.
- Мәліметтер қорында транзакцияны пайдалану.
- Клиентке транзакцияның сәтті қолданылғаны туралы растауды қайтару.
Әртүрлі дерекқорларда бұл алгоритмнің нюанстары болуы мүмкін: мысалы, MySQL дерекқорының InnoDB қозғалтқышында 2 журнал бар: біреуі репликацияға арналған (екілік журнал), екіншісі PostgreSQL-де болған кезде ACID (болдырмау/қайталау журналы) жүргізуге арналған. екі функцияны орындайтын бір журнал бар (алға жазу журналы = WAL). Бірақ жоғарыда келтірілген нәрсе - дәл осындай нюанстарды ескермеуге мүмкіндік беретін жалпы тұжырымдама.
Синхронды (синхронды) репликация
Транзакцияны орындау алгоритміне алынған өзгерістерді қайталау үшін логиканы қосамыз:
- Мәліметтер журналына транзакцияны тіркеу.
- Мәліметтер қорында транзакцияны пайдалану.
- Деректерді барлық көшірмелерге жіберу.
- Барлық көшірмелерден олар бойынша транзакцияның орындалғаны туралы растау алу.
- Клиентке транзакцияның сәтті қолданылғаны туралы растауды қайтару.
Бұл тәсілмен біз бірқатар кемшіліктерге ие боламыз:
- клиент өзгертулердің барлық көшірмелерге қолданылуын күтеді.
- кластердегі түйіндер саны артқан сайын жазу әрекетінің сәтті болу ықтималдығын азайтамыз.
Егер 1-ші пунктпен бәрі азды-көпті түсінікті болса, онда 2-тармақтың себептерін түсіндіруге тұрарлық. Синхронды репликация кезінде кем дегенде бір түйіннен жауап алмасақ, транзакцияны кері қайтарамыз. Осылайша, кластердегі түйіндер санын көбейту арқылы жазу әрекетінің сәтсіз болу ықтималдығын арттырасыз.
Біз түйіндердің белгілі бір пайызынан ғана растауды күте аламыз ба, мысалы, 51% (кворум)? Иә, мүмкін, бірақ классикалық нұсқада барлық түйіндерден растау қажет, өйткені осылайша біз кластердегі деректердің толық сәйкестігін қамтамасыз ете аламыз, бұл репликацияның осы түрінің сөзсіз артықшылығы болып табылады.
Асинхронды (асинхронды) репликация
Алдыңғы алгоритмді өзгертейік. Біз деректерді репликаларға «біраз уақыттан кейін» жібереміз және «біраз уақыттан кейін» өзгертулер көшірмелерге қолданылады:
- Мәліметтер журналына транзакцияны тіркеу.
- Мәліметтер қорында транзакцияны пайдалану.
- Клиентке транзакцияның сәтті қолданылғаны туралы растауды қайтару.
- Деректерді көшірмелерге жіберу және оларға өзгертулер қолдану.
Бұл тәсіл кластердің жылдам жұмыс істеуіне әкеледі, өйткені біз клиентті деректердің көшірмелерге жетуін және тіпті орындалуын күтпейміз.
Бірақ деректерді көшірмелерге «кейде кейінірек» демпинг шарты транзакцияның жоғалуына және пайдаланушы растаған транзакцияның жоғалуына әкелуі мүмкін, өйткені егер деректер көшіруге уақыт болмаса, клиентке растау. операцияның сәттілігі туралы жіберілді және өзгерістер енгізілген түйін HDD апатқа ұшырады, біз транзакцияны жоғалтамыз, бұл өте жағымсыз салдарға әкелуі мүмкін.
Жартылай синхрондалған репликация
Ақырында біз жартылай синхронды репликацияға көшеміз. Репликацияның бұл түрі өте танымал емес немесе өте кең таралған, бірақ ол синхронды және асинхронды репликацияның артықшылықтарын біріктіре алатындықтан айтарлықтай қызығушылық тудырады.
Алдыңғы 2 тәсілді біріктіруге тырысайық. Біз клиентті ұзақ сақтамаймыз, бірақ деректердің қайталануын талап етеміз:
- Мәліметтер журналына транзакцияны тіркеу.
- Мәліметтер қорында транзакцияны пайдалану.
- Деректерді көшірмелерге жіберу.
- Өзгерістер қабылданғаны туралы репликадан растау алу (олар «біраз уақыттан кейін» қолданылады).
- Клиентке транзакцияның сәтті қолданылғаны туралы растауды қайтару.
Бұл алгоритммен транзакцияның жоғалуы өзгерістерді қабылдайтын түйін де, реплика түйіні де сәтсіз болған жағдайда ғана орын алатынын ескеріңіз. Мұндай сәтсіздіктің ықтималдығы төмен болып саналады және бұл тәуекелдер қабылданады.
Бірақ бұл тәсілмен фантомды оқудың ықтимал қаупі бар. Келесі сценарийді елестетіп көрейік: 4-қадамда біз ешбір көшірмеден растауды алмадық. Біз бұл транзакцияны кері қайтаруымыз керек және клиентке растауды қайтармауымыз керек. Деректер 2-қадамда қолданылғандықтан, 2-қадамның соңы мен транзакцияның кері қайтарылуы арасында уақыт аралығы бар, оның барысында параллельді транзакциялар дерекқорда болмауы керек өзгерістерді көре алады.
Жоғалмайтын жартылай синхронды репликация
Егер сіз аздап ойлансаңыз, сіз алгоритм қадамдарын өзгертіп, осы сценарийде фантомдық оқу мәселесін шеше аласыз:
- Мәліметтер журналына транзакцияны тіркеу.
- Көшірме деректерін жіберу.
- Өзгерістер қабылданғаны туралы репликадан растау алу (олар «біраз уақыттан кейін» қолданылады).
- Мәліметтер қорында транзакцияны пайдалану.
- Клиентке транзакцияның сәтті қолданылғаны туралы растауды қайтару.
Енді өзгертулер қайталанған жағдайда ғана енгіземіз.
қорытынды
Әдеттегідей, идеалды шешімдер жоқ, шешімдердің жиынтығы бар, олардың әрқайсысының өзіндік артықшылықтары мен кемшіліктері бар және әртүрлі сыныптағы мәселелерді шешуге жарамды. Бұл қайталанатын дерекқордағы деректерді синхрондау механизмін таңдау үшін мүлдем дұрыс. Жартылай синхронды репликацияның артықшылықтарының жиынтығы жеткілікті берік және қызықты, сондықтан оның таралуы төмен болғанымен назар аударуға лайық деп санауға болады.
Бар болғаны. Кездескенше !
Ақпарат көзі: www.habr.com