Как сделать операцию записи идемпотентной? - PullRequest
8 голосов
/ 08 апреля 2010

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

Согласно википедии «Идемпотентные операции - это операции, которые могут применяться несколько раз без изменения результата». Но, IMHO, в случае с Gizzard идемпотентными операциями записи должны быть операции, последовательность которых не имеет значения.

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

Единственное, что я могу себе представить, это иметь номер версии, прикрепленный к каждой записи. Например, в системе блогов каждый блог должен иметь $ blog_id и $ content . На уровне приложения мы всегда пишем содержимое блога, например write ($ blog_id, $ content, $ version) . $ версия определена как уникальная на уровне приложения. Итак, если приложение сначала пытается установить для одного блога «Hello world», а второе хочет, чтобы оно было «до свидания», тогда write идемпотентно. У нас есть две такие операции записи:

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

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

Это только мое понимание. Пожалуйста, поправьте меня, если я ошибаюсь.

Ответы [ 2 ]

6 голосов
/ 22 апреля 2010

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

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

3 голосов
/ 08 апреля 2010

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

Кроме того, посмотрите этот предыдущий вопрос стекопотока .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...