Возможная последовательность и обмен сообщениями - PullRequest
1 голос
/ 23 августа 2011

Я сталкивался с этой проблемой, и до сих пор кажется, что единственным решением является более сильная модель согласованности. Сервис Amazon S3, который обеспечивает возможную согласованность. Мы используем его как хранилище BLOB-объектов.

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

  1. подсистема получает данные от пользователя
  2. данные сохраняются в S3
  3. сообщение отправлено
  4. сообщение получено другой подсистемой
  5. данные считываются с S3
  6. ... сверчки. Это старые данные? Иногда это так.

Итак. Мы постарались на очевидное, отправив данные в сообщение, чтобы избежать непоследовательного чтения из S3. Но это довольно неприятная вещь: сообщение становится излишне большим, и когда получатель слишком занят или выходит из строя и получает сообщение с опозданием, в то время как уже доступны новые данные, происходит сбой.

Есть ли решение для этого или нам действительно нужно сбросить S3 для более согласованного бэкэнда, такого как RDBMS или MongoDB?

1 Ответ

0 голосов
/ 03 ноября 2011

Если ваш сценарий позволяет всегда записывать ваши данные на S3 под новым ключом (всегда создавая новые объекты), то вы можете полагаться на согласованность операций чтения-после-записи Amazon.

Вот описание Amazon, которое описывает эту модель согласованности:

Корзины Amazon S3 на западе США (Северная Калифорния), ЕС (Ирландия), Азиатско-Тихоокеанском регионе (Сингапур) и АзииТихоокеанские (Токио) регионы обеспечивают согласованность чтения-после-записи для PUTS новых объектов и возможную согласованность для перезаписи PUTS и DELETES.Контейнеры Amazon S3 в стандартном регионе США обеспечивают возможную согласованность.

...