Защо може да се нуждаете от полусинхронна репликация?

Здравейте всички. Владислав Родин е във връзка. В момента преподавам курсове по софтуерна архитектура и софтуерна архитектура с висок стрес в OTUS. В очакване на началото на нов курс поток „Архитект с голямо натоварване“ Реших да напиша кратък оригинален материал, който искам да споделя с вас.

въведение

Поради факта, че твърдият диск може да изпълнява само около 400-700 операции в секунда (което е несравнимо с типичните rps на система с голямо натоварване), класическата дискова база данни е тясното място на архитектурата. Следователно е необходимо да се обърне специално внимание на моделите на мащабиране на това хранилище.

В момента има 2 модела за мащабиране на бази данни: репликация и шардинг. Шардингът ви позволява да мащабирате операцията за запис и в резултат на това да намалите rps за запис на сървър във вашия клъстер. Репликацията ви позволява да правите същото, но с операции за четене. Именно на този модел е посветена тази статия.

репликация

Ако погледнете репликацията на много високо ниво, това е просто нещо: имахте един сървър, имаше данни на него и след това този сървър вече не можеше да се справи с натоварването от четене на тези данни. Добавяте още няколко сървъра, синхронизирате данни между всички сървъри и потребителят може да чете от всеки сървър във вашия клъстер.

Въпреки привидната си простота, има няколко опции за класифициране на различни изпълнения на тази схема:

• По роли в клъстера (master-master или master-slave)
• Чрез изпратени обекти (базирани на редове, базирани на изявления или смесени)
• Според механизма за синхронизация на възела

Днес ще разгледаме точка 3.

Как възниква ангажимент за транзакция?

Тази тема не е пряко свързана с репликацията; може да се напише отделна статия за нея, но тъй като по-нататъшното четене е безполезно без разбиране на механизма за ангажиране на транзакциите, позволете ми да ви напомня най-основните неща. Ангажирането на транзакция се осъществява на 3 етапа:

1. Регистриране на транзакция в регистрационния файл на базата данни.
2. Използване на транзакция в двигател на база данни.
3. Връщане на потвърждение на клиента, че транзакцията е успешно приложена.

В различни бази данни този алгоритъм може да има нюанси: например в двигателя InnoDB на базата данни на MySQL има 2 журнала: един за репликация (двоичен журнал), а другият за поддържане на ACID (дневник за отмяна/повторяване), докато в PostgreSQL има един дневник, който изпълнява и двете функции (журнал за предварително запис = WAL). Но това, което е представено по-горе, е именно общата концепция, която позволява да не се вземат предвид такива нюанси.

Синхронна (синхронна) репликация

Нека добавим логика за копиране на получените промени в алгоритъма за извършване на транзакция:

1. Регистриране на транзакция в регистрационния файл на базата данни.
2. Използване на транзакция в двигател на база данни.
3. Изпращане на данни до всички реплики.
4. Получаване на потвърждение от всички реплики, че върху тях е извършена транзакция.
5. Връщане на потвърждение на клиента, че транзакцията е успешно приложена.

С този подход получаваме редица недостатъци:

• клиентът изчаква промените да бъдат приложени към всички реплики.
• тъй като броят на възлите в клъстера се увеличава, ние намаляваме вероятността операцията за запис да бъде успешна.

Ако всичко е повече или по-малко ясно с 1-ва точка, тогава причините за 2-ра точка си струва да бъдат обяснени. Ако по време на синхронна репликация не получим отговор от поне един възел, връщаме обратно транзакцията. По този начин, чрез увеличаване на броя на възлите в клъстера, вие увеличавате вероятността операцията за запис да се провали.

Можем ли да чакаме потвърждение само от определен процент възли, например от 51% (кворум)? Да, можем, но в класическата версия е необходимо потвърждение от всички възли, защото така можем да осигурим пълна консистенция на данните в клъстера, което е безспорно предимство на този тип репликация.

Асинхронна (асинхронна) репликация

Нека модифицираме предишния алгоритъм. Ще изпратим данни на репликите „някога по-късно“, а „някога по-късно“ промените ще бъдат приложени към репликите:

1. Регистриране на транзакция в регистрационния файл на базата данни.
2. Използване на транзакция в двигател на база данни.
3. Връщане на потвърждение на клиента, че транзакцията е успешно приложена.
4. Изпращане на данни до реплики и прилагане на промени към тях.

Този подход води до факта, че клъстерът работи бързо, защото не караме клиента да чака данните да достигнат до репликите и дори да бъдат ангажирани.

Но условието за изхвърляне на данни върху реплики „някога по-късно“ може да доведе до загуба на транзакция и до загуба на транзакция, потвърдена от потребителя, защото ако данните не са имали време да бъдат репликирани, потвърждение към клиента за успеха на операцията беше изпратено и възелът, до който пристигнаха промените, се срина HDD, губим транзакцията, което може да доведе до много неприятни последици.

Полусинхронна репликация

Накрая стигаме до полусинхронна репликация. Този тип репликация не е много добре познат или много често срещан, но представлява значителен интерес, тъй като може да комбинира предимствата както на синхронната, така и на асинхронната репликация.

Нека се опитаме да комбинираме двата предишни подхода. Няма да задържим клиента дълго, но ще изискваме данните да бъдат репликирани:

1. Регистриране на транзакция в регистрационния файл на базата данни.
2. Използване на транзакция в двигател на база данни.
3. Изпращане на данни към реплики.
4. Получаване на потвърждение от репликата, че промените са получени (те ще бъдат приложени „по-късно“).
5. Връщане на потвърждение на клиента, че транзакцията е успешно приложена.

Моля, обърнете внимание, че с този алгоритъм загуба на транзакция възниква само ако и възелът, който получава промените, и възелът на реплика се провалят. Вероятността от такъв отказ се счита за ниска и тези рискове се приемат.

Но при този подход съществува възможен риск от фантомни четения. Нека си представим следния сценарий: в стъпка 4 не получихме потвърждение от никаква реплика. Трябва да отменим тази транзакция и да не връщаме потвърждение на клиента. Тъй като данните бяха приложени в стъпка 2, има интервал от време между края на стъпка 2 и връщането назад на транзакцията, по време на който паралелните транзакции могат да видят промени, които не трябва да бъдат в базата данни.

Полусинхронизирана репликация без загуба

Ако помислите малко, можете просто да обърнете стъпките на алгоритъма и да коригирате проблема с фантомните четения в този сценарий:

1. Регистриране на транзакция в регистрационния файл на базата данни.
2. Изпращане на реплика на данни.
3. Получаване на потвърждение от репликата, че промените са получени (те ще бъдат приложени „по-късно“).
4. Използване на транзакция в двигател на база данни.
5. Връщане на потвърждение на клиента, че транзакцията е успешно приложена.

Сега извършваме промени само ако са били репликирани.

Продукция

Както винаги, няма идеални решения; има набор от решения, всяко от които има своите предимства и недостатъци и е подходящо за решаване на различни класове проблеми. Това е абсолютно вярно за избор на механизъм за синхронизиране на данни в репликирана база данни. Наборът от предимства, които има полусинхронната репликация, е достатъчно солиден и интересен, за да може да се счита за достоен за внимание, въпреки слабото си разпространение.

Това е всичко. Ще се видим в курс!

Източник: www.habr.com