Това е втората и заключителна част от блога — разпределени съобщения с ниска латентност с RocketMQ. Ще хвърлим светлина върху трите ключа за гарантиране на капацитета, архитектурата на RocketMQ и бъдещето или системата за съобщения на Alibaba Cloud.
Три ключа за гарантиране на капацитет
Гаранцията за оптимизация с ниска латентност може да не доведе непременно до ситуация без латентност за машина за съобщения. За да осигури гладко изживяване за приложенията, системата за съобщения изисква гъвкаво планиране въз основа на капацитета. Как можем да накараме системата да реагира с лекота на огромни пикове на трафика? За да се справим с това безпокойство, трябва да се обърне внимание на трите основни фактора на латентността - влошаване, ограничаване на трафика и сливане. Гаранцията за ресурсите на основните услуги възниква с цената на влошаване и спиране на маргинални услуги и компоненти. Приоритетът на системата е да не регистрира повреда поради спукване на трафик.
От гледна точка на стабилността на архитектурата и с ограничени ресурси, възможностите за обслужване, които системата може да предостави за единица време, също са ограничени. Цялата услуга може да спре при превишаване на капацитета за носене, причинявайки срив на приложението, което може да прехвърли риска върху извикващия услугата и да причини недостъпност на услугата за цялата система, което в крайна сметка води до лавина от приложения. Освен това, според теорията на опашката, средното време за отговор на услугите със закъснения се увеличава бързо с нарастващите заявки. За да се осигурят SLA за обслужване, е необходимо да се контролират заявките за единица време. Следователно ограничаването на трафика става още по-решаващо.
Концепцията за ограничаване на трафика е известна още като Traffic Shaping в академичния свят. Той произхожда от областта на мрежовата комуникация, като обикновено включва алгоритъма за изтичаща кофа и алгоритъма за токена за кофа. По-долу има допълнително обяснение:
Фигура 1.
Основната идея на алгоритъма за течаща кофа е, че имаме течаща кофа, от която водата капе с постоянна скорост, и кран отгоре, от който водата се излива в кофата. Ако водата се излива със скорост, по-бърза от водата, която капе, кофата ще прелее. В идеалния случай можем да разберем това като претоварване на заявка.
Основната идея на токена, точно както алгоритъмът на кофата е свързан с кофа, токените влизат в кофата с постоянна скорост. Съществува ограничение за броя токени, които могат да влязат в кофата. Всяка заявка ще получи токен. Ако няма останали токени в кофата, когато пристигне заявка, се получава претоварване на заявката. Трябва да е очевидно, когато има внезапен скок в заявките за токените на кофата.
Фигура 2.
По-точно, можем да разглеждаме или пропускащата кофа, жетонната кофа или всеки друг вариант на тези алгоритми като форма на ограничаване на трафика, която контролира скоростта на трафика. Освен това има режими за ограничаване на трафика, които контролират паралелността, като семафори в операционна система и семафор в JDK.
Асинхронното отделяне, намаляването на пиковите времена и преместването на натоварването са основни функции на двигателите за съобщения. Тези функции са фокусирани върху скоростта на трафика, но все пак трябва да вземем предвид някои необходими контроли на трафика. За разлика от това, което споменахме по-рано, готовите тарифи и компоненти за контрол на трафика като Guava и Netty не са част от RocketMQ. Бавните заявки се подлагат на толерантна към грешки обработка чрез позоваване на теорията за опашките. Бавните заявки тук се отнасят до заявки с време на изчакване в опашката и време за обслужване, които надхвърлят определен праг.
За сценарии на офлайн приложения обработката с устойчивост на грешки използва механизма на плъзгащия се прозорец и чрез бавно свиване на прозореца намалява честотата на изтегляне от сървъра и размерите на съобщенията и минимизира влиянието върху сървъра. За сценарии с високочестотна търговия и репликация на данни, системата има приложени стратегии за бърз отказ, за да предотврати лавините на приложенията, произтичащи от вериги на приложения, причиняващи изчерпани ресурси, и ефективно намалява натиска върху сървъра, ефективно гарантирайки ниската латентност от край до край .
Влошаването на услугата е типичен пример за жертване на нещо незначително за по-голямото благо, с 20%-80% по принцип, когато се практикува. Средствата за деградация не са нищо друго освен такава проста и груба операция като изключване на сървъра и извеждането му офлайн. Изборът на цели за влошаване е по-зависим от дефиницията на QoS. Първоначалната обработка на влошаването от двигателите за съобщения идва главно от два аспекта: събирането на потребителски данни и настройките на компонентите на QoS двигателя. За първото, прокарването на QoS данни на приложението чрез системите за операции и поддръжка и управление и контрол обикновено ще изведе следната таблица: За основните функции QoS на компонентите на двигателя, като модули за верига, обслужващи проследяването на проблеми със съобщенията, са с ниска градация и затваряне на риска преди достигане на пика.
Не можем да говорим за предпазители, без да разгледаме предпазителите в класическата система за захранване. В случай на прекомерни натоварвания, повреди във веригата или изключения, токът ще продължи да нараства. За да се предотврати нарастващият ток от евентуална повреда на някои решаващи или скъпи компоненти във веригата, изгаряне на веригата или дори причиняване на пожар, предпазителите ще се стопят, за да прекъснат тока, когато той бързо се повиши до определено ниво или се нагрее, за да се защити безопасната работа на веригата.
Също така, в разпределените системи, ако отдалечените услуги или ресурси са недостъпни по някаква причина, липсата на защита от претоварване ще блокира заявените ресурси в сървъра, принуждавайки го да чака, като по този начин използва ресурсите на системата или сървъра. В много случаи първоначално има само локални или малки системни повреди. Въпреки това, поради различни причини, обхватът на ефектите от тези грешки се увеличава и накрая води до глобални последици. Този тип защита от претоварване е известен като прекъсвач. За да разреши този проблем, Netflix отвори източника на своето решение за сливане Hystrix.
Фигура 3.
Фигура 4.
Фигура 5.
Трите изображения по-горе описват сценариите на системата от първоначалното здравословно състояние до нейното блокирано състояние в някакъв ключов зависим компонент надолу по веригата в сценарий с висока едновременност. На практика тази ситуация лесно може да предизвика лавина. Представянето на фюзинг механизма на Hystrix позволява на приложенията да се провалят бързо и избягва най-лошия сценарий.
Фигура 6.
Като се позовава на идеята на Hystrix, екипът на Alibaba Cloud разработи набор от механизми за сливане на двигателя за съобщения. По време на тестването на натоварване имаше случаи, при които услугите бяха недостъпни поради повреда в компютърния хардуер. При използване на конвенционалните средства, устойчиви на грешки, са необходими 30 секунди, преди недостъпният компютър да престане да бъде част от списъка. Въпреки това, чрез този набор от механизми за сливане е възможно да се идентифицират и изолират засегнатите услуги в рамките на милисекунди. По този начин идеята допълнително надгражда наличността на двигатели.
Решения с висока наличност
Въпреки че препоръчваме да разчитате на трите фактора, влияещи върху гаранцията за капацитет; обаче, тъй като мащабът на клъстерите на машината за съобщения се увеличава равномерно, за да достигне определена степен, възможността за компютърни грешки в клъстера става по-висока. Това значително намалява надеждността на съобщенията и наличността на системата. В същото време клъстерните режими, базирани на разполагането на множество сървърни стаи, също ще доведат до счупени мрежи в сървърните стаи, което допълнително компрометира наличността на системите за съобщения.
За да се справи с този проблем, екипът на Alibaba Cloud въведе базирани на много реплики високодостъпни решения, които позволяват динамично идентифициране на сценарии за бедствия, като компютърни повреди и счупени мрежи в сървърните стаи. Освен това решенията позволяват автоматично възстановяване от грешки. Целият процес на възстановяване е прозрачен за потребителите, не изисква намеса от персонала за експлоатация и поддръжка, аспект, който значително подобри надеждността на съхранението на съобщения и по-високата наличност на целия клъстер.
По-голямата достъпност е важна характеристика, която почти всяка разпределена система трябва да вземе предвид. Въз основа на принципа на CAP (съгласуваност, наличност и разделяне), е невъзможно да се удовлетвори толерансът едновременно в разпределена система. По-долу са някои общи високодостъпни решения, предложени за разпределени системи в индустрията:
Фигура 7.
Редовете представляват високодостъпни решения в разпределени системи, включително студени резервни копия, главни/подчинени, главни/главни, 2PC и решения, базирани на алгоритми Paxos. Колоните представляват индикаторите, които формират основния фокус на разпределените системи, включително съгласуваност на данните, ниво на поддръжка на транзакции, латентност на данните, пропускателна способност на системата, възможност за загуба на данни, както и начин на възстановяване от отказ.
Както се вижда от снимката, степента на поддръжка на индикаторите варира в зависимост от решенията. Въз основа на принципа на CAP е трудно да се проектира високо достъпно решение, способно да отговори на оптималната стойност на всички показатели. В случай на система master/slave, например, тя обикновено отговаря на следните характеристики:
• Задаване на броя на подчинените въз основа на степента на важност на данните.
Данните удрят главния, когато пишат заявки и главния или подчинения, когато четат заявки.
• След натискане на главния при писане на заявки, репликацията на данни се извършва от главния към подчинения по синхронен или асинхронен начин. За режим на репликация на синхронизиране е наложително да се уверите, че главният и подчинения записват успешно, преди да дадете обратна връзка за успех на клиента. За режим на асинхронна репликация е необходимо само да се уверите, че главният записва успешно, преди да изпратите обратна връзка за успех на клиента.
Като се има предвид възможността за копиране на данни от главния към подчинения по синхронен или асинхронен начин, структурата на главен/подчинен може поне да осигури крайната последователност на данните. В режим на асинхронна репликация, където е възможно да се изпрати обратна връзка за успеха на клиента след успешното записване на данните в главния, системата има по-ниска латентност и по-висока пропускателна способност, но загубата на данни все още е възможна поради грешка на главния.
Ако не се очаква загубата на данни да бъде фактор за повреда на главния в режим на асинхронна репликация, подчиненият може само да изчака възстановяването на главния в режим само за четене, удължавайки времето за възстановяване от системни грешки. От друга страна, режимът на синхронно репликиране в структурата master/slave ще гарантира липса на загуба на данни поради повреда на компютъра и ще намали времето за възстановяване от системни грешки с цената на увеличаване на закъсненията при запис на данни и намаляване на пропускателната способност на системата.
Архитектурата с висока достъпност на RocketMQ
Въз основа на първоначалното разгръщане на множество сървърни стаи, клъстерният режим RocketMQ използва разпределени заключвания и механизми за уведомяване, с помощта на контролера на компонентите, за да проектира и постигне високодостъпната архитектура на структурата master/slave, както е показано по-долу:
Фигура 8.
Като разпределена рамка за планиране, Zookeeper изисква внедряването на поне три сървърни стаи A, B и C, за да се гарантира неговата наличност и да се осигурят следните функции за високодостъпна архитектура на RocketMQ:
• Поддържане на ПОСТОЯННИ възли и запазване на машинните състояния на главния/подчинения;
• Поддържайте EPHEMERAL възли и запазвайте текущото състояние на RocketMQ;
• Уведомете съответните наблюдатели в случай на промени в текущото състояние на машинните състояния на главния/подчинения сървър
RocketMQ постига peer-базирано внедряване на множество сървърни стаи със структурата master/slave. Заявките за запис на съобщения ще ударят главния и ще се репликират към подчинения за постоянно съхранение в синхронен или асинхронен режим; заявките за четене на съобщения ще ударят главния като въпрос на приоритет и впоследствие ще се преместят към подчинения, когато се натрупат съобщения, причинявайки по-голям натиск върху диска. RocketMQ взаимодейства директно със Zookeeper чрез:
• Отчитане на текущото състояние към Zookeeper под формата на EPHEMERAL възли;
• Наблюдение на промяната в състоянието на машината на главния/подчинения на Zookeeper като наблюдател. Ако открием промяна в състоянието на машината на главния/подчинения, текущото състояние ще се промени в съответствие с новото състояние на машината;
RocketMQ HA Controller е компонент без състояние в архитектурата с висока достъпност на двигатели за съобщения за намаляване на времето за възстановяване от системни грешки, разположени отделно в сървърни стаи A, B и C. Той служи главно за:
• Наблюдавайте промяната в текущото състояние на RocketMQ в Zookeeper като наблюдател
• Контролирайте превключването на състоянието на машината на главния/подчинения въз основа на текущото състояние на клъстера и докладвайте на Zookeeper новото състояние на машината на главния/подчинения
Като се има предвид сложността на системата и адаптивността на самата система за съобщения към принципа на CAP, дизайнът на високодостъпната архитектура RocketMQ използва структурата master/slave. Въз основа на предоставянето на услуги за съобщения с ниска латентност и висока пропускателна способност, системата възприема репликацията за синхронизиране на главен/подчинен, за да избегне загуба на съобщения поради грешки.
В процеса на синхронизиране на данни поддържането на инкрементален и глобално уникален SequenceID ще осигури силна съгласуваност на данните. Системата въвежда механизъм за автоматично възстановяване от грешки едновременно, за да съкрати времето за възстановяване и да подобри наличността на системата.
Оценка на наличността
Наличността на системата е способността на една информационна система да предоставя непрекъсната услуга, измерена в информационната индустрия. Той показва вероятността системата или способността на системата да работи нормално в конкретна среда, в рамките на даден интервал от време. Накратко, наличността е резултат от средното време между отказите (MTBF), разделено на сумата от MTBF и средното време за ремонт (MTTR), а именно:
Общата практика в индустрията е наличността на системата да се представя с числото деветки. Например три деветки означават, че наличността е най-малко 99,9%, което показва, че продължителността на недостъпност през годината е в рамките на 8,76 часа. Наличност от 99,999%, или пет деветки, означава, че продължителността на недостъпност през цялата година трябва да бъде в рамките на 5,26 минути. Система без автоматично възстановяване от грешки не може да постигне наличност на пет деветки.
Гаранция за висока наличност на RocketMQ
Както се вижда от формулата за наличност, за подобряване на наличността на системата е от решаващо значение да се подобри допълнително способността на системата да се възстановява автоматично от грешки, за да се съкрати MTTR въз основа на осигуряване на устойчивост на системата, за да се удължи MTBF. Архитектурата с висока достъпност на RocketMQ е проектирала и внедрила компонентен контролер, който превключва машина с ограничено състояние в реда на състояние на единичен главен, състояние на асинхронна репликация, състояние на полусинхронизация и състояние на окончателна синхронизирана репликация. В последното състояние на синхронизирана репликация, ако възникне повреда в който и да е главен и подчинен възел, е възможно други възли да преминат към състояние на един главен в рамките на секунди, за да продължат предоставянето на услугата. В сравнение с предишното използване на ръчна намеса за възстановяване на услугата, високодостъпната архитектура на RocketMQ предлага възможност за автоматично възстановяване от системни грешки, значително съкращаване на MTTR и подобряване на наличността на системата.
Картината по-долу описва превключването на крайни автомати в архитектурата с висока достъпност на RocketMQ:
Фигура 9
• След инициирането на първия възел, контролерът контролира състоянието на машината, за да превключи към състояние с един главен и уведомява инициирания възел да предоставя услуги като главен.
• При иницииране на втория възел, контролерът управлява машината за състояние, за да превключи в състояние на асинхронна репликация. Главният репликира данни към подчинения в асинхронен режим.
• Когато данните на подчиненото устройство са на път да наваксат тези на главния, контролерът контролира държавната машина да превключи в полусинхронизирано състояние, което гарантира задържането на заявка за запис, удряща главния, докато главният репликира данните от всички несъответствия към подчинения в асинхронен режим.
• В полусинхронизирано състояние, когато данните на подчинения напълно наваксат тези на главния, контролерът контролира крайната машина да превключи в режим на синхронна репликация. Главният започва да репликира данни към подчинения в синхронен режим. Ако възникне повреда в който и да е възел в това състояние, възможно е други възли да преминат към състояние с един главен в рамките на секунди, за да продължат да предоставят услугите.
Компонентът на контролера контролира RocketMQ, за да превключи машината на състоянието в реда на състояние на единичен главен, състояние на асинхронна репликация, състояние на полусинхронизация и окончателно състояние на синхронна репликация. Продължителността на междинните състояния е фактор за несъответствието на главния/подчинения данни и честотната лента на мрежата. Въпреки това, те в крайна сметка ще останат в състояние на синхронизирана репликация.
Заключение
След няколко години онлайн тестове, подобни на работни условия, все още има възможност за оптимизиране на механизма за съобщения на Alibaba Cloud. Екипът се опитва да намали допълнително забавянето на съхранението на съобщения чрез алгоритми за оптимизиране на съхранението и междуезични разговори. Пред нововъзникващи сценарии като Интернет на нещата, големи данни и VR, екипът започна да създава 4-то поколение двигатели за съобщения, включващи многостепенен протокол QoS. Освен това, той също така разполага с поддръжка на различни мрежи, между терминали и различни езици, по-ниско време за реакция за онлайн приложения и по-висока пропускателна способност за офлайн приложения. В идеята да вземем от отворен код и да върнем на същия отворен код, нашето убеждение е, че RocketMQ ще се развие към по-здравословна екология.
Справка
[1]Райън Барет. http://snarfed.org/transactions_across_datacenters_io.html
[2]http://www.slideshare.net/vimal25792/leaky-bucket-tocken-buckettraffic-shaping
[3] http://systemdesigns.blogspot.com/2015/12/rate-limiter.html
[4]Little J D C, Graves S C. Little's law [M]//Изграждане на интуиция. Springer US, 2008: 81–100.
[5]https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Performance_Tuning_Guide/index.html
[6]http://highscalability.com/blog/2012/3/12/google-taming-the-long-latency-tail-when-more-machines-equal.html
[7] https://www.azul.com/files/EnablingJavaInLatencySensitiveEnvs_DotCMSBootcamp_Nashville_23Oct20141.pdf
