Как создать очередь с несколькими рабочими?

Question

Я хочу создать очередь, в которой клиенты могут помещать запросы, тогда потоки рабочего сервера могут вытащить их, поскольку у них есть доступные ресурсы.

Я изучаю, как это сделать с репозиторием Firebase, а не с внешней службой очереди, которая затем должна будет вводить данные обратно в Firebase.

С безопасности и проверки инструментов в виду, вот простой пример того, что я имею в виду:

• пользователь нажимает запрос в «очереди» ведро
• серверы вытаскивать запрос и удалений он (как я могу гарантировать только один сервер получает запрос?)
• сервера проверяет данные и извлекает из частного ведра (или впрыскивает новые данные)
• сервера помещает данные и/или ошибки обратно в ведро пользователя

Упрощенный пример того, где это может быть полезно было бы аутентификации:

• пользователь помещает запрос на аутентификацию в общей очереди
• его логин/пароль переходит в его частную ведре (место, где только он может читать/записывать)
• сервер подбирает запрос аутентификации, получает логин/пароль и проверяет его против частного buc только KET сервер может получить доступ к
• на сервер помещает маркер в частное ведро пользователя

(конечно, есть еще какие-то лазейки безопасности в общей очереди; Я просто исследовать в этой точке)

Некоторых других примеров для использования:

• только для чтения очереди статуса (статус пользователя передаются через частное ведро, сервер запись его в общественное ведро, которое предназначено только для чтения для общественности)
• очереди сообщений (сообщения посылаются через пользователь, сервер решает, какие ведра дискуссионных они понижены в)

Так вопросы:

1. Это хороший дизайн, который будет хорошо интегрироваться в предстоящие планы безопасности? Какие существуют альтернативные подходы?
2. Как заставить все серверы прослушивать очередь, но только один, чтобы выбрать каждый запрос?

Answer 1

Ничего себе, отличный вопрос. Это шаблон использования, который мы обсудили внутренне, поэтому мы хотели бы услышать о вашем опыте его реализации (support@firebase.com).Вот некоторые мысли на вопросы:

Authentication

Если ваша главная цель на самом деле аутентификация, просто ждать наших функций безопасности. :-) В частности, мы намерены иметь возможность делать auth, поддерживаемые вашим собственным серверным сервером, поддерживаемым магазином пользователей firebase или поддерживаемым сторонними провайдерами (Facebook, твиттер и т. Д.).

балансировка нагрузки Queue Работы

Независимо от AUTH, есть еще интересный случай использования для использования Firebase в качестве основы для какого-то нагрузки системы балансировки, как вы описали. Для этого есть несколько подходов, которые вы можете предпринять:

1. Как вы описали, у вас есть одна рабочая очередь, в которой все ваши серверы будут смотреть и удалять элементы. Вы можете выполнить это, используя transaction(), чтобы удалить элементы. transaction() обрабатывает конфликты, так что транзакция только одного сервера будет успешной. Если один сервер ударяет второй сервер в рабочий элемент, второй сервер может прервать свою транзакцию и повторить попытку следующего элемента в очереди. Этот подход хорош, потому что он автоматически масштабируется при добавлении и удалении серверов, но для каждой попытки транзакции есть накладные расходы, так как он должен совершать круговое путешествие на серверы firebase, чтобы убедиться, что никто еще не схватил элемент из очереди. Но если время, затрачиваемое на обработку рабочего элемента, намного больше, чем время, чтобы совершить кругосветное путешествие на серверы Firebase, это накладные расходы, вероятно, не очень важны. Если у вас много серверов (т. Е. Больше конкурентов) и/или много мелких рабочих элементов, накладные расходы могут быть убийцей.
2. Наведите балансировку нагрузки на клиента, сделав их случайным образом выбранным из числа рабочих очередей. (например, иметь/queue/0,/queue/1,/queue/2,/queue/3, и клиент случайно выбирает один). Затем каждый сервер может контролировать одну рабочую очередь и владеть всей обработкой. В целом, это будет иметь наименьшие издержки, но оно не масштабируется так же легко, когда вы добавляете/удаляете серверы (вам, вероятно, потребуется сохранить отдельный список рабочих очередей, которые серверы обновляют, когда они выходят в сеть, а затем имеют клиентов отслеживать список, чтобы они знали, сколько очередей на выбор и т. д.).

Лично я бы наклонился к варианту № 2, если вам нужна оптимальная производительность. Но №1 может быть проще для прототипирования и, по крайней мере, изначально быть в порядке.

В целом, ваш дизайн определенно находится на правильном пути. Если вы экспериментируете с реализацией и сталкиваетесь с проблемами или имеете предложения для нашего API, сообщите нам (support@firebase.com :-)!

Answer 2

Этот вопрос довольно старый, но в случае, если кто-то делает это здесь так или иначе ...

С серединой 2015 Firebase предлагает что-то называется Firebase Queue, отказоустойчивые мульти-мастер, работа трубопровод, проложенный на Firebase.

В: Это хороший дизайн, который будет хорошо интегрироваться в предстоящие планы безопасности?

A: Ваше дизайнерское предложение идеально подходит для очереди Firebase.

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

A: Ну, это в значительной степени то, что Firebase Queue делает для вас!

Ссылки:

• Introducing Firebase Queue (blog entry)
• Firebase Queue (official GitHub-repo)