get_multi/set_multi атомарный?

В официальном FAQ Memcached я прочитал:

«Все отдельные команды, отправляемые в memcached, абсолютно атомарны».

Однако это все еще неясно для меня, когда дело доходит до get_multi и set_multi. Я хотел бы знать, являются ли get_multi и set_multi атомарными в следующем смысле:

  • Все записи, выполняемые set_multi, будут выполняться вместе атомарно.
  • Все чтения, выполняемые get_multi, будут выполняться вместе атомарно.

Например, эти ситуации должны быть невозможными:

1)

  • Изначально содержимое кеша {'a': 0, 'b': 0}
  • машина А вызывает set_multi({'a': 1, 'b': 1})
  • машина B вызывает get_multi(['a', 'b']) и получает {'a': 1, 'b': 0}

2)

  • Изначально содержимое кеша {'a': 0, 'b': 0}
  • машина A вызывает `set({'a': 1})
  • машина A вызывает `set({'b': 2})
  • машина B вызывает get_multi(['a', 'b']) и получает {'a': 0, 'b': 2}

Этот вопрос настолько важен для моего дизайна, что я подумал, что лучше попросить подтверждения.


person julx    schedule 17.09.2011    source источник


Ответы (1)


По мере того, как я читал этот раздел, get_multi выдает несколько запросов, которые выполняются параллельно, идея заключается в том, что для больших запросов get_multi позволяет сократить общее количество времени для получения всех результатов. Я не вижу никакой гарантии или упоминания о том, что независимые запросы, выполняемые вместе, коллективно атомарны. То же правило, вероятно, применяется к set_multi (т. е. отдельные запросы являются атомарными, а их совокупность — нет).

Там также, кажется, нет упоминания о транзакциях.

person jefflunt    schedule 17.09.2011
comment
Я думаю ты прав. Кажется, протокол даже не поддерживает это. Я ошибочно предположил, что библиотечные процедуры находятся в 1-1 соответствии с реальными операциями с кэшем. - person julx; 17.09.2011
comment
Правильный. get_multi — это оптимизация. В бинарном протоколе вы можете выполнить аналогичную оптимизацию, отправив несколько объектов вместе, но все они фактически являются отдельными запросами. - person Dustin; 19.09.2011