реплицируется это что такое

Значение слова «реплицировать»

РЕПЛИЦИ’РОВАТЬ, рую, руешь, сов. и несов. (театр., муз.). Подать (подавать) реплики, делать реплики (см. реплика в 1, 2 и 5 знач.).

Источник: «Толковый словарь русского языка» под редакцией Д. Н. Ушакова (1935-1940); (электронная версия): Фундаментальная электронная библиотека

реплици́ровать

1. театр. муз. подать (подавать) реплики, делать реплики

2. спец. производить (произвести) репликацию; создавать (создать) синхронную копию ◆ На заре развития жизни, реплицировать свою ДНК клетки умели плохо, а делать это надо было быстро, геномы поневоле были маленькими и экономными. Марина Фридман, «Генетика — наука. Просто надо думать» // «Знание — сила», 2005 г. (цитата из НКРЯ) ◆ В MS Access есть пункт «репликация», который позволяет создавать копию – реплицировать базу данных на определённую дату. А. Н. Гущин, «Базы данных», 2015 г. (цитата из библиотеки Google Книги)

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.

Насколько понятно значение слова склочница (существительное):

Источник

Значение слова «реплицироваться»

реплицироваться

1. комп. соединиться с корпоративным сервером по модему из удаленного от офиса места, обычно чтобы скачать почту

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.

Насколько понятно значение слова невралгия (существительное):

Синонимы к слову «реплицироваться&raquo

Предложения со словом «реплицироваться&raquo

Понятия, связанные со словом «реплицироваться»

Отправить комментарий

Предложения со словом «реплицироваться&raquo

Гены выстраивают организмы, поведение которых позволяет им реплицироваться, – иначе означенные гены уже прекратили бы существование.

Эти модификации опосредуют взаимодействие 3’-конца с клеточными белками типа поли-A-связывающего белка и кэп-связывающего комплекса, что приводит к формированию нековалентно замкнутых функциональных комплексов, которые могут повторно промотировать трансляцию рибосомами и повторно реплицироваться RdRp’s.

Таким образом объясняются некоторые формы суицидального поведения, приковывающие к себе внимание средств массовой информации (например, прыжки с небоскрёбов), поскольку некоторые самоубийственные мимы могут таким образом реплицироваться дальше.

Синонимы к слову «реплицироваться&raquo

Карта слов и выражений русского языка

Онлайн-тезаурус с возможностью поиска ассоциаций, синонимов, контекстных связей и примеров предложений к словам и выражениям русского языка.

Справочная информация по склонению имён существительных и прилагательных, спряжению глаголов, а также морфемному строению слов.

Сайт оснащён мощной системой поиска с поддержкой русской морфологии.

Источник

Путеводитель по репликации баз данных

Повторяться, но каждый раз по-новому – разве не это есть искусство?

Станислав Ежи Лец, из книги «Непричёсанные мысли»

Словарь определяет репликацию как процесс поддержания двух (или более) наборов данных в согласованном состоянии. Что такое «согласованное состояние наборов данных» – отдельный большой вопрос, поэтому переформулируем определение проще: процесс изменения одного набора данных, называемого репликой, в ответ на изменения другого набора данных, называемого основным. Совсем не обязательно наборы при этом будут одинаковыми.

Поддержка репликации баз данных – одна из важнейших задач администратора: почти у каждой сколько-нибудь важной базы данных есть реплика, а то и не одна.

Среди задач, решаемых репликацией, можно назвать как минимум

Блочная репликация

При блочной репликации каждая операция записи выполняется не только на основном диске, но и на резервном. Таким образом тому на одном массиве соответствует зеркальный том на другом массиве, с точностью до байта повторяющий основной том:

К достоинствам такой репликации можно отнести простоту настройки и надёжность. Записывать данные на удалённый диск может либо дисковый массив, либо нечто (устройство или программное обеспечение), стоящее между хостом и диском.

Дисковые массивы могут быть дополнены опциями, позволяющими включить репликацию. Название опции зависит от производителя массива:

Если дисковый массив не способен реплицировать данные, между хостом и массивом может быть установлен агент, осуществляющей запись на два массива сразу. Агент может быть как отдельным устройством (EMC VPLEX), так и программным компонентом (HPE PeerPersistence, Windows Server Storage Replica, DRBD). В отличие от дискового массива, который может работать только с таким же массивом или, как минимум, с массивом того же производителя, агент может работать с совершенно разными дисковыми устройствами.

