Проектиране на опашки от съобщения: Гарантиране на последователността на съобщенията

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

Защо последователността на съобщенията е важна

Последователността на съобщенията е от решаващо значение в сценарии, при които редът на събитията е важен за поддържане на консистентността на данните и логиката на приложението. Разгледайте тези примери:

• Финансови трансакции: В една банкова система операциите по дебит и кредит трябва да се обработват в правилния ред, за да се предотвратят овърдрафти или неправилни салда. Дебитно съобщение, пристигнало след кредитно съобщение, може да доведе до неточно състояние на сметката.
• Обработка на поръчки: В платформа за електронна търговия, съобщенията за направена поръчка, обработка на плащане и потвърждение за изпращане трябва да се обработват в правилната последователност, за да се осигури гладко клиентско изживяване и точно управление на наличностите.
• Event Sourcing: В система, базирана на събития (event-sourced), редът на събитията представлява състоянието на приложението. Обработката на събития извън реда може да доведе до повреда на данните и несъответствия.
• Новини в социалните медии: Въпреки че евентуалната консистентност (eventual consistency) често е приемлива, показването на публикации извън хронологичен ред може да бъде разочароващо потребителско изживяване. Често се желае подредба в почти реално време.
• Управление на инвентара: При актуализиране на нивата на наличностите, особено в разпределена среда, гарантирането, че добавянията и изважданията от склада се обработват в правилния ред, е жизненоважно за точността. Сценарий, при който продажба се обработва преди съответното добавяне в склада (поради връщане), може да доведе до неправилни нива на наличностите и потенциално свръхпродажба.

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

Предизвикателства при поддържането на последователността на съобщенията

Поддържането на реда на съобщенията в разпределена опашка от съобщения е предизвикателство поради няколко фактора:

• Разпределена архитектура: Опашките от съобщения често работят в разпределена среда с множество брокери или възли. Гарантирането, че съобщенията се обработват в същия ред на всички възли, е трудно.
• Едновременност (Concurrency): Множество потребители (consumers) могат да обработват съобщения едновременно, което потенциално може да доведе до обработка извън реда.
• Откази: Откази на възли, мрежови разделяния или сривове на потребители могат да нарушат обработката на съобщения и да доведат до проблеми с подредбата.
• Повторни опити за съобщения: Повторното изпращане на неуспешни съобщения може да създаде проблеми с подредбата, ако повтореното съобщение бъде обработено преди следващите съобщения.
• Балансиране на натоварването: Разпределянето на съобщения между множество потребители с помощта на стратегии за балансиране на натоварването може по невнимание да доведе до обработка на съобщения извън реда.

Стратегии за гарантиране на последователността на съобщенията

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

1. Единична опашка, единичен потребител

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

Предимства:

• Лесен за внедряване
• Гарантира стриктна последователност

Недостатъци:

• Ограничена мащабируемост и пропускателна способност
• Единична точка на отказ (Single point of failure)

2. Разделяне (Partitioning) с ключове за подредба

По-мащабируем подход е разделянето на опашката на базата на ключ за подредба. Съобщенията със същия ключ за подредба се гарантира, че ще бъдат доставени в една и съща партиция, а потребителите обработват съобщенията във всяка партиция по ред. Често срещани ключове за подредба могат да бъдат ID на потребител, ID на поръчка или номер на сметка. Това позволява паралелна обработка на съобщения с различни ключове за подредба, като същевременно се запазва редът в рамките на всеки ключ.

Пример:

Разгледайте платформа за електронна търговия, където съобщенията, свързани с конкретна поръчка, трябва да се обработват по ред. ID-то на поръчката може да се използва като ключ за подредба. Всички съобщения, свързани с поръчка с ID 123 (напр. направена поръчка, потвърждение на плащане, актуализации за доставка), ще бъдат насочени към една и съща партиция и обработени по ред. Съобщенията, свързани с друго ID на поръчка (напр. ID на поръчка 456), могат да се обработват едновременно в друга партиция.

Популярни системи за опашки от съобщения като Apache Kafka и Apache Pulsar предоставят вградена поддръжка за разделяне с ключове за подредба.

Предимства:

• Подобрена мащабируемост и пропускателна способност в сравнение с единична опашка
• Гарантира последователност в рамките на всяка партиция

Недостатъци:

• Изисква внимателен избор на ключа за подредба
• Неравномерното разпределение на ключовете за подредба може да доведе до "горещи" партиции (hot partitions)
• Сложност при управлението на партиции и потребители

3. Поредни номера

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

Пример:

Разпределена система за регистриране (logging) получава лог съобщения от множество сървъри. Всеки сървър присвоява пореден номер на своите лог съобщения. Агрегаторът на логове буферира съобщенията и ги обработва в реда на поредните номера, като гарантира, че лог събитията са подредени правилно, дори ако пристигнат извън реда поради мрежови закъснения.

Предимства:

• Осигурява гъвкавост при обработката на съобщения извън реда
• Може да се използва с всяка система за опашки от съобщения

Недостатъци:

• Изисква логика за буфериране и пренареждане от страна на потребителя
• Повишена сложност при обработката на липсващи съобщения и повторни опити
• Потенциал за увеличено забавяне (latency) поради буферирането

4. Идемпотентни потребители

Идемпотентността е свойството на операция, която може да бъде приложена многократно, без да променя резултата след първоначалното приложение. Ако потребителите са проектирани да бъдат идемпотентни, те могат безопасно да обработват съобщения многократно, без да причиняват несъответствия. Това позволява семантика на доставка "поне веднъж" (at-least-once), при която се гарантира, че съобщенията се доставят поне веднъж, но може да бъдат доставени повече от веднъж. Въпреки че това не гарантира стриктна последователност, то може да се комбинира с други техники, като поредни номера, за да се осигури евентуална консистентност, дори ако съобщенията пристигнат първоначално извън реда.

Пример:

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

Предимства:

• Опростява дизайна на опашката от съобщения, като позволява доставка "поне веднъж"
• Намалява въздействието от дублиране на съобщения

Недостатъци:

• Изисква внимателно проектиране на потребителите, за да се гарантира идемпотентност
• Добавя сложност към логиката на потребителя
• Не гарантира последователност на съобщенията

5. Модел "Трансакционна изходяща кутия" (Transactional Outbox)

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

Как работи:

1. Когато приложението трябва да актуализира базата данни и да публикува съобщение, то вмъква съобщение в таблица "outbox" в рамките на същата трансакция в базата данни като актуализацията на данните.
2. Отделен процес (напр. проследяващ трансакционния лог на базата данни или планирана задача) наблюдава таблицата "outbox".
3. Този процес чете съобщенията от таблицата "outbox" и ги публикува в опашката от съобщения.
4. След като съобщението е успешно публикувано, процесът маркира съобщението като изпратено (или го изтрива) от таблицата "outbox".

Пример:

Когато е направена нова клиентска поръчка, приложението вмъква детайлите на поръчката в таблицата `orders` и съответно съобщение в таблицата `outbox`, всичко това в рамките на една и съща трансакция в базата данни. Съобщението в таблицата `outbox` съдържа информация за новата поръчка. Отделен процес чете това съобщение и го публикува в опашка `new_orders`. Това гарантира, че съобщението се публикува само ако поръчката е успешно създадена в базата данни и че съобщението не се губи, ако приложението се срине преди да го публикува. Освен това, използването на ID на клиента като ключ за разделяне при публикуване в опашката от съобщения гарантира, че всички съобщения, свързани с този клиент, се обработват по ред.

Предимства:

• Гарантира надеждна доставка на съобщения и атомарност между актуализациите на базата данни и публикуването на съобщения.
• Може да се комбинира с разделяне, за да се гарантира подредена доставка на свързани съобщения.

Недостатъци:

• Добавя сложност към приложението и изисква отделен процес за наблюдение на таблицата "outbox".
• Изисква внимателно обмисляне на нивата на изолация на трансакциите в базата данни, за да се избегнат несъответствия в данните.

Избор на правилната стратегия

Най-добрата стратегия за гарантиране на последователността на съобщенията зависи от специфичните изисквания на приложението. Обмислете следните фактори:

• Изисквания за мащабируемост: Каква пропускателна способност е необходима? Може ли приложението да толерира един-единствен потребител, или е необходимо разделяне?
• Изисквания за последователност: Необходима ли е стриктна последователност за всички съобщения, или последователността е важна само за свързани съобщения?
• Сложност: Колко сложност може да понесе приложението? Простите решения като единична опашка са по-лесни за внедряване, но може да не се мащабират добре.
• Устойчивост на грешки (Fault Tolerance): Колко устойчива трябва да бъде системата на откази?
• Изисквания за забавяне (Latency): Колко бързо трябва да се обработват съобщенията? Буферирането и пренареждането могат да увеличат забавянето.
• Възможности на системата за опашки от съобщения: Какви функции за подредба предоставя избраната система за опашки от съобщения?

