Согласованные в конечном счете (Eventually Consistent)
Введение
В основе облачных вычислений Amazon лежат инфраструктурные сервисы. Такие, как Amazon S3, SimpleDB и EC2. Они позволяют строить масштабируемые вычислительные платформы и приложения. Требования к этим сервисам весьма жесткие. Они должны обеспечивать отличную безопасность, масштабируемость, доступность, производительность и эффективное использование ресурсов. И всё это – во время обслуживания миллионов клиентов со всего мира.
Внутри эти сервисы представляют собой огромные распределенные системы, работающие в мировом масштабе. Что создаёт дополнительные сложности, поскольку при обработке триллионов и триллионов запросов, события, которые обычно случаются с весьма низкой вероятностью, теперь гарантированно случаются. И это нужно учитывать при проектировании и разработке системы. В мировых масштабах мы используем репликацию повсеместно, чтобы обеспечить требуемую производительность и высокую доступность. Хотя репликация и приближает нас к нашим цели, она всё же не позволяет нам прозрачно достичь их. Существует ряд нюансов, с которыми столкнутся пользователи сервисов, использующих репликацию.
Один из таких нюансов – тип согласованности данных, обеспечиваемый системой. В частности, многие распространенные распределенные системы используют модель «согласованность в конечном счете» (eventual consistency) в контексте репликации данных. При разработке больших масштабируемых систем в Amazon мы использовали набор правил и абстракций, связанных с репликацией данных в больших масштабируемых системах. Мы сфокусировались на поиске компромисса между высокой доступностью (high availability) и согласованностью данных. В этой статье я рассмотрю часть информации, сформировавшей наш подход к построению надежных распределенных систем, работающих в мировом масштабе.
Историческая перспектива
В идеальном мире существовала бы только одна модель согласованности: после выполнения обновления данных, все наблюдатели увидят обновления. Первые трудности с достижением этого возникли в СУБД в конце 70х. Лучшая работа на эту тему – «Notes on Distributed Databases» Брюса Линдсей. Он излагает основные принципы репликации баз данных и обсуждает ряд техник, связанных с достижением согласованности. Множество из этих техник пытается достичь прозрачности распределения – чтобы с точки зрения пользователя это выглядело как единая система, а не как множество связанных систем. Многие системы того времени следовали подходу, что лучше сбой всей системы, чем нарушение прозрачности.
В средине 90х, с ростом систем в интернете, эта практика была пересмотрена. В это время люди начали склоняться к мнению, что доступность – наиболее важное свойство, но они не могли решить, чем пожертвовать в качестве компромисса. Эрик Брюэр (Eric Brewer), профессор Беркли, который в то время был главой Inktomi (компания, выпустившая успешный поисковик, которая потом была поглощена Yahoo – прим. пер.), собрал все компромиссы воедино в докладе на конференции PODC в 2000 году. Он представил теорему CAP, которая утверждает, что из трех свойств систем с распределенными данными – согласованность данных (consistency), доступность системы при сбое одного из узлов (system availability) и устойчивость к потере связи между сегментами сети (partition tolerance) (здесь и далее под сегментированием сети подразумевается потеря связи между частями распределенной системы, когда каждая часть отдельно работоспособна, но они «не видят» друг друга – прим. пер.) – одновременно можно достичь только два. Более формализованное подтверждение опубликовано в статье Сета Гилберта и Ненси Линча в 2002.
Система, не обеспечивающая устойчивости к потере связи между сегментами сети, может достичь согласованности данных и доступности, что зачастую достигается использованием протокола транзакций. При этом, определенные ситуации обрабатываются как сбой системы. Например, если клиент не видит часть узлов. Стоит отметить, что в больших масштабируемых системах зачастую присутствует сегментирование, потому согласованность данных и доступность не достижимы одновременно. Это значит, что у нас есть два выбора: ослабить согласованность, что позволит создать систему с высокой доступностью в условиях сегментирования сети, или же акцентироваться на согласованности, что приведет к недоступности системы в определенных ситуациях.
Оба варианта требуют внимания разработчика клиентской части к возможностям системы. Если система акцентируется на целостности, то разработчик должен иметь ввиду, что система может оказаться недоступной, например, для записи и соответственно обрабатывать эту ситуацию, чтобы не потерять данные. Если же система акцентирует внимание на доступности, то она может всегда обеспечивать запись, но чтение данных в некоторых случаях не будет отражать результат недавно осуществленной записи. Разработчику приходится решать, действительно ли клиенту необходимы самые-самые последние изменения. Во многих случаях допустимо использовать слегка устаревшие данные.
В принципе, согласованность в транзакционных системах, соответствующих ACID, – это несколько другой вид обеспечения согласованности. В ACID под согласованностью подразумевается гарантия, что по завершению транзакции база данных находится в согласованном состоянии. Например, при переводе денег между счетами, сумма денег на счетах не должна измениться. В системах, соответствующих ACID, этот вид согласованности, как правило, обеспечивается использованием транзакций и средств базы по обеспечению целостности данных.
Согласованность – клиент и сервер
Существует два взгляда на согласованность. Один с точки зрения разработчика/клиента: как они видят обновления данных. Второй – со стороны сервера: как проходят обновления в системе и что система может гарантировать относительно апдейтов.
Согласованность с точки зрения клиента
С точки зрения клиента у нас есть следующие компоненты:
Система хранения. На данный момент мы рассматриваем её как черный ящик. Но учитываем, что внутри нечто в высокой степени масштабируемое и распределенное, построенное для обеспечения устойчивости и доступности.
Процесс А. Процесс, который пишет в систему хранения и читает из неё.
Процессы В и С. Два процесса, не зависящие от процесса А, которые также пишут систему хранения и читают из неё. Не важно, являются ли они процессами или потоками одного процесса. Важно лишь то, что они независимы и должны взаимодействовать для обмена информацией.
Клиентская (client-side) согласованность определяет, как и когда наблюдатели (в нашем случае процессы А, В и С) видят изменения объекта данный в системе хранения. В следующих примерах, иллюстрирующих различные типы согласованности, процесс А выполнил обновление (update) данных.
Сильная согласованность (Strong consistency). После завершения обновления, любой последующий доступ к данным (Процессом А, В или С) вернет обновленное значение.
Слабая согласованность (Weak consistency). Система не гарантирует, что последующие обращения к данным вернут обновленное значение. Перед тем, как будет возвращено обновленное значение, должен выполниться ряд условий. Период между обновлением и моментом, когда каждый наблюдатель всегда гарантированно увидит обновленное значение, называется окном несогласованности (inconsistency window).
Согласованность в конечном счете (Eventual consistency). Частный случай слабой согласованности. Система гарантирует, что, при отсутствии новых обновлений данных, в конечном счете, все запросы будут возвращать последнее обновленное значение. При отсутствии сбоев, максимальный размер окна несогласованности может быть определен на основании таких факторов, как задержка связи, загруженность системы и количество реплик в соответствии со схемой репликации. Самая популярная система, реализующая «согласованность в конечном счете» – DNS. Обновленная запись распространяется в соответствии с параметрами конфигурации и настройками интервалов кэшированя. В конечном счете, все клиенты увидят обновление.
Согласованность в конечном счете (Eventual consistency) имеет множество вариаций, которые важно учитывать:
Причинная согласованность (Causal consistency). Если процесс А сообщил процессу В, что обновил данные, то последующие обращения процесса В к этим данным будут возвращать обновленные значения и запись гарантированно замещает более раннюю. Доступ процесса С, который не находится в причинной связи с процессом А, подчиняется обычным правилам eventual consistency.
Модель согласованности «Читай то, что записал» (Read-your-writes consistency). Это важная модель, в которой процесс А после обновления данных всегда при обращении получает обновленное значение и никогда не видит более старого. Это частный случай причинной согласованности (causal consistency).
Сессионная согласованность (Session consistency). Это практическая версия предыдущей модели, когда процесс получает доступ к хранилищу в контексте сессии. Пока сессия существует, система гарантирует Read-your-writes согласованность. Если же сессия завершается по причине какого-либо сбоя, то должна создаваться новая сессия, гарантированно не перекрывающаяся с другими.
Модель согласованности «однообразное чтение» (Monotonic read consistency). Если процесс увидел определенное значение, то, при последующих обращениях к этим данным, он никогда не получит более старое значение.
Модель согласованности «однообразная запись» (Monotonic write consistency). В этом варианте система гарантирует упорядоченность записи одного процесса. Системы, не обеспечивающие этот уровень согласованности, сложны в использовании.
Некоторые из этих вариаций могут быть скомбинированы. Например, можно объединить monotonic reads и сессионную согласованность. С практической точки зрения, monotonic reads и read-your-writes наиболее желанны в системах, реализующих «согласованность в конечном счете», но не всегда необходимы. Такая комбинация облегчает разработку приложений, позволяя при этом системе хранения ослабить согласованность и обеспечить высокую доступность.
«Согласованность в конечном счете» (Eventual consistency) не является какой-то эзотерической поэзией экстремальных распределенных систем. Многие современные реляционные СУБД, обеспечивающие надежность дублированием на резервный сервер (primary-backup reliability), реализуют работу механизма репликации в двух режимах: синхронном и асинхронном. В синхронном режиме обновление реплики является частью транзакции. В асинхронном режиме обновление доставляется как бекап, с некоторой задержкой, зачастую через доставку логов. В последнем случае, если основной сервер откажет до того, как лог был доставлен, то чтение с резервного сервера, поднятого вместо основного, вернет нам устаревшие данные. Также, для обеспечения лучшей масштабируемости чтения, реляционные СУБД начали предоставлять возможность чтения с резервного сервера, что является классическим случаем гарантий «согласованности в конечном счете», в котором размер окна несогласованности зависит от периодичности отправки лога.
Консистентность и ACID-гарантии в распределенных системах хранения данных
Распределенные системы используют, когда возникает необходимость в горизонтальном масштабировании, чтобы обеспечить повышенные показатели производительности, которые не способна обеспечить за адекватные деньги вертикально масштабированная система.
Как и переход с однопоточной парадигмы на многопоточную, миграция на распределенную систему требует своего рода погружения и понимания того, как это работает внутри, на что нужно обращать внимание.
Одна из проблем, которая встает перед человеком, который хочет мигрировать проект на распределенную систему или начать на ней проект, — какой продукт выбрать.
Мы, как компания, которая «собаку сьела» в разработке систем такого рода, помогаем нашим клиентам взвешенно принимать такие решения применительно к распределенным системам хранения. Также мы выпускаем серию вебинаров для более широкой аудитории, которые посвящены базовым принципам, рассказанным простым языком, и безотносительно каких-то конкретных продуктовых предпочтений помогают составить карту значимых характеристик, чтобы облегчить выбор.
Эта статья основана на наших материалах по консистентности и ACID-гарантиям в распределенных системах.
Что это такое и зачем это нужно?
«Согласованность данных (иногда консистентность данных, англ. data consistency) — согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.» (Wikipedia)
Согласованность подразумевает, что в любой момент времени приложения могут быть уверены, что работают с корректной, технически актуальной версией данных, и могут расчитывать на нее при принятии решений.
В распределенных системах обеспечивать согласованность становится сложнее и дороже, потому что появляется целый ряд новых вызовов, связанных с сетевым обменом между различными узлами, возможностью отказа отдельных узлов и — зачастую — отсутствием единой памяти, которая может служить для верификации.
Например, если у меня есть система из 4 узлов: A, B, C и D, которая обслуживает банковские транзакции, и узлы C и D отделились от A и B (скажем, из-за сетевых проблем), вполне возможно, я теперь не имею доступа к части транзакций. Как мне действовать в этой ситуации? Разные системы принимают разные подходы.
На верхнем уровне есть 2 ключевых направления, которые выражены в CAP-теореме.
«Теорема CAP (известная также как теорема Брюера) — эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:
Когда CAP-теорема говорит о консистентности, она подразумевает достаточно строгое определение, включающее линеаризацию записей и чтений, и оговаривает только консистетность при записи отдельных значений. (Martin Kleppman)
CAP-теорема говорит о том, что если мы хотим быть устойчивы к сетевым проблемам, то мы в целом должны выбрать, чем жертвовать: консистентностью или доступностью. Есть также расширенная версия этой теоремы — PACELC (Wikipedia), которая дополнительно рассказывает о том, что даже в отсутствии сетевых проблем мы должны выбирать между скоростью отклика и консистетностью.
И хотя, на первый взгляд выходца из мира классических СУБД, кажется, что выбор очевиден, и консистетность — самое главное, что у нас есть, это далеко не всегда так, что ярко иллюстрирует взрывной рост целого ряда NoSQL СУБД, которые сделали другой выбор и, несмотря на это, получили огромную пользовательскую базу. Apache Cassandra с ее знаменитой eventual consistency является хорошим примером.
Все из-за того, что это выбор, который подразумевает, что мы чем-то жертвуем, и далеко не всегда мы этим жертвовать готовы.
Часто проблема консистентности в распределенных системах решается просто отказом от этой консистентности.
Но нужно и важно понимать, когда отказ от этой консистентности допустим, а когда она является бизнес-критичным требованием.
Например, если я проектирую компонент, который отвечает за хранение пользовательских сессий, здесь мне, скорее всего, консистентность не так важна, да и потеря данных некритична, если она происходит только в проблемных случаях — очень редко. Худшее, что случится, — пользователю нужно будет перелогиниться, и для многих бизнесов это практически никак не повлияет на их финансовые показатели.
Если я делаю аналитику на потоке данных с датчиков, во многих случаях мне совсем некритично потерять часть данных и получить на небольшом промежутке времени пониженную дискретизацию, особенно, если «eventually» данные я все-таки увижу.
Но если я делаю банковскую систему, консистентность денежных проводок критична для моего бизнеса. Если я начислил пеню на кредит клиента из-за того, что просто не увидел в срок внесенный платеж, хотя он был в системе — это очень-очень плохо. Как и если клиент может несколько раз снять все деньги с моей кредитной карты, потому что у меня в момент проведения транзакции возникли сетевые проблемы, и на часть моего кластера информация о снятии не дошла.
Если вы оформляете дорогостоящую покупку в интернет-магазине, вы не хотите, чтобы о вашем заказе забыли, несмотря на рапортующую об успехе веб-страницу.
Но если вы делаете выбор в пользу консистентности, вы жертвуете доступностью. И зачастую это ожидается, скорее всего, вы не раз сталкивались с этим лично.
Лучше, если корзина интернет-магазина скажет «попробуйте позднее, распределенная СУБД недоступна», чем если отрапортует об успехе и забудет заказ. Лучше получить отказ в транзакции из-за недоступности сервисов банка, чем отбивку об успехе и потом разбирательства с банком из-за того, что он забыл, что вы внесли платеж по кредиту.
Наконец, если мы смотрим на расширенную, PACELC теорему, то мы понимаем, что даже в случае штатной работы системы, выбирая консистентность, мы можем жертвовать низкими задержками, получая потенциально более низкий уровень максимальной производительности.
Поэтому, отвечая на вопрос «зачем это нужно?»: это нужно, если для вашей задачи критично иметь актуальные, целостные данные, и альтернатива принесет вам существенные потери, большие, чем временная недоступность сервиса на период инцидента или его более низкая производительность.
Как это обеспечить?
Соответственно, первое решение, которое вам нужно принять — где вы находитесь в CAP-теореме, вы хотите консистентность или доступность в случае инцидента.
Далее нужно понять, на каком уровне вы хотите проводить изменения. Возможно, вам хватит обычных атомарных записей, затрагивающих единственный объект, как умела и умеет MongoDB (сейчас она расширяет это дополнительно поддержкой полноценных транзакций). Напомню, что CAP-теорема ничего не говорит о консистентности операций записи, затрагивающих множественные объекты: система вполне может быть CP (т.е. предпочитать консистентность доступности) и при этом предоставлять только атомарные одиночные записи.
Если вам этого не хватает, мы начинаем подходить к концепции полноценных распределенных ACID-транзакций.
Замечу, что даже переходя в дивный новый мир распределенных ACID-транзакций, мы зачастую вынуждены чем-то жертвовать. Так например, ряд распределенных систем хранения имеет распределенные транзакции, но только в рамках одной партиции. Или, например, система может не поддерживать «I»-часть на нужном вам уровне, не имея изоляции, либо имея недостаточное количество уровней изоляции.
Эти ограничения зачастую были сделаны по какой-то причине: либо для упрощения реализации, либо, например, для повышения производительности, либо для чего-то еще. Они достаточны для большого количества кейсов, поэтому не стоит рассматривать их как минусы сами по себе.
Нужно понять, являются ли эти ограничения проблемой для вашего конкретного сценария. Если нет, — у вас есть более широкий выбор, и вы можете больший вес дать, например, показателям производительности или способности системы обеспечивать катастрофоустойчивость и т.д. Наконец, нужно не забывать, что у ряда систем эти параметры могут настраиваться вплоть до того, что система может быть CP или AP в зависимости от конфигурации.
Если наш продукт стремится быть CP, то обычно у него есть либо кворумный подход к выбору данных, либо выделенные узлы, которые являются основными владельцами записей, через них проходят все изменения данных, и в случае сетевых проблем, если эти мастер-узлы не могут дать ответ, считается, что данные в принципе, невозможно получить, либо арбитраж, когда внешний высокодоступный компонент (например, кластер ZooKeeper) может говорить, какой из сегментов кластера является основным, содержит актуальную версию данных и может эффективно обслуживать запросы.
Наконец, если нас интересует не просто CP, но поддержка полноценных распределенных ACID-транзакций, то зачастую или используется все же единый источник истины, например, централизованное дисковое хранилище, где наши узлы, по сути, выступают лишь кешами к нему, которые можно инвалидировать в момент коммита, или применяется протокол многофазового коммита.
Первый подход с единым диском также упрощает реализацию, дает низкие задержки на распределенных транзакциях, но торгует взамен очень ограниченной масштабируемостью на нагрузках с большими объемами записи.
Второй подход дает намного больше свободы в масштабировании, и, в свою очередь, делится на двухфазный (Wikipedia) и трехфазный (Wikipedia) протоколы коммита.
Рассмотрим на примере двухфазного коммита, который использует, например, Apache Ignite.

Процедура коммита делится на 2 фазы: prepare и commit.
На фазе prepare рассылается сообщение о подготовке к коммиту, и каждый участник при необходимости делает блокировку, выполняет все операции вплоть до фактического commit не включительно, рассылает prepare на свои реплики, если это предполагается продуктом. Если хотя бы один из участников ответил по какой-то причине отказом или оказался недоступен — данные фактически не поменялись, коммита не было. Участники откатывают изменения, снимают блокировки и возвращаются на исходное состояние.
На фазе commit отправляется фактическое выполнение commit на узлах кластера. Если по какой-то причине часть узлов была недоступна или ответила ошибкой, то к этому времени данные занесены в их redo-лог (поскольку prepare был выполнен успешно), и коммит в любом случае может быть завершен хотя бы в отложенном состоянии.
Наконец, если отказывает координатор, то на prepare-этапе коммит будет отменен, на commit-этапе может быть выбран новый координатор, и, если все узлы выполнили prepare, он может проверить и обеспечить выполнение этапа commit.
Разные продукты имеют свои особенности реализации и оптимизации. Так, например, некоторые продукты умеют в отдельных случаях сводить 2-х фазный коммит к 1-фазному, значительно выигрывая по производительности.
Выводы
Ключевой вывод: распределенные системы хранения данных — это достаточно развитый рынок, и продукты на нем могут обеспечивать высокую консистентность данных.
При этом продукты этой категории находятся на разных точках шкалы консистентности, от полностью AP-продуктов без какой-либо транзкционности, до CP-продуктов, которые дополнительно дают еще и полноценные ACID-транзакции. Часть продуктов может быть настроена в одну или в другую сторону.
Когда вы выбираете, что нужно вам, нужно учитывать потребности вашего кейса и хорошо понимать, на какие жертвы и компромиссы вы готовы пойти, потому что ничего не бывает бесплатно, и выбирая одно, вы, скорее всего, откажетесь от чего-то другого.
Оценивая продукты с этой стороны, стоит обращать внимание на то:
Eventual consistency что это
Продолжая включать интересные практические примеры в наши курсы Apache Kafka для разработчиков, сегодня поговорим о согласованности в распределенных системах с высокой доступностью. Читайте далее, что такое eventual consistency, почему это важно для микросервисной архитектуры, при чем здесь ограничения CAP-теоремы и как решить проблемы обеспечения конечной согласованности с Kafka Streams.
Что такое eventual consistency или как хакнуть CAP-теорему в распределенных микросервисах
Простота реализации микросервисных решений часто оборачивается сложностью их проектирования. В частности, если один из сервисов изменил состояние какого-то объекта, другие сервисы должны знать об этом как можно скорее (в идеале – сразу же), чтобы избежать несогласованности данных. К примеру, работы по сборке и доставке товара начнутся только после того, как заказ оплачен, и желательно, сразу же после наступления этого события. При этом за процессы создания заказа, оплаты, сборки и доставки отвечают разные сервисы.
Однако, добиться такой согласованности данных в распределенных системах не так-то просто. Не случайно CAP-теорема для распределенных систем гласит, что из 3 возможных состояний (Consistency – Согласованность, Availability – Доступность и Partition tolerance – Устойчивость к разделению) одновременно возможны лишь 2. При этом для микросервисов достижение максимальной согласованности является наиболее затратным из-за требований к распределенным транзакциям с двухфазной фиксацией (2PC). Такие транзакции имеют низкую производительность, ограниченную масштабируемость и требуют тесной связи сервисов друг с другом. Напомним, согласованность является одним из 4-х ключевых свойств ACID (Atomicity – атомарность, Consistency – консистентность, Isolation – изолированность, Durability – долговечность), характерных для транзакций. В случае микросервисов необходимо гарантировать ACID транзакций в распределенной системе с низкими затратами при сохранении слабосвязанной архитектуры.
Чаще всего из всех моделей согласованности для распределенных систем современные микросервисные архитектуры выбирают конечную согласованность (eventual consistency) [2].
Это обеспечивает высокую доступность, гарантируя, что в отсутствии изменений данных, через какой-то промежуток времени после последнего обновления, т.е. в конечном счёте, все запросы будут возвращать последнее обновлённое значение. Например, обновлённая DNS-запись распространится по серверам согласно настройкам интервалов кэширования, в результате чего в конечном счёте все клиенты увидят обновление, хотя и не в то же мгновение. Таким образом, eventual consistency гарантирует асинхронное применение изменений с некоторой задержкой времени [3].
Но главной проблемой асинхронного обмена сообщениями является отсутствие каких-либо гарантий для потребителей относительно логического порядка получения событий от производителей. Например, сообщение об оплате заказа получено перед сообщением о новом заказе, что вызовет попытку обработки как будто не существующего объекта. Это можно решить, сохранив сообщение об оплате и повторно обработать его после получения и обработки сообщения о новом заказе. Реализовать такой подход можно с помощью обмена сообщениями или платформы обработки событий с разделением системы и базы данных (кэша) для отслеживания состояния обработки объектов, а также через приложения Apache Kafka Streams. Почему именно это является наиболее простым, легким в реализации и масштабируемым решением, мы рассмотрим далее.
Как Kafka Streams обеспечивает конечную согласованность распределенных микросервисов
Kafka Streams API – это клиентская библиотека для разработки приложений, обрабатывающих записи из топиков в Apache Kafka. Приложение Kafka Streams обрабатывает потоки данных (записи) через топологии процессоров из топиков, хранилищ состояний и узлов процессора. Приложение Kafka Streams потребляет и создает сообщения, которые постоянно хранятся в топиках и хранилищах состояний. Потоки Kafka можно масштабировать, разбивая топики так, чтобы несколько задач и потоков могли обрабатывать данные параллельно, в т.ч. с отслеживанием состояния (stateful), когда записи обрабатываются на основе их исторических состояний. Раздел топика обрабатывается выделенной задачей или потоком. Алгоритм назначения разделов Kafka Streams API гарантирует, что записи с одним и тем же первичным ключом обрабатываются последовательно, а хранилище состояний для раздела используется исключительно назначенной задачей или потоком. Записи с одним и тем же первичным ключом гарантированно попадают в один и тот же раздел, что позволяет обрабатывать их «последовательно» по времени события в Kafka Streams.
Таким образом, Kafka Streams отлично походит для реализации конечной согласованности распределенных микросервисных систем, дополнительно обеспечивая отказоустойчивость, масштабируемость и производительность [1]:
Именно поэтому разработчики международной финтех-компании BlackRock, о которых мы рассказывали вчера на примере обеспечения расширенной безопасности Apache Kafka, использовали API Kafka Streams для своей веб-платформы управления ликвидностью, одобренной крупными банками и корпорациями по управлению активами. Приложение Cachematrix Cloud Connector для портала Cachematrix Liquidity Trading Portal представляет собой сервис «Интеграция как услуга» в реальном времени, соединяя разные внешние банковские системы и системы Transfer Agent (TA) с мультитенантным порталом Cachematrix. В качестве брокера сообщений и платформы потоковой передачи собыйтий используется Apache Kafka. А необходимые функции сохранения сообщений и их stateful-обработки реализованы с помощью Kafka Streams API, гарантируя конечную согласованность с высокой отказоустойчивостью, стабильностью и производительностью [1].
Узнайте все тонкости разработки распределенных приложений потоковой аналитики больших данных и администрирования кластеров Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