Главное назначение блочной репликации – обеспечение отказоустойчивости. Если база данных потеряна, то можно перезапустить её с использованием зеркального тома.

Блочная репликация хороша своей универсальностью, но за универсальность приходится платить.

Во-первых, никакой сервер не может работать с зеркальным томом, поскольку его операционная система не может управлять записью на него; с точки зрения наблюдателя данные на зеркальном томе появляются сами собой. В случае аварии (отказ основного сервера или всего ЦОДа, где находится основной сервер) следует остановить репликацию, размонтировать основной том и смонтировать зеркальный том. Как только появится возможность, следует перезапустить репликацию в обратном направлении.

В случае использования агента все эти действия выполнит агент, что упрощает настройку, но не уменьшает время переключения.

Во-вторых, сама СУБД на резервном сервере может быть запущена только после монтирования диска. В некоторых операционных системах, например, в Solaris, память под кеш при выделении размечается, и время разметки пропорционально объёму выделяемой памяти, то есть старт экземпляра будет отнюдь не мгновенным. Плюс ко всему кеш после рестарта будет пуст.

В-третьих, после запуска на резервном сервере СУБД обнаружит, что данные на диске неконсистентны, и нужно потратить значительное время на восстановление с применением журналов повторного выполнения: сначала повторить те транзакции, результаты которых сохранились в журнале, но не успели сохраниться в файлы данных, а потом откатить транзакции, которые к моменту сбоя не успели завершиться.

Блочная репликация не может использоваться для распределения нагрузки, а для обновления хранилища данных используется похожая схема, когда зеркальный том находится в том же массиве, что и основной. У EMC и HP эта схема называется BCV, только EMC расшифровывает аббревиатуру как Business Continuance Volume, а HP – как Business Copy Volume. У IBM на этот случай нет специальной торговой марки, эта схема так и называется – «mirrored volume».

В массиве создаются два тома, и операции записи синхронно выполняются на обоих (A). В определённое время зеркало разрывается (B), то есть тома становятся независимыми. Зеркальный том монтируется к серверу, выделенному для обновления хранилища, и на этом сервере поднимается экземпляр базы данных. Экземпляр будет подниматься так же долго, как и при восстановлении с помощью блочной репликации, но это время может быть существенно уменьшено за счёт разрыва зеркала в период минимальной нагрузки. Дело в том, что разрыв зеркала по своим последствиям эквивалентен аварийному завершению СУБД, а время восстановление при аварийном завершении существенно зависит от количества активных транзакций в момент аварии. База данных, предназначенная для выгрузки, доступна как на чтение, так и на запись. Идентификаторы всех блоков, изменённых после разрыва зеркала как на основном, так и на зеркальном томе, сохраняются в специальной области Block Change Tracking – BCT.

После окончания выгрузки зеркальный том размонтируется (С), зеркало восстанавливается, и через некоторое время зеркальный том вновь догоняет основной и становится его копией.

Физическая репликация

Журналы (redo log или write-ahead log) содержат все изменения, которые вносятся в файлы базы данных. Идея физической репликации состоит в том, что изменения из журналов повторно выполняются в другой базе (реплике), и таким образом данные в реплике повторяют данные в основной базе байт-в-байт.

Возможность использовать журналы базы данных для обновления реплики появилась в релизе Oracle 7.3, который вышел в 1996 году, а уже в релизе Oracle 8i доставка журналов с основной базы в реплику была автоматизирована и получила название DataGuard. Технология оказалась настолько востребованной, что сегодня механизм физической репликации есть практически во всех современных СУБД.

Опыт показывает, что если использовать сервер только для поддержания реплики в актуальном состоянии, то ему достаточно примерно 10% процессорной мощности сервера, на котором работает основная база.

Журналы СУБД не предназначены для использования вне этой платформы, их формат не документируется и может меняться без предупреждения. Отсюда совершенно естественное требование, что физическая репликация возможна только между экземплярами одной и той же версии одной той же СУБД. Отсюда же возможные ограничения на операционную систему и архитектуру процессора, которые тоже могут влиять на формат журнала.

Естественно, никаких ограничений на модели СХД физическая репликация не накладывает. Более того, файлы в базе-реплике могут располагаться совсем по-другому, чем на базе-источнике – надо лишь описать соответствие между томами, на которых лежат эти файлы.

