Комментарии: 3
🦾
В этот раз хотябы всего 4 часа дебага, а не вся ночь, но произошло следующее:
У нас есть кастомный fan-out exchange, к нему привязаны несколько topic exchange
Один сервис шлет сообщения в другой используя свой topic exchange, а потом когда пытается отправить в третий сервис в 70% случаев падает с ошибкой "No queue found"
Перепроверили все последние MR, все метрики, все секреты, все кластеры, написали кучу доп тестов на RMQ, посылаем кастомные сообщения в каждый узел и по всем показателям все ОК
Единственное что нашли: произошел сетевой сбой одного одного из узлов RMQ, но быстро пришел в норму и показатели начали именно с этого момента падать вниз
Перезагружаем сервисы и теперь в 100% случаев ошибки "No queue found"...
С учетом, что в админке RMQ он показывает абсолюнтую хуйню про использование exchange и queue (чаще всего он будет говорить, что нагрузки нет, хоть она есть) ориентироваться на него не приходится
И тут мне приходит мысль: "Если со стороны consumer все хорошо, а со стороны publisher он не видит очереди, значит узел не сообщил кластеру об exchange, который эту очередь держит"
Удаляю exchange, переподнимаем сервисы его использовавшие, они его пересоздают и все приходит в норму...
То есть, этот пидр показывал, что абсолютно все правильно, но на деле, просто не синхронизировал exchange после сетевого падения...
Это прям пиздец, это прям вообще теперь нельзя доверять этой системе, когда она не может синхронизировать нормально свою собственную конфигурацию
RMQ всегда страдал именно от того какой он "умный брокер" и вот еще одно подтверждение
Сразу скажу: Kafka, Redpanda, Redis и Cloud очереди – не вариант, что вы можете посоветовать как альтернативу?
Единственное, что я использовал и проблем с этим не было, это VerneMQ, использующая MQTT протокол, это интересный выбор, но для большинства неочевидный, поэтому интересно что вы используете
У нас есть кастомный fan-out exchange, к нему привязаны несколько topic exchange
Один сервис шлет сообщения в другой используя свой topic exchange, а потом когда пытается отправить в третий сервис в 70% случаев падает с ошибкой "No queue found"
Перепроверили все последние MR, все метрики, все секреты, все кластеры, написали кучу доп тестов на RMQ, посылаем кастомные сообщения в каждый узел и по всем показателям все ОК
Единственное что нашли: произошел сетевой сбой одного одного из узлов RMQ, но быстро пришел в норму и показатели начали именно с этого момента падать вниз
Перезагружаем сервисы и теперь в 100% случаев ошибки "No queue found"...
С учетом, что в админке RMQ он показывает абсолюнтую хуйню про использование exchange и queue (чаще всего он будет говорить, что нагрузки нет, хоть она есть) ориентироваться на него не приходится
И тут мне приходит мысль: "Если со стороны consumer все хорошо, а со стороны publisher он не видит очереди, значит узел не сообщил кластеру об exchange, который эту очередь держит"
Удаляю exchange, переподнимаем сервисы его использовавшие, они его пересоздают и все приходит в норму...
То есть, этот пидр показывал, что абсолютно все правильно, но на деле, просто не синхронизировал exchange после сетевого падения...
Это прям пиздец, это прям вообще теперь нельзя доверять этой системе, когда она не может синхронизировать нормально свою собственную конфигурацию
RMQ всегда страдал именно от того какой он "умный брокер" и вот еще одно подтверждение
Сразу скажу: Kafka, Redpanda, Redis и Cloud очереди – не вариант, что вы можете посоветовать как альтернативу?
Единственное, что я использовал и проблем с этим не было, это VerneMQ, использующая MQTT протокол, это интересный выбор, но для большинства неочевидный, поэтому интересно что вы используете
🦾
При том что на всякий случай: это стандартный EDA, нам в этой схеме подошла бы и Kafka, потому что Consumer group + Partition решили бы весь вопрос, то есть мы нигде даже не используем что-то RMQ специфичное
Нам просто нужно публиковать в конкретную очередь, и читать из нее разными наборами сервисов с уникальностью на уровне Consumer Group
Нам просто нужно публиковать в конкретную очередь, и читать из нее разными наборами сервисов с уникальностью на уровне Consumer Group