Здравствуйте, Tom, Вы писали:
_>>Messaging — это в меньшей степени про "корпоративный софт", а прежде всего про высоконагруженные сервисы (SOA и пр.). Tom>Перестаньте отвечать чушь людям и начните учиться. Вы путаете людей.
Отлично, с удовольствием начну. А теперь еще раз, по делу и без хамства: с чем конкретно Вы не согласны, уважаемый?
Здравствуйте, scale_tone, Вы писали:
_>Здравствуйте, Tom, Вы писали:
_>>>Messaging — это в меньшей степени про "корпоративный софт", а прежде всего про высоконагруженные сервисы (SOA и пр.). Tom>>Перестаньте отвечать чушь людям и начните учиться. Вы путаете людей.
_>Отлично, с удовольствием начну. А теперь еще раз, по делу и без хамства: с чем конкретно Вы не согласны, уважаемый?
С той фразой которую я процитировал. Серьёзный, корпоративный, НЕ высоко нагруженый софт без messaging-а просто жить не может.
Здравствуйте, Tom, Вы писали:
Tom>С той фразой которую я процитировал. Серьёзный, корпоративный, НЕ высоко нагруженый софт без messaging-а просто жить не может.
Понятно. "Сама придумала — сама обиделась".
В каком месте я сказал что-либо противоречащее Вашему прекрасному утверждению?
_>В каком месте я сказал что-либо противоречащее Вашему прекрасному утверждению? >>Messaging — это в меньшей степени про "корпоративный софт", а прежде всего про высоконагруженные сервисы (SOA и пр.).
Здравствуйте, Tom, Вы писали:
_>>В каком месте я сказал что-либо противоречащее Вашему прекрасному утверждению? >>>Messaging — это в меньшей степени про "корпоративный софт", а прежде всего про высоконагруженные сервисы (SOA и пр.).
Еще раз: если бы весь "серьезный корпоративный софт" изначально строился на принципах messaging-а (читай: если б MSMQ с момента своего создания сразу же побил бы по популярности какой-нибудь DCOM) — это было б счастье. К сожалению, дело было не так, и Message Broker-ы получили массовое распространение только с появлением интернет-магазинов масштаба сотен тысяч заказов в сутки (т.е. когда вручную разгребать один процент проимевшихся транзакций стало накладно).
В этом и была проблема MSMQ как продукта: сначала широкие массы не понимали, зачем эта хрень нужна ("RPC ж быстрее! И наш любимый Фаулер ничего такого не писал
Здравствуйте, scale_tone, Вы писали:
_>Здравствуйте, Tom, Вы писали:
_>>>В каком месте я сказал что-либо противоречащее Вашему прекрасному утверждению? >>>>Messaging — это в меньшей степени про "корпоративный софт", а прежде всего про высоконагруженные сервисы (SOA и пр.).
_>Еще раз: если бы весь "серьезный корпоративный софт" изначально строился на принципах messaging-а (читай: если б MSMQ с момента своего создания сразу же побил бы по популярности какой-нибудь DCOM) — это было б счастье. К сожалению, дело было не так, и Message Broker-ы получили массовое распространение только с появлением интернет-магазинов масштаба сотен тысяч заказов в сутки (т.е. когда вручную разгребать один процент проимевшихся транзакций стало накладно).
_>В этом и была проблема MSMQ как продукта: сначала широкие массы не понимали, зачем эта хрень нужна ("RPC ж быстрее! И наш любимый Фаулер ничего такого не писал
."), а потом когда поняли, обнаружилось много других более удобных продуктов этой разновидности.
Вы не понимаете для чего используется messagiung и путаете паттерны и продукты. Интеграция корпоративных приложений при помощи обмена сообщениями это патерн, MSMQ/ServiceBroker/ServiseBus/IBM MQ Series это продукты. Разберитесь в теме, хотя бьы для чегор всё таки нужны сообщения и очереди и какие проблемы они решают. А если где то написали чушь — не стесняйтесь это признавать а не писать ещё большую чушь в ответах. Да и в MSMQ вы ни бельмеса как я уверен и в других продуктах не понимаете. А если не так то расскажите чем это так не удобен MSMQ и чем это другие продкты егор рвут
Tom, Вы меня явно с кем-то путаете. И продолжаете хамить, что обидно.
Tom>Вы не понимаете для чего используется messagiung и путаете паттерны и продукты. Интеграция корпоративных приложений при помощи обмена сообщениями это патерн, MSMQ/ServiceBroker/ServiseBus/IBM MQ Series это продукты.
Основная архитектурная проблема у MSMQ одна — отсутствие встроенной репликации хранилища сообщений (в Кролике это queue mirroring). Система сама по себе распределенная, на каждом узле работает свой экземпляр сервиса и держит сообщения (входящие и исходящие) у себя под ногами на диске (и только на диске). По-английски эта проблема формулируется как "MSMQ can't share storage".
Отсюда возникают следующие ограничения:
1. Горизонтальная масштабируемость (в Кролике — work queues) встроенными средствами не обеспечивается. Обеспечивается внешними надстройками (в NServiceBus — distributors) или собственным аналогичным кодом. Но при этом возникает SPoF — это, собственно, узел, который занимается распределением задач (пересылкой сообщений воркер-нодам). Это плавно ведет ко второму пункту:
2. Доступность обеспечивается только за счет развертывания под Windows Failover Cluster. Что само по себе хреново: Windows Failover Cluster — штука дорогая, тяжелая в обслуживании и нестабильная внутренне (сколько раз уже кластер разваливался без видимых внешних причин!). И к тому же, кластеризацией сервиса MSMQ мы добиваемся дублирования сервиса, но не добиваемся дублирования хранилища сообщений. Чтобы при полном издыхании одной из нод кластера оказавшиеся на ее диске сообщения не уходили в /dev/null вместе с нодой, хранилище приходится организовывать на SAN (шарить его кусок между нодами кластера). Это опять дорого, сложно в конфигурировании и нестабильно. И при всем при этом, переезд сервиса с ноды на ноду занимает от нескольких секунд (если все идеально) до бесконечности (это когда опять руками надо собирать разъехавшийся кластер), поэтому доступность получается крайне относительная. Наконец, Failover Cluster с нодами в разных ДЦ — это вещь теоретически возможная, но на практике нереализуемая, посему для резервирования всего ДЦ требуется держать в холодном резерве еще одну маленькую копию всей инфраструктуры в другом ДЦ (опять расходы).
Все эти траблы с обеспечением доступности я в исходном посте обозначил как "отсутствие нормальных инструментов настройки и зависимость от других средств".
, что позволяет решать известную SOA-задачку с сервисами Billing и Shipping без распределенных транзакций (каковые в "корпоративном софте" еще туда-сюда, а в SOA считаются жутким bad smell-ом). Про эти полезности мало знают, и эту траблу я обозначил в исходном посте как "отсутствие документации".
. А более детально, из собственного опыта, ниже. _>Основная архитектурная проблема у MSMQ одна — отсутствие встроенной репликации хранилища сообщений (в Кролике это queue mirroring). Система сама по себе распределенная, на каждом узле работает свой экземпляр сервиса и держит сообщения (входящие и исходящие) у себя под ногами на диске (и только на диске). По-английски эта проблема формулируется как "MSMQ can't share storage".
Репликация — это конечно хорошо, но с репликацией возникает огромное количество вопросов. Как минимум — конфликты. Я слабо понимаю как это работает в кролике, как ноды не конфликтуют, допустим одна нода вычитала и удалила сообщение из очереди. Что будет на другних, сообщение удалится? А если на другой его успели прочитать? А если успели прочитать а удалить не захотели?
_>Отсюда возникают следующие ограничения: _>1. Горизонтальная масштабируемость (в Кролике — work queues) встроенными средствами не обеспечивается. Обеспечивается внешними надстройками (в NServiceBus — distributors) или собственным аналогичным кодом. Но при этом возникает SPoF — это, собственно, узел, который занимается распределением задач (пересылкой сообщений воркер-нодам). Это плавно ведет ко второму пункту:
Итак мы приходим к тому что кролик и MSMQ не являются распределёнными очередями.
_>2. Доступность обеспечивается только за счет развертывания под Windows Failover Cluster. Что само по себе хреново: Windows Failover Cluster — штука дорогая, тяжелая в обслуживании и нестабильная внутренне (сколько раз уже кластер разваливался без видимых внешних причин!). И к тому же, кластеризацией сервиса MSMQ мы добиваемся дублирования сервиса, но не добиваемся дублирования хранилища сообщений. Чтобы при полном издыхании одной из нод кластера оказавшиеся на ее диске сообщения не уходили в /dev/null вместе с нодой, хранилище приходится организовывать на SAN (шарить его кусок между нодами кластера). Это опять дорого, сложно в конфигурировании и нестабильно. И при всем при этом, переезд сервиса с ноды на ноду занимает от нескольких секунд (если все идеально) до бесконечности (это когда опять руками надо собирать разъехавшийся кластер), поэтому доступность получается крайне относительная. Наконец, Failover Cluster с нодами в разных ДЦ — это вещь теоретически возможная, но на практике нереализуемая, посему для резервирования всего ДЦ требуется держать в холодном резерве еще одну маленькую копию всей инфраструктуры в другом ДЦ (опять расходы).
По поводу нестабильности failover cluster-а это конечно повеселили. Переезд сам по себе много времени занимать не должен, время занимает определение что нода жива. У нас на продакшине сиквел failover делаем вообще до пяти минут и это считается норм (Alwaysd On не используется пока).
_>Все эти траблы с обеспечением доступности я в исходном посте обозначил как "отсутствие нормальных инструментов настройки и зависимость от других средств".
_>Ну вот, а в том же Кролике пункт 2 обеспечивается из коробки за счет кластеризации+ queue mirroring.
Да только вы забываете что репликация она как бы штука асинхронная и при смерти узла
Итак мы пришли к выводу что и MSMQ и кролик порддерживают failover cluster, по разному но поддерждивают. Ну ок.
_>В то же время, в MSMQ есть местами и свои полезности. Например, "локальность транзакций"
, что позволяет решать известную SOA-задачку с сервисами Billing и Shipping без распределенных транзакций (каковые в "корпоративном софте" еще туда-сюда, а в SOA считаются жутким bad smell-ом). Про эти полезности мало знают, и эту траблу я обозначил в исходном посте как "отсутствие документации".
Документации вагон.
Кроме того несколько гигантских слонов вы так и не заметили.
А именно поддержку DTC.
С MSMQ вы можете обеспечить в единой распределоённой транзакции чтение сообщение из очереди и изменение БД.
Классический пример — создание ордера. Читаем из очереди сообщение и вставляем в базу в единой транзакции.
Если транзакция в БД отвалилась — сообщение из очереди не удалиться.
Так же не заметили возможность в одной транзакции отослать N сообщений.
Да и ещё тьму всего.
А в принципе архитектурно и кролик и MSMQ это одинаковые по своей сути приложения.
Главная их задача — обеспечить надёжныое хранение и транспорт от узла А к узлу Б которые работают по своему протоколу.
Да кролик немного поновее но и у него легаси уже громадный.
Здравствуйте, Tom, Вы писали:
Tom>Репликация — это конечно хорошо, но с репликацией возникает огромное количество вопросов. Как минимум — конфликты. Я слабо понимаю как это работает в кролике, как ноды не конфликтуют, допустим одна нода вычитала и удалила сообщение из очереди. Что будет на другних, сообщение удалится? А если на другой его успели прочитать? А если успели прочитать а удалить не захотели?
Ну как, так и работает — master-slave-репликация. Клиент шлет ACK (подтверждает, что обработал сообщение) только мастеру, тот рассылает его слейвам. Если мастер помирает в процессе, сообщение будет обработано дважды.
Tom>По поводу нестабильности failover cluster-а это конечно повеселили. Переезд сам по себе много времени занимать не должен, время занимает определение что нода жива.
Не должен. Однако, случается. Сервис MSMQ имеет старческую привычку дефрагментировать свое хранилище при старте (aka при переезде ноды). Что занимает минуты, если накопилось достаточно сообщений (e.g. в deadletter или в outgoing queue).
Tom>А именно поддержку DTC. Tom>С MSMQ вы можете обеспечить в единой распределоённой транзакции чтение сообщение из очереди и изменение БД. Tom>Классический пример — создание ордера. Читаем из очереди сообщение и вставляем в базу в единой транзакции. Tom>Если транзакция в БД отвалилась — сообщение из очереди не удалиться.
Про вычитывание.
Это только MSMQ вычитывает сообщение из входящей очереди с применением DTC. Весь остальной мир (Кролик, Azure Service Bus) используют подтверждения об успешной обработке. Если клиентский обработчик падает с исключением, сообщение откатывается и передоставляется. При этом, если проблема возникла на этапе отправки ACK-а — сообщение да, может обработаться дважды. Это и называется at-least-once-delivery.
В MSMQ же транзакционно вычитываются сообщения только из локальной входящей очереди (пруф). В смысле, только с диска локального компа. Это (наверно) гарантирует однократную обработку сообщения, лежащего в этой локальной очереди. Но не гарантирует, что это сообщение в эту очередь попадет однократно (см. про In-Doubt Transactions).
Т.е. режим exactly-once-delivery, боюсь, недостижим даже в MSMQ. И потому следует просто писать всегда идемпотентные обработчики (иными словами, заказы в БД идентифицировать GUID-ами).
Tom>Так же не заметили возможность в одной транзакции отослать N сообщений.
Про отправку.
Вот как раз таки в MSMQ отослать N сообщений в одной транзакции можно, но коммит этой транзакции говорит только о том, что эти N сообщений уложены в локальную исходящую очередь (там же, еще здесь и здесь).
Т.е. MSMQ-шная часть этой транзакции будет ни разу не "распределенная". Посему e.g. "транзакционная" посылка события сервисуА и сервисуБ вполне может закончиться тем, что сервисА его получит, а сервисБ — нет (если компьютер с сервисомБ выкинут и поставят вместо него новый компьютер, с другим именем).
В то же время e.g. в Кролике publisher confirms гарантируют, что событие успешно уложено во все нужные очереди (их может быть несколько при fanout-е). Т.е. запаблишенные события дойдут в итоге всем, даже если комп внезапно заменят.
Опять же, я не хочу сказать, что "локальность транзакций" в MSMQ — это прям бага. Скорее, это особенность, про которую приходится помнить.
Здравствуйте, Tom, Вы писали:
Tom>>>1.1 Сообщения будут доставлены именно в том порядке в котором они были отосланы Н>>Не знаю про другие системы, но RabbitMQ в некоторых случаях такую гарантию не даёт. Tom>Почитайте про AMPQ и его анзначение
With release 2.7.0 and later it is still possible for individual consumers to observe messages out of order if the queue has multiple subscribers. This is due to the actions of other subscribers who may requeue messages. From the perspective of the queue the messages are always held in the publication order.
Tom>>>1.2 Сообщение будет доставлено только один раз Н>>Нет. Exactly-Once Delivery невозможно гарантировать. Можно гарантировать либо At-Least-Once, либо At-Most-Once. Tom>Мне определённо нравится ваше нет Tom>Поясните
Проблема двух генералов.
Два варианта в случае с RMQ:
Получили сообщение, ack()'нули его, и, так и не начав обрабатывать, упали. Результат: данные (т.е. сообщение) потеряно безвозвратно
Получили сообщение, обработали и упали, не успев ack()'нуть. Результат: сообщение будет доставлено еще раз
То, что в штатном режиме сообщение приходит ровно один раз, не служит основанием полагать, что такое поведение можно гарантировать в любом случае.
Use of acknowledgements guarantees at-least-once delivery. Without acknowledgements, message loss is possible during publish and consume operations and only at-most-once delivery is guaranteed.
Tom>>>1.3 При любых обрывах связи сообщение таки будет доставлено Н>>Тоже нет. Tom>Тоже нет что? )
Нет, при любых обрывах связи сообщение доставлено не будет. Можно поспорить насчет формального определения понятия "доставлено", но что бы вы под этим ни понимали -- гарантии доставки при обрывах связи нет и быть не может.
HgLab: Mercurial Server and Repository Management for Windows
)