Oracle DataGuard позволяет удалить часть файлов из базы-реплики – в этом случае изменения в журналах, относящиеся к этим файлам, будут проигнорированы.

Физическая репликация базы данных имеет множество преимуществ перед репликацией средствами СХД:

Запись данных в реплику невозможна, поскольку изменения в неё приходят побайтно, и реплика не может обеспечить конкурентное исполнение своих запросов. Oracle Active DataGuard в последних релизах разрешает запись в реплику, но это не более чем «сахар»: на самом деле изменения выполняются на основной базе, а клиент ждёт, пока они докатятся до реплики.

В случае повреждения файла в основной базе можно просто скопировать соответствующий файл с реплики (прежде, чем делать такое со своей базой, внимательно изучите руководство администратора!). Файл на реплике может быть не идентичен файлу в основной базе: дело в том, что когда файл расширяется, новые блоки в целях ускорения ничем не заполняются, и их содержимое случайно. База может использовать не всё пространство блока (например, в блоке может оставаться свободное место), но содержимое использованного пространства совпадает с точностью до байта.

Физическая репликация может быть как синхронной, так и асинхронной. При асинхронной репликации всегда есть некий набор транзакций, которые завершены на основной базе, но ещё не дошли до резервной, и в случае перехода на резервную базу при сбое основной эти транзакции будут потеряны. При синхронной репликации завершение операции commit означает, что все журнальные записи, относящиеся к данной транзакции, переданы на реплику. Важно понимать, что получение репликой журнала не означает применения изменений к данным. При потере основной базы транзакции не будут потеряны, но если приложение пишет данные в основную базу и считывает их из реплики, то у него есть шанс получить старую версию этих данных.

В PostgreSQL есть возможность сконфигурировать репликацию так, чтобы commit завершался только после применения изменений к данным реплики (опция synchronous_commit = remote_apply ), а в Oracle можно сконфигурировать всю реплику или отдельные сессии, чтобы запросы выполнялись только если реплика не отстаёт от основной базы ( STANDBY_MAX_DATA_DELAY=0 ). Однако всё же лучше проектировать приложение так, чтобы запись в основную базу и чтение из реплик выполнялись в разных модулях.

При поиске ответа на вопрос, какой режим выбрать, синхронный или асинхронный, нам на помощь приходят маркетологи Oracle. DataGuard предусматривает три режима, каждый из которых максимизирует один из параметров – сохранность данных, производительность, доступность – за счёт остальных:

Во-первых, в случае репликации средствами дискового массива трафик идёт не по сети передачи данных (LAN), а по сети хранения данных (Storage Area Network). Зачастую в инфраструктурах, построенных давно, SAN гораздо надёжнее и производительнее, чем сеть передачи данных.

Во-вторых, синхронная репликация средствами СУБД стала надёжной относительно недавно. В Oracle прорыв произошёл в релизе 11g, который вышел в 2007 году, а в других СУБД синхронная репликация появилась ещё позже. Конечно, 10 лет по меркам сферы информационных технологий – срок не такой уж маленький, но когда речь идёт о сохранности данных, некоторые администраторы до сих пор руководствуются принципом «как бы чего не вышло»…

Логическая репликация

Все изменения в базе данных происходят в результате вызовов её API – например, в результате выполнения SQL-запросов. Очень заманчивой кажется идея выполнять одну и ту же последовательность запросов на двух разных базах. Для репликации необходимо придерживаться двух правил:

Во-первых, не все API детерминированы. Например, если в SQL-запросе встречается функция now() или sysdate(), возвращающая текущее время, то на разных серверах она вернёт разный результат – из-за того, что запросы выполняются не одновременно. Кроме того, к различиям могут привести разные состояния триггеров и хранимых функций, разные национальные настройки, влияющие на порядок сортировки, и многое другое.

Во-вторых, репликацию, основанную на параллельном исполнении команд, невозможно корректно приостановить и перезапустить.

Если репликация остановлена в момент T1 транзакция B должна быть прервана и откачена. При перезапуске репликации исполнение транзакции B может привести реплику к состоянию, отличному от состояния базы-источника: на источнике транзакция B началась до того, как закончилась транзакция A, а значит, она не видела изменений, сделанных транзакцией A.
Репликация запросов может быть остановлена и перезапущена только в момент T2, когда в базе нет ни одной активной транзакции. Разумеется, на сколько-нибудь нагруженной промышленной базе таких моментов не бывает.

