Название архитектуры pubsub с уведомлением и проверкой?

Основной вопрос по архитектуре pubsub. На высоком уровне при проектировании pubsub я иногда сталкиваюсь с выбором между двумя архитектурами:

  1. Опубликовать мутации или новое состояние.

Некоторое состояние БД изменяется, и издатели уведомляют об этом изменении через pubsub. Но они включают в сообщение достаточно информации, чтобы подписчику не нужно было искать в БД. Представьте, что у подписчика есть кеш БД. Он может получать мутации или новое состояние и обновлять свой кеш без поиска. Опубликовать мутации или новое состояние

  1. Уведомление и проверка. Издатели уведомляют только о появлении нового изменения, которое предлагает подписчику получить последнее из БД. Это более надежный ИМО. pubsub может не гарантировать порядок доставки, и эта архитектура устойчива к этому, в то время как #1 нет, если мутации чувствительны к порядку.

Уведомление и проверка

Мой вопрос: есть ли общее название для этих двух типов архитектур? Спасибо!


architecture design-patterns publish-subscribe distributed-system event-driven-design
person bhh1988    schedule 08.08.2020    source источник
comment
Я не согласен с тем, что № 2 более надежен: вам нужно воспроизвести все предыдущие события, чтобы добраться до конечного состояния, а не только последнее событие; к тому времени, когда получатель опрашивает, чтобы получить данные о событии, данные могут быть устаревшими. Не говорю, что № 1 лучше, просто говорю, что у каждого есть свои плюсы и минусы, и обычно один, если два будут лучше в вашей текущей ситуации, но не обязательно во всех ваших ситуациях.   -  person Oliver    schedule 10.08.2020

Ответы (1)


arrow_upward
0
arrow_downward

Публикация/подписка известна как шаблон Observer в книге Gang of Four Design Patterns. На странице 298 они описывают эти два варианта как модели push и pull.

Реализации шаблона Observer часто передают субъекту дополнительную информацию об изменении. Субъект передает эту информацию в качестве аргумента функции Update. Объем информации может сильно различаться.

В одном крайнем случае, который мы называем моделью push, субъект отправляет наблюдателям подробную информацию об изменении, хотят они этого или нет. Другой крайностью является модель вытягивания; субъект не отправляет ничего, кроме самого минимального уведомления, и после этого наблюдатели явно запрашивают подробности.

Модель вытягивания подчеркивает невежество субъекта о своих наблюдателях, тогда как модель выталкивания предполагает, что субъекты что-то знают о потребностях своих наблюдателей. Модель push может сделать наблюдателей менее пригодными для повторного использования, потому что классы Subject делают предположения о классах Observer, которые не всегда могут быть верными. С другой стороны, модель вытягивания может быть неэффективной, потому что классы Observer должны выяснить, что изменилось, без помощи субъекта.

person jaco0646    schedule 09.08.2020