Как сделать идемпотент операции записи?

Я читаю статью о недавно выпущенном Животе sharding платформа Твиттером (http://engineering.twitter.com/2010/04/introducing-gizzard-framework-for.html). Это упоминает, что все операции записи должны быть идемпотентом для обеспечения высокой надежности.

Согласно Википедии, "Идемпотентные операции являются операциями, которые могут быть применены многократно, не изменяя результат". Но, по моему скромному мнению, в случае Живота, идемпотентные операции записи должны быть, в которых не имеет значения последовательность.

Теперь, мой вопрос: Как сделать, я делаю идемпотент операций записи?

Единственной вещи, которую я могу вообразить, состоял в том, чтобы присоединить номер версии к каждой записи. Например, в системе блога, каждый блог должен иметь $blog_id и $content. На прикладном уровне мы всегда пишем содержание блога как эта запись ($blog_id, $content, $version). $version полон решимости быть уникальным на прикладном уровне. Так, если приложение сначала пытается установить один блог на "Привет мировой" и второй want's это, чтобы быть "До свидания", затем запишите, идемпотент. У нас есть такие две операции записи:

write($blog_id, "Hello world", 1);
write($blog_id, "Goodbye", 2);

Эти две операции предполагаются к измененным двум различным записям в DB. Так, неважно, сколько раз и что упорядочивает эти две операции, выполняются, результатами является то же.

Это - просто мое понимание. Исправьте меня, если я неправ.

8
задан Matthew Murdoch 17 November 2011 в 16:45
поделиться

2 ответа

Вы абсолютно правы. Сами по себе идемпотентные операции могут обеспечить только один шаблон разрешения конфликтов - «Побеждает последняя запись». Это возможное решение, если ваши записи не могут быть переупорядочены вовремя. Если они могут, вы должны предоставить дополнительную информацию, чтобы разрешение конфликтов было автоматическим. И ваша идея не нова. В общем случае они называются векторными часами .

Мы используем разрешение конфликтов на основе версий в одной из наших систем, которые собирают историю изменений объектов в нашей системе. Клиенты отправляют полную информацию о состоянии объекта и версии в модуль истории (асинхронно). Затем модуль истории может изменить порядок состояний объекта правильным образом и сохранить только дельту в постоянном хранилище. Единственное ограничение состоит в том, что клиент должен использовать какой-то вид управления параллелизмом при внесении изменений в объект ( оптимистическая блокировка - очень хороший метод, если вы отслеживаете версию состояния объекта).

6
ответ дан 5 December 2019 в 18:58
поделиться

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

Также см. Этот предыдущий вопрос о переполнении стека .

3
ответ дан 5 December 2019 в 18:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: