Лучше подписаться на изменения или полный набор данных?

Question

Допустим, у меня есть две службы A и B.Служба A имеет набор элементов, таких как [ "foo", "bar" ], и является службой, ответственной за доставку элементов в систему.Служба B должна подписаться на этот набор данных.Это можно сделать двумя способами:

1. Подписаться на полный набор данных
2. Подписаться на изменения

Чтобы привести конкретный пример, давайтескажем, набор данных проходит через эволюцию, как

• [ "foo", "bar" ]
• [ "foo", "bar", "baz" ]
• [ "foo", "baz" ]
• [ "foo", "baz", "buz" ]

Сообщения, отправляемые в службу B с каждым изменением, могут быть точно такими же, как указано выше, или могут выглядеть как

• { add: [ "foo", "bar" ], subtract: [] }
• { add: [ "baz" ], subtract: [] }
• { add: [], subtract: [ "bar" ] }
• { add: [ "buz" ], subtract: [] }

Вопрос в том, что будет лучше.Я считаю, что первое лучше по следующим причинам

• Последовательная согласованность. Во-первых, если сообщение потеряно или есть какой-то другой сбой, так что B нене обрабатывать сообщение, оно всегда будет исправлено, если оно успешно обработает другое сообщение.Во-вторых, в систему будет добавлено много сложностей для автоматического исправления этих сценариев сбоя.
• Idemptoency. Аналогично приведенному выше пункту, если служба A отправляетдублировать сообщения случайно, что в первом дизайне совершенно нормально, тогда как в случае второго варианта этот случай потребует дополнительной сложности.
• Дельта на самом деле не является оптимизацией. Изначально это звучит какоптимизация, чтобы сказать: «Остальная часть нашей системы будет только обрабатывать изменения», но дело в том, что кто-то должен вычислить изменения, так почему бы A вместо B, и какэто уменьшит общее количество операций?

Answer 1

Сначала обратите внимание, что если вы работаете с set , такие операции, как «сложение» и «вычитание» являются идемпотентными, если вы не меняете порядок (на самом деле это полезное свойство вхотя бы в некоторых случаях, так как в некоторых сценариях ваш «сервер» может отправить второе сообщение с тем же действием, не испортив данные клиента).

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

В-третьих, лучше использовать дифференцированный подход, когда размер целых данных намного больше, чем размер обновленных данных (скажем, 10 ^6 предметов, в то время как вы меняете два или три одновременно).При отображении данных вам обычно требуется дельта (так что, скажем, в пользовательском интерфейсе вы удаляете две строки из списка, а не стираете весь список, а затем создаете его снова);вычисление его из двух больших блоков данных может занять время.Кроме того, попытка оперировать целыми наборами данных также становится проблематичной, когда они больше не помещаются в памяти (а повторная отправка клиентских мега- или даже гигабайт данных при каждом действии оказывается менее чем целесообразной).

Answer 2

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

Но я бы хотел, чтобы вы посмотрели с точки зрения продюсеров.Продюсер должен работать над определенными событиями, скажем, добавить и саб.Когда генерируются события, все, что у него есть, это «Баз».Он обработает операцию, а затем запросит свою систему, чтобы проверить все данные и отправить их.Однако он мог просто отправить вас

{add: ["baz"], вычесть: []}

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

Другая сторона этой истории, почему подписчикнужно это, ему может понадобиться, чтобы увидеть, если он может показать продукт.Если это так, то он не очень обеспокоен, если инвентарь 10, 11 или 9. Он беспокоится о том, приближается ли он к нулю или нет, в этом случае могут иметь смысл дельта-обновления.

Но только дельта-обновления могут не помочьвы.Как вы сказали, они не идемпотентны и не последовательны.И чтобы это исправить, я предпочитаю использовать оба.

Отправлять дельта-обновления с меньшими интервалами.Пусть система выйдет из строя, но исправьте ее, прежде чем она станет слишком плохой, нажав полные наборы данных.

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

Так одно лучше другого?Я скажу, это зависит от вашего варианта использования, вы можете предпочесть один из них другому, или они оба могут использоваться для дополнения друг друга.