Обычно для логической репликации используют детерминированные запросы. Детерминированность запроса обеспечивается двумя свойствами:

Предположим, что у нас есть таблица сотрудников со следующими данными:

Над этой таблицей была выполнена следующая операция:

Для того, чтобы корректно реплицировать данные, в реплике будут выполнены такие запросы:

Запросы приводят к тому же результату, что и на исходной базе, но при этом не эквивалентны выполненным запросам.

База-реплика открыта и доступна не только на чтение, но и на запись. Это позволяет использовать реплику для выполнения части запросов, в том числе для построения отчётов, требующих создания дополнительных таблиц или индексов.

Важно понимать, что логическая реплика будет эквивалентна исходной базе только в том случае, если в неё не вносится никаких дополнительных изменений. Например, если в примере выше в реплике добавить в 36 отдел Сидорова, то он повышения не получит, а если Иванова перевести из 36 отдела, то он получит повышение, несмотря ни на что.

Логическая репликация предоставляет ряд возможностей, отсутствующих в других видах репликации:

Есть несколько способов реализации логической репликации, и каждый из этих способов реализует одну часть возможностей и не реализует другую:

Репликация триггерами

Триггер – хранимая процедура, которая исполняется автоматически при каком-либо действии по модификации данных. Триггеру, который вызывается при изменении каждой записи, доступны ключ этой записи, а также старые и новые значения полей. При необходимости триггер может сохранять новые значения строк в специальную таблицу, откуда специальный процесс на стороне реплики будет их вычитывать. Объём кода в триггерах велик, поэтому существуют специальное программное обеспечение, генерирующее такие триггеры, например, «Репликация слиянием» (merge replication) – компонент Microsoft SQL Server или Slony-I – отдельный продукт для репликации PostgreSQL.

Сильные стороны репликации триггерами:

Использование журналов СУБД

Сами СУБД также могут предоставлять возможности логической репликации. Источником данных, как и для физической репликации, являются журналы. К информации о побайтовом изменении добавляется также информация об изменённых полях (supplemental logging в Oracle, wal_level = logical в PostgreSQL), а также значение уникального ключа, даже если он не меняется. В результате объём журналов БД увеличивается – по разным оценкам от 10 до 15%.

Возможности репликации зависят от реализации в конкретной СУБД – если в Oracle можно построить logical standby, то в PostgreSQL или Microsoft SQL Server встроенными средствами платформы можно развернуть сложную систему взаимных подписок и публикаций. Кроме того, СУБД предоставляет встроенные средства мониторинга и управления репликацией.

К недостаткам данного подхода можно отнести увеличение объёма журналов и возможное увеличение трафика между узлами.

Использование CDC

Существует целый класс программного обеспечения, предназначенного для организации логической репликации. Это ПО называется CDC, change data capture. Вот список наиболее известных платформ этого класса:

Прикладная репликация

Наконец, ещё один способ репликации – формирование векторов изменений непосредственно на стороне клиента. Клиент должен формировать детерминированные запросы, затрагивающие единственную запись. Добиться этого можно, используя специальную библиотеку работы с базой данных, например, Borland Database Engine (BDE) или Hibernate ORM.

Когда приложение завершает транзакцию, подключаемый модуль Hibernate ORM записывает вектор изменений в очередь и выполняет транзакцию в базе данных. Специальный процесс-репликатор вычитывает векторы из очереди и выполняет транзакции в базе-реплике.
Этот механизм хорош для обновления отчётных систем. Может он использоваться и для обеспечения отказоустойчивости, но в этом случае в приложении должен быть реализован контроль состояния репликации.

Традиционно – сильные и слабые стороны данного подхода:

Так что же лучше?

Однозначного ответа на этот вопрос, как и на многие другие, не существует. Но надеюсь, что таблица ниже поможет сделать правильный выбор для каждой конкретной задачи:

Источник

РЕПЛИКАЦИЯ

Полезное

Смотреть что такое «РЕПЛИКАЦИЯ» в других словарях:

РЕПЛИКАЦИЯ — (от позднелат. replicatio повторение) (ауторепродукция аутосинтез, редупликация), удвоение молекул ДНК (у некоторых вирусов РНК) при участии специальных ферментов. Репликацией называется также удвоение хромосом, в основе которого лежит репликация … Большой Энциклопедический словарь

