Как обеспечить запись данных в два больших двоичных объекта Azure?

Я разрабатываю мультитенантное приложение Azure Service Fabric, в котором мы будем хранить данные о событиях в больших двоичных объектах Azure, предназначенных только для добавления.

Будет два вида капель; объединить большие двоичные объекты (по одному на каждого клиента); и экземпляры больших двоичных объектов (по одному на каждый "объект", принадлежащий арендатору - их будет более 100 тыс. на каждого арендатора)

Для каждого экземпляра большого двоичного объекта будет один писатель. Этот модуль записи отслеживает позицию последнего записанного большого двоичного объекта и тем самым может гарантировать (с помощью условной записи), что ни один другой модуль записи не записал в этот большой двоичный объект с момента последней успешной записи. Это важный аспект, который мы будем использовать для обеспечения строгой согласованности для каждого экземпляра.

Однако все записи в экземплярный большой двоичный объект должны также в конечном итоге (но как можно скорее) достигать единственного (для каждого клиента) слияния blob.

При нормальной работе я бы хотел, чтобы эти записи слиянием происходили в течение ~ 100 мс.

У меня вопрос о том, как лучше всего реализовать эту функцию гарантированной двойной записи:

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

Следует избегать следующих несоответствий:

  1. Данные успешно записываются в большой двоичный объект экземпляра, но никогда не записываются в соответствующий большой двоичный объект слияния.

  2. Данные записываются в большой двоичный объект слияния более одного раза.


azure-storage-blobs azure-storage azure-service-fabric distributed-computing algorithm
person Mårten Wikström    schedule 23.10.2016    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Самый простой способ, как для меня, - использовать события: служебную шину, концентраторы событий или любой другой поставщик, чтобы гарантировать, что событие будет сохранено и доступно хотя бы где-то. Плюс, это даст возможность записывать события в Blob Storage партиями. Кроме того, я думаю, что это значительно снизит нагрузку на Service Fabric и позволит обрабатывать события в желаемое время.
Таким образом, у вас может быть много служб без сохранения состояния или просто веб-воркеров, которые будут собирать новые сообщения из очереди и в пакетном режиме. отправьте их в службу Statefull.
Допустим, это будет служба слияния. Вам нужно будет разделить эти службы, и лучший способ отправить пакет событий, сгруппированных по одному разделу, - это сделать такую ​​службу без сохранения состояния или веб-воркер.

Тогда у вас может быть отдельный Statefull Actor для каждого объекта. Но на вашем месте я бы попробовал создать 100 тысяч актеров или любую другую реальную нагрузку и посмотреть, насколько это будет дорого. Если это слишком дорого, и вы не можете позволить себе такие машины, тогда все можно будет обработать в другой секционированной службе без сохранения состояния.

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

Как только субъект записывает свои данные в свое состояние, а служба делает то же самое, тогда такая седьмая в ESB может быть помечена как обработанная и удалена из очереди. Тогда вам просто нужно время от времени записывать сохраненные данные из службы слияния и субъектов в хранилище BLOB-объектов.

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

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

person cassandrad    schedule 23.10.2016

arrow_upward
0
arrow_downward

Для этого вы можете использовать Stateful Actor. Вам не нужно беспокоиться о параллелизме, потому что его нет. В состоянии Актера вы можете отслеживать, какие операции были успешно завершены. (напишите 1, напишите 2)

Тем не менее, написание «ровно один раз» в распределенной системе (без DTC) никогда не является 100% водонепроницаемым.

Дополнительная информация об этом:

person LoekD    schedule 24.10.2016