Ето ръководство за вземане на решения, което да ви помогне да изберете правилната стратегия:

• Стриктна последователност, ниска пропускателна способност: Единична опашка, единичен потребител
• Подредени съобщения в контекст (напр. потребител, поръчка), висока пропускателна способност: Разделяне с ключове за подредба
• Справяне с редки съобщения извън реда, гъвкавост: Поредни номера с буфериране
• Доставка "поне веднъж", дублирането на съобщения е приемливо: Идемпотентни потребители
• Гарантиране на атомарност между актуализации на базата данни и публикуване на съобщения: Модел "Трансакционна изходяща кутия" (може да се комбинира с разделяне за подредена доставка)

Съображения относно системите за опашки от съобщения

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

• Гаранции за последователност: Предоставя ли системата стриктна последователност, или гарантира последователност само в рамките на една партиция?
• Поддръжка на разделяне (Partitioning): Поддържа ли системата разделяне с ключове за подредба?
• Семантика "точно веднъж" (Exactly-Once): Предоставя ли системата семантика "точно веднъж", или предоставя само семантика "поне веднъж" или "най-много веднъж"?
• Устойчивост на грешки (Fault Tolerance): Колко добре се справя системата с откази на възли и мрежови разделяния?

Ето кратък преглед на възможностите за подредба на някои популярни системи за опашки от съобщения:

• Apache Kafka: Осигурява стриктна последователност в рамките на една партиция. Съобщенията със същия ключ се гарантира, че ще бъдат доставени в една и съща партиция и обработени по ред.
• Apache Pulsar: Осигурява стриктна последователност в рамките на една партиция. Също така поддържа дедупликация на съобщения, за да се постигне семантика "точно веднъж".
• RabbitMQ: Поддържа единична опашка, единичен потребител за стриктна последователност. Също така поддържа разделяне чрез типове exchange и ключове за маршрутизация (routing keys), но последователността не е гарантирана между партициите без допълнителна логика от страна на клиента.
• Amazon SQS: Предоставя подредба на принципа "най-добро усилие" (best-effort). Съобщенията обикновено се доставят в реда, в който са изпратени, но е възможна доставка извън реда. Опашките SQS FIFO (First-In-First-Out) предоставят обработка "точно веднъж" и гаранции за последователност.
• Azure Service Bus: Поддържа сесии на съобщения (message sessions), които предоставят начин за групиране на свързани съобщения и гарантират, че те се обработват по ред от един-единствен потребител.

Практически съображения

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

• Мониторинг и известяване: Внедрете мониторинг и известяване за откриване на съобщения извън реда и други проблеми с последователността.
• Тестване: Тествайте щателно системата за опашки от съобщения, за да се уверите, че отговаря на изискванията за последователност. Включете тестове, които симулират откази и едновременна обработка.
• Разпределено проследяване (Distributed Tracing): Внедрете разпределено проследяване, за да следите съобщенията, докато преминават през системата, и да идентифицирате потенциални проблеми с последователността. Инструменти като Jaeger, Zipkin и AWS X-Ray могат да бъдат безценни за диагностициране на проблеми в архитектурите на разпределени опашки от съобщения. Чрез маркиране на съобщенията с уникални идентификатори и проследяване на пътя им през различните услуги, можете лесно да идентифицирате точки, където съобщенията се забавят или обработват извън реда.
• Размер на съобщението: По-големите размери на съобщенията могат да повлияят на производителността и да увеличат вероятността от проблеми с последователността поради мрежови закъснения или ограничения на опашката от съобщения. Обмислете оптимизиране на размера на съобщенията чрез компресиране на данни или разделяне на големи съобщения на по-малки части.
• Времена за изчакване (Timeouts) и повторни опити: Конфигурирайте подходящи времена за изчакване и политики за повторни опити, за да се справите с временни откази и мрежови проблеми. Въпреки това, имайте предвид въздействието на повторните опити върху последователността на съобщенията, особено в сценарии, при които съобщенията могат да бъдат обработени многократно.

Заключение

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