Конечная согласованность и обмен сообщениями

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

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

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

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

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


person skrat    schedule 23.08.2011    source источник


Ответы (1)


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

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

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

person dcro    schedule 03.11.2011
comment
Мы решили переключить хранилище BLOB-объектов на MongoDB, это обеспечивает высокую согласованность. - person skrat; 10.11.2011