Что такое CRDT в распределенных системах?
Я новичок в распределенных системах, и я пытаюсь получить представление о концепции CRDT. Я понимаю, что он имеет три обозначения :
Conflict-free Replicated Data Type
Convergent Replicated Data Type
Commutative Replicated Data Type
может ли кто - нибудь привести пример, где мы используем CRDT в распределенных системах? Большое спасибо заранее.
3 ответов
CRDTs вдохновлены работой Марка Шапиро. В распределенных вычислениях бесконфликтный реплицированный тип данных (сокращенно CRDT)-это тип специально разработанной структуры данных, используемой для достижения сильной конечной согласованности (SEC) и монотонности (отсутствие откатов). Существует два альтернативных пути обеспечения SEC: операционные CRDTs и государственные CRDTs.
CRDTs на разных репликах могут отличаться друг от друга, но в конце они могут быть безопасно объединены, обеспечивая согласованную стоимость. Другими словами, CRDTs имеют метод слияния, который является идемпотентным, коммутативным и ассоциативным.
эти две альтернативы эквивалентны, поскольку одна может эмулировать другую, но основанные на операциях CRDTs требуют дополнительных гарантий от промежуточного программного обеспечения связи. CRDTs используются для репликации данных на нескольких компьютерах в сети, выполняя обновления без необходимости удаленной синхронизации. Это приведет к слиянию конфликтов в системах, использующих обычные конечная технология согласованности, но CRDTs разработаны таким образом, что конфликты математически невозможны. Под ограничениями теоремы CAP они обеспечивают самые сильные гарантии согласованности для доступных / толерантных к разбиению (AP) настроек.
некоторые примеры, где они используются
Riak является самой популярной библиотекой с открытым исходным кодом CRDT и используется Bet365 и League of Legends. Ниже приведены некоторые полезные ссылки, которые поддерживают Riak.
1- Bet365 (использует Erlang и Riak) http://www.erlang-factory.com/static/upload/media/1434558446558020erlanguserconference2015bet365michaelowen.pdf
2 - League of Legends использует реализацию Riak CRDT для своей системы чата в игре (которая обрабатывает 7,5 миллионов одновременных пользователей и 11 000 сообщений в секунду)
3-Roshi реализовано SoundCloud, который поддерживает набор с отметкой времени LWW: -Блог: https://developers.soundcloud.com/blog/roshi-a-crdt-system-for-timestamped-events
CRDTs используют математику для обеспечения согласованности в распределенном кластере, не беспокоясь о консенсусе и связанной задержке/недоступности.
набор значений, которые CRDT может принимать в любое время, подпадает под категорию полурешетки (в частности, полурешетки соединения), которая является POSET (частично упорядоченным набором) с наименьшей функцией верхней границы (LUB).
проще говоря, POSET-это набор элементов, в которых не все сопоставимы. Е. Г. в массив пар: {(2,4), (4, 5), (2, 1), (6, 3)}, (2,4) is (4,5), но не может сравниться с (6,3) (поскольку один элемент больше, а другой меньше). Теперь полурешетка-это POSET, в котором заданы 2 пары, даже если вы не можете сравнить их, вы можете найти элемент больше обоих (LUB).
другое условие заключается в том, что обновления этого типа данных должны увеличиваться, CRDTs имеют монотонно увеличивающееся состояние, где клиенты никогда не наблюдают откат состояния.
этот отличная статья использует массив я использовал выше в качестве примера. Для CRDT, поддерживающего эти значения, если 2 реплики пытаются достичь консенсуса между (4,5) и (6,3), Они могут выбрать LUB = (6,5) как консенсус и назначить реплики. Поскольку значения
растут, это хорошее значение, чтобы поселиться на.
есть 2 способа для CRDTs синхронизировать друг с другом через реплики, они могут передавать состояние через периодически (конвергентная реплицированная тип данных), или они могут передавать обновления (дельты) по мере их получения (коммутативный реплицированный тип данных). Первый занимает больше полосы пропускания.
SoundCloud это Роси является хорошим примером (хотя больше не в разработке), они хранят данные, связанные с меткой времени, где метка времени явно увеличивается. Любые обновления, поступающие с меткой времени, меньшей или равной сохраненной, отбрасываются, что гарантирует идемпотентность (повторные записи в порядке) и коммутативность (из порядка записи в порядке. Коммутативность a=b means b=a, что в данном случае означает update1 с последующим update2 совпадает с update2 с последующим update1)
записи отправляются во все кластеры, и если некоторые узлы не отвечают из-за такой проблемы, как медленность или раздел, они, как ожидается, догонят позже через read-repair, что гарантирует, что значения сходятся. Конвергенция может быть достигнута с помощью 2 протоколов, как я упоминал выше, распространять состояние или обновления на другие точных копий. Я считаю, что Роши делает первое. Как часть read-repair, реплики обмениваются состоянием, и поскольку данные придерживаются свойства полурешетки, они сходятся.
PS. Системы, использующие CRDTs, в конечном итоге согласованы, i.e они принимают AP (высокодоступный и толерантный к разделу) в теорема CAP.
эти три расширения аббревиатуры означают в основном одно и то же.
CRDT сходится, если те же операции, применяемые в другой последовательности, дают (сходятся) тот же результат. То есть операции могут быть коммутированы - это коммутативный RDT. Причина, по которой операции могут применяться в другой последовательности и получать тот же результат, заключается в том, что операции не конфликтуют.
таким образом, CRDT означает то же самое, что и любой из трех расширения, которые вы используете, хотя лично я предпочитаю "конвергентные".