В настоящее время у нас RabbitMQ развернут через кластер из трех узлов (работает на Windows VM в том же центре обработки данных). По неизвестным причинам наш кластер был подвержен сетевым разделам по неизвестным причинам. Мы хотим расширить с помощью RabbitMQ, поэтому нам нужно развернуть альтернативный метод / топологию хостинга, который больше подходит для нашей внутренней сети.
Согласно документам, нам кажется, что нам нужна какая-то модель федерации, но мне нужна помощь, чтобы убедиться, что я на правильном пути для рекомендации модели хостинга через федерацию.
Модель, которую я сейчас готов предложить, такова:
- Три узла развернуты как восходящий обмен: UBrokerA, UBrokerB, UBrokerC.
- Балансировщик нагрузки, который находится перед узлами от # 1. Производители сообщений строго используют балансировщик нагрузки для постановки сообщений в очередь.
- В качестве нисходящего обмена развернуты три узла: DSBrokerA, DSBrokerB, DSBrokerC. Потребители сообщений подключаются к этим узлам для обработки сообщений.
- Узлы из # 3 настроены на использование федерации очередей, чтобы потребители могли получать сообщения независимо от обмена, из которого оно было получено. Это будет полный двунаправленный граф.
По моему мнению, преимущество разделения узлов для приема сообщений и узлов для обработки сообщений заключается в том, что они разделяют два отдельных действия. Коллекция узлов кажется более устойчивой к сбоям, если какой-либо один узел неожиданно отключается. Хотя я не могу доказать это, поэтому вполне возможно, что я ошибаюсь.
Через комбинацию обмена и / или федерации очереди, какова идеальная топология для продолжения получения преимуществ, которые может предложить кластер? Наша текущая конфигурация использует прямой обмен, отложенный обмен и пять очередей, связанных с прямым и отложенным обменом. Наиболее важным для нас является то, что сообщения доставляются ровно один раз (необходимо избегать проверки на наличие дубликатов у потребителей), и это крайне важно, чтобы избежать потери сообщений.