репликация — синтез, аутосинтез, повторение, ауторепродукция, редупликация, удвоение Словарь русских синонимов. репликация сущ., кол во синонимов: 8 • ауторепликация (1) • … Словарь синонимов

Репликация — Повторение конкретного открытия в области психологии в других ситуациях и с участием других людей. Мы склонны больше доверять экспериментальным открытиям, если они подтверждаются другими исследоватешями. Репликация того или иного открытия другим… … Большая психологическая энциклопедия

РЕПЛИКАЦИЯ — (от позднелатинского replicatio повторение) (редупликация), удвоение молекул ДНК (у некоторых вирусов РНК) при участии ферментов. Обеспечивает точное копирование генетической информации, заключенной в молекулах ДНК, и передачу ее от поколения к… … Современная энциклопедия

Репликация — (редупликация) процесс образования новых молекул НК, осуществляемый полимеразами (см. Полимеразы вирусные). Матрицами для репликации НК служат однонитчатые молекулы НК с позитивной полярностью. (Источник: «Словарь терминов микробиологии») … Словарь микробиологии

репликация — репликация. См. ауторепродукция. (Источник: «Англо русский толковый словарь генетических терминов». Арефьев В.А., Лисовенко Л.А., Москва: Изд во ВНИРО, 1995 г.) … Молекулярная биология и генетика. Толковый словарь.

репликация — Процесс создания идентичной копии (ДНК) [http://www.dunwoodypress.com/148/PDF/Biotech Eng Rus.pdf] Тематики биотехнологии EN replication … Справочник технического переводчика

Репликация — (от лат. replicatio, возобновление, повторение) : В Викисловаре есть статья «репликация» … Википедия

репликация — (от позднелат. replicatio повторение) (ауторепродукция, аутосинтез, редупликация), удвоение молекул ДНК (у некоторых вирусов РНК) при участии специальных ферментов. Репликацией называют также удвоение хромосом, в основе которого лежит репликация … Энциклопедический словарь

репликация — (лат. replicare обращать назад, отражать) биол. ауторепродукция создание себе подобной структуры; в молекулярной генетике синтез на каждой из нитей молекулы дезоксирибонуклеиновой кислоты (ДНК, иногда РНК) парной ей нити; р. лежит в основе… … Словарь иностранных слов русского языка

Источник

Реплицируемый объект. Часть 1: Введение

Предисловие. Данная публикация является авторским переводом собственной статьи. Поэтому если вы найдёте ошибку в переводе, то вполне может оказаться, что ошибка, на самом деле, в оригинальной статье.

Аннотация

Настоящая статья содержит описание раннего прототипа, который вводит понятие реплицируемого объекта (replicated object) или сокращённо replob. Такой объект является дальнейшим переосмыслением борьбы со сложностью кода, возникающего при программировании распределённых систем. Replob устраняет зависимость от стороннего сервиса и реализует согласованное изменение любых пользовательских объектов, представляющих соответствующие данные и функциональность. Эта идея основана на использовании выразительности языка C++ и объектно-ориентированного подхода, что позволяет использовать сложную логику внутри распределённых транзакций. Это позволяет значительно упростить разработку отказоустойчивых приложений и сервисов. Последующие статьи будут более детально объяснять развиваемый подход.

Введение

ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки памяти и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

На текущий момент, тематика, связанная с распределёнными системами, является одной из самых интересных, и привлекают большое количество людей, включая разработчиков и учёных. Популярность объясняется просто: мы должны создавать надежные отказоустойчивые системы, которые обеспечивают безопасную среду для выполнения различных операций и для хранения данных.

Вместе с тем, сохранение консистентности распределённой системы играет важную роль. Обеспечение консистентности высокого уровня даётся немалой ценой. Сегодня существует ряд решений, которые обеспечивают самую слабую форму консистентности: так называемую консистентность в конечном счёте (eventual consistency). С одной стороны, такие решения имеют относительно неплохую производительность, но с другой стороны они не могут быть использованы во многих областях, где необходимо иметь транзакционную семантику операций. Дело в том, что намного проще размышлять о системе, используя одну из сильных уровней консистентности наподобие строгой консистентности или линеаризуемости. Такие уровни консистентности позволяют гораздо легче разработать надежное приложение с безопасной семантикой исполнения последовательности операций.

Обзор

Как показывает жизнь, счастье в меньшей степени зависит от внешних вещей, чем полагает большинство.

Для разработки распределённой системы наиболее часто используют специализированные сервисы. Эти сервисы должны предоставлять собой удобный способ борьбы со сложностью, связанной с асинхронной природой распределённых задач и с различными видами отказов, включая сетевые проблемы, падение приложений и аппаратные сбои. В распределённой среде эти проблемы не должны рассматриваться как что-то из ряда вон выходящее, а должны быть обработаны как вещи вполне обычные и заурядные. Таким образом, на сцене появляется задача создания надежного и консистентного сервиса для решения вопросов, возникающих в распределённых системах.

Современные системы используют отказоустойчивые сервисы, такие как Zookeeper (в основном) или etcd (в стадии активной разработки). Они используют алгоритмы распределённого консенсуса: Zab (Zookeeper) или Raft (etcd), чтобы обеспечить линеаризуемость операций. Идея здесь заключается в следующем. На первом шаге избирается лидер, затем назначенный лидер (мастер) фиксирует сообщения в определенной последовательности, что обеспечивает необходимый уровень консистентности. Несмотря на то, что документация Zookeeper утверждает, что Zookeeper реализует подход с использованием первичной резервной копии, а не репликации конечного автомата, очевидно, что единственная разница между этими подходами состоит в том, что первичная резервная копия основана на очередности, задаваемой репликами, а репликация конечного автомата основана на последовательности, задаваемой клиентом. Я думаю, что тут важно то, что оба подхода договариваются о последовательности детерминированных операций с использованием разработанных алгоритмов консенсуса на основе мастера.

Обсуждение существующих подходов

Следует всегда помнить, что мы не можем управлять событиями, а должны прилаживаться к ним.

Транзакционная семантика и нетривиальные сценарии

Логика – это искусство ошибаться с уверенностью в своей правоте.

Пессимистическая блокировка

В связи с этим на сцене появляется иной способ решения задачи.

Оптимистическая блокировка

Концепция реплицируемого объекта

К сложному надо подходить просто, иначе мы никогда его не поймём.

Давайте сделаем шаг назад и вспомним про объектно-ориентированное программирование (ООП). Здесь у нас есть понятие объектов. Каждому такому объекту принадлежат определенные данные, представляющие состояние объекта. При этом объект содержит набор методов, которые преобразует объект из одного состояния в другое.

Таким образом, идея заключается в реплицировании действий (методов объекта) между нодами кластера вместо репликации самих данных (состояния объекта). Эти действия детерминировано изменяют состояние объекта и создают иллюзию того, что реплицируется сам объект. При этом линеаризумость гарантирует, что все реплики принимают одну и ту же последовательность действий, таким образом получая консистентное состояние рассматриваемого распределённого объекта. Это очень похоже на модель репликации конечного автомата. Разница состоит лишь в том, что я использую обычный объект для представления состояния и методы для представления событий, трансформирующих объект. Такое отображение значительно снижает сложность разработки и позволяет использовать мощь языка C++, поскольку он изначально поддерживает использование ООП без раздувания кода.

Свойства реплицируемого объекта

При многословии не миновать греха, а сдерживающий уста свои разумен.

Встроенный. Это не отдельно стоящий сервис. Функциональность работает внутри пользовательского процесса, что сокращает задержку операций за счет уменьшения количества сетевых сообщений между репликами. Такой подход полностью избавляет от внешней зависимости от сервисов наподобие Zookeeper или etcd и использует нативные интерфейсы, что серьезно упрощает взаимодействие с логикой репликации, делая её полностью прозрачной для пользователя.

Без мастера. Алгоритм не имеет выделенного мастера (лидера). Таким образом, каждый узел неотличим друг от друга. Это значительно снижает задержки при восстановлении после сбоев, а также создает более предсказуемое поведение в большинстве случаев.

Хранение в памяти. Текущая реализация не имеет персистентный слой, и каждый элемент распределяется по репликам внутри памяти процессов. Алгоритм, тем не менее, позволяет добавить свойство персистентности для объектов.

Линеаризуемая консистентность. Алгоритм реплицируемых объектов предоставляет гарантию линеаризуемости операций.

FIFO гарантия для процесса. Для указанного процесса все операции будут завершены в порядке их планирования этим процессом (FIFO-порядок).

Быстрые локальные чтения. Специальный режим позволяет читать данные локально путем снижения уровня консистентности до последовательного консистентности. Это значительно снижает задержки и общую нагрузку на систему.

Конкурентные гибкие распределённые транзакции. Внутри транзакций можно использовать детерминированную последовательность операций любой степени сложности. Такие транзакции обрабатываются конкурентным образом.

Поддержка опции независимых параллельных транзакций. Пользователь может иметь несколько экземпляров реализации консенсуса для распараллеливания независимых транзакций.

Можно настраивать САР. Пользователь может выбирать между линеаризуемостью и доступностью в случаях нарушения сетевой связности.

Плавная деградации набора реплик. Система сохраняет консистентность даже в условиях, когда число реплик уменьшается значительно. Например, количество реплик может уменьшиться от пяти до двух, а в некоторых ситуациях сократиться даже до одной реплики.

Безопасность и живучесть при различных сетевых проблемах. Существует немалое количество различных сетевых проблем (см. Aphyr: The network is reliable). При этом алгоритм сохраняет консистентность и работоспособность в указанных случаях.

Все эти пункты будут подробно рассмотрены в последующих статьях.

Примеры

Непобедимым быть можешь, если не вступишь ни в какой бой, в котором победа от тебя не зависит.

Чтобы продемонстрировать всю гибкость и мощь подхода я рассмотрю достаточно простой пример.

Пример: хранилище типа ключ-значение

Давайте реализуем реплицируемое хранилище со следующим интерфейсом (я опускаю пространства имен std:: и boost:: для краткости):

Для простоты я выбрал симметричный интерфейс. set метод удаляет соответствующий ключ, если было передано пустое значение. При использовании обычного объекта соответствующие реализации могут быть следующие:

Теперь я хотел бы преобразовать наш обычный объект в реплицируемый объект. Для этого я просто добавлю:

Подсказка: реализация DECL_REPLOB такова:

И тогда я могу использовать следующую строку кода для репликации моих данных по набору реплик:

Чтобы прочитать данные с линеаризуемым уровнем консистентности, следует написать:

Но чтобы улучшить производительность для этой операции чтения я просто пишу:

Транзакции

Давайте предположим, что я хочу изменить значение по указанному ключу. Наивный способ заключается в написании такого кода:

Проблема тут только в том, что последовательные две атомарные операции не дают суммарную атомарную операцию (так называемое, состояние гонки второго рода). Таким образом, нам необходимо поместить все наши действия внутрь транзакции:

Тогда все указанные действия будут применяться на всех репликах атомарно.

Транзакции с результатами

Рассмотрим следующую задачу: необходимо вычислить размер значения для указанного ключа. Нет ничего проще:

Такой же подход можно использовать операции изменения объекта:

Все указанные операции применяются на репликах атомарно.

Транзакции с несколькими replob

Следует ли мне упомянуть то, что все эти действия выполняются атомарно, при этом первая транзакция является распределённой и выполняется на всех репликах?

Продвинутый пример

Давайте рассмотрим итерацию по коллекции с использование функции, определяемой пользователем:

Теперь задача состоит в том, чтобы вернуть общий размер строк для всех значений:

Как вы можете видеть, всё реализуется достаточно прямолинейно.

Дальнейшие направления

Если вы заранее знаете, к чему вы хотите прийти, то шаги в этом направлении – это совсем не эксперимент.

Выводы

Зрелость – это переход от опоры на окружающих к опоре на самого себя.

Мы рассмотрели введение во встроенный отказоустойчивый распределённый реплицируемый объект, который обладает множеством необычных свойств. Эти свойства позволяют существенно снизить сложность создания надежного распределённого приложения, и открывает новые горизонты для применения такого объекта в широком диапазоне возникающих задач.

Алгоритм достижения консенсуса без мастера позволяет обрабатывать различные ситуации отказа предсказуемым образом без существенной потери времени. Встроенный подход исключает сетевые задержки при чтении данных. В то же время, модель сильной консистентности обеспечивает удобный способ взаимодействия с реплицируемым объектом, а также позволяет использовать его максимально гибко внутри распределённых транзакций.

Хочу выразить отдельное спасибо Sergey Polovko, Yauheni Akhotnikau и Petr Prokhorenkov за полезные комментарии и советы.

Вопросы для самопроверки

Единственная сложность состоит в том, чтобы задать правильный вопрос.

Источник