Проектирование системы с использованием очередей сообщений и координационных служб

Question

Я новичок в разработке системы и имею некоторые сомнения в очередях сообщений и координирующих сервисах (zookeeper).

Это будет здорово, если кто-то может внести ясность в эти понятия: -

Мое понимание MQ в системе, что я проектирование: -

у меня будет служба производителя, который будет создавать сообщения и добавлять в MQ. Потребитель будет потреблять это сообщение и выполнять соответствующие действия. После того, как пользовательский ACK завершит обработку сообщения; MQ переместит смещение к следующему. Я не хочу, чтобы мои сообщения были пропущены, поэтому я должен быть уверен, что сообщения были успешно использованы. Также я пытаюсь, чтобы эта система потребляла сообщения ровно один раз (как можно ближе).

Теперь я следующие вопросы на основе этого понимания: -

1) Если я хочу, чтобы мой производителя и потребителя, чтобы быть запущен только один экземпляр (для высокой доступности) в том же DC, то мне нужно, чтобы иметь как производителя, так и потребителя в качестве отдельных услуг Zookeeper? Могут ли все мои разные сервисы (в мире микросервисов) нуждаться в отдельном сервере/экземпляре zookeeper или один и тот же экземпляр может решить эту проблему?

2) Когда сообщения потребляются Потребителем, он будет ACK MQ после его потребления (завершение обработки и принятие любых необходимых мер). Я пытаюсь понять, как это будет быстрее для системы, которая будет иметь тысячи запросов каждую секунду. Если мы читаем больше сообщений или не дожидаемся ACK до обработки, то в случае отказа пользователя эти сообщения будут пропущены, так как они никогда не обрабатывались успешно. Я понимаю, что с большим количеством потребителей это будет работать параллельно, но не ясно, как эта концепция работает. Может ли кто-нибудь объяснить мне, какой будет правильный способ потребления и настройки взаимодействия между компонентами, чтобы он был оптимизирован, а также постоянным, высоким, надежным и закрытым, как раз, когда-то моделью.

EDIT: Я планирую использовать Java, Zookeeper, Kafka, Cassandra в системе.

Answer 1

Очередь сообщений может, как и любая система обмена сообщениями, работать в двух основных режимах: по крайней мере один раз доставки или не более одного раза. Оба стремятся ровно один раз, но мы говорим о краевых случаях здесь. Вам нужно будет выбрать один из них. Если вся ваша связь между производителями и потребителями (включая производителя-производителя и потребителя-потребителя) проходит через очередь сообщений, то только очередь сообщений нуждается в кластере zookeeper. Предпочтительным способом этого является централизация всех сообщений через единую систему.

Вы нацеливаетесь ровно на доставку, потому что расточительно выполнять одну и ту же работу дважды, или потому что все горит на земле, если вы делаете то же самое дважды?

Если первый, постройте что-то простое. Либо сама очередь сообщений может отслеживать это, так как она перестанет просить новых потребителей использовать задачу, как только один из них ответит на результат, или, если хранилище должно быть немного более постоянным, используйте redis или couchbase или cassandra или какой-то простой магазин ключей/ценностей, чтобы сохранить то, что было успешно выполнено. Помните о запросах, которые вы отправили, но не получили ответа из памяти. Сохраните примечание «это мероприятие compeleted» в базе данных.

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