Вы неправильно поняли, как работают Subscription
и add
.
Когда вы subscribe
к чему-то, вы получаете объект Subscription
, к которому вы можете обратиться unsubscribe()
. Это отлично. Тем не менее, вы не присвоили значение правильно. Вы присвоили Subscription
- const sub
, которые затем передаете как блок completion
на add
.
Рассмотрим Subscription.add
как блок finally
из try/catch
. Независимо от результата Subscription
, когда он равен complete
, блок, переданный в add
, будет выполняться. Используйте это для любых задач очистки.
subscriptions: Subscriptions[] = [];
ngOnDestroy() {
subscriptions.forEach((sub) => sub.unsubscribe());
}
deleteFile(id: any) {
const sub = this.fileCabinetService.deleteFile(id).subscribe(...);
this.subscriptions.push(sub);
sub.add(() => this.subscriptions.remove(sub));
}
Чтобы ответить на ваш вопрос о том, когда unsubscribe
, это действительно зависит от того, что deleteFile
делает. Если метод deleteFile
внутренне сигнализирует со значением (или набором значений) и затем завершается, подписка прекращается автоматически. Если оно не будет завершено и оставлено висящим, ваша подписка будет сохраняться.
Рассмотрим сценарий:
WallClock.subscribe((time) => console.log(time));
Этот Subscription
никогда не будет прекращен, потому что время (предположительно) будет продолжаться бесконечно. Вместо этого вы захотите вручную контролировать, когда это будет прекращено. Вы можете сделать это несколькими способами:
/* Get the current time, but don't bother listening to updates. */
WallClock.pipe(take(1)).subscribe((time) => console.log(time));
/* Continually update with the current time as long as the component is on screen
— Requires setting `this.staySubscribed = false` when you're leaving */
WallClock.pipe(takeWhile(() => this.staySubscribed)).subscribe((time) => console.log(time));
/* Continually update until you remember to unsubscribe
— Requires remembering to unsubscribe and can get verbose with multiple subscriptions
- Call `this.subscription.unsubscribe()` later */
this.subscription = WallClock.subscribe((time) => console.log(time));
Если ваш deleteFile
работает так и непрерывно сообщает значения без определенного условия завершения, вы должны каким-то образом прекратить подписку. Вероятно, это случай (основанный на названии функции), что это самоограничение Subscription
, которое не требует ничего с вашей стороны. Если вы хотите быть в безопасности, pipe(take(1))
обеспечит это для вас.
AMQP не является структурой RPC. Он предоставляет строительные блоки для моделирования таких вещей, как общие очереди, RPC, pubsub и т. Д., Но не требует какого-либо конкретного способа его использования.
Если вы хотите разделить свое приложение (сделав его доступным для распространения) и связать его с AMQP, я думаю, что это правильная технология. Хотя могут быть более быстрые альтернативы, но, вероятно, нет такой универсальной, как AMQP.
AMQP является спецификацией, таким образом, Вы сравнили бы яблоки с апельсинами действительно. Нет то, что многие производство готовые поставщики AMQP там действительно; ни один из главных поставщиков сообщений или поставщиков не поддерживает AMQP во время записи (например, IBM, Tibco, Звуковой, BEA, Oracle, SwiftMQ, Миссисипи, Apache ActiveMQ, openmq от Sun) - таким образом, все доступные поставщики AMQP являются довольно новыми.
Таким образом, я рекомендовал бы выдержать сравнение безотносительно поставщика AMQP Вы интересуетесь с Вашей платформой передачи сообщений. Нет никакого смысла разрывающего что-то, которое хорошо работает только из-за способа, которым это читает и пишет байты в сокет :)
AMQP больше походит на предложение промежуточного программного обеспечения надежной передачи для SOA, чем что-то использоваться внутренне.
В качестве основы для надежной, чрезвычайно гибкой (с точки зрения шаблонов обмена сообщениями) он может использоваться для многих сценариев обмена сообщениями, как внутримашинных (т. Е. Между процессами), так и межсетевых. Он может масштабироваться от нуля до огромных многосетевых систем с высокой пропускной способностью.
В настоящее время я оцениваю его для небольшой, но относительно сложной системы, работающей почти в реальном времени, где нам все равно, насколько далеко сообщения путешествия или кто / что (в пределах разумного;) их потребляет. Если потребитель сидит на одной машине, пусть будет так. Я бы попробовал и посмотрел, что вы об этом думаете. Если вы хотите собрать воедино прототип системы, используйте python и библиотеку Pika .
Если вас в первую очередь интересует производительность во внутримашинном сценарии, вопрос меньше об AMQP ( который является протоколом только на уровне проводов), чем о том, какую реализацию вы должны попробовать.
Убрав задержку, вносимую сетью, вы, вероятно, будете намного более чувствительны к исходным характеристикам различных реализаций. Поэтому я бы посмотрел на продукты, реализованные на C ++, такие как Qpid или Zeromq.
Qpid может легко достигать 400 000 сообщений в секунду (с сообщениями размером 1024 байта) на некотором приличном оборудовании (четырехъядерном). Zeromq, вероятно, будет работать намного лучше, потому что у вас могут быть одноранговые каналы, тогда как Qpid использует архитектуру брокера (в которой был шаг).
Стандарт AMQP становится зрелым и решает некоторые сложные проблемы, которые преследовали другие стандарты обмена сообщениями, такие как JMS. На ваш вопрос, стоит ли заменять существующее решение, я бы сказал, зависит от обстоятельств. Я был бы очень скептически настроен, поскольку, по-видимому, система уже работает, находится в производстве и имеет высокую производительность.
Если у вас есть такие проблемы, как:
Вам следует изучить объем требуемой работы и более точно проанализировать преимущества. Если вы уже довольны, замена фреймворка обмена сообщениями не окупится.