Что такое кластеризация RabbitMQ? - PullRequest
1 голос
/ 08 декабря 2011

Я уже некоторое время использую RabbitMQ (AMQP) с моими проектами ruby, в любом случае, я только что слышал о кластеризации RabbitMQ, любой может рассказать мне об этом простыми словами, мне нужно знать разницу между запуском обычного сервера RabbitMQ и кластеризация RabbitMQ, зачем она мне нужна и как ее реализовать.

Мне нужно, чтобы мое решение было масштабируемым и обрабатывало так много запросов, я думал о следующей реализации и хотел бы знать, как реализовать такую ​​вещь:

HA proxy->3 Clustered RabbitMQ instances

Какой самый быстрый способ, наряду с лучшим выбором веб-сервера ruby, обрабатывает запрос и просто анализирует его и отправляет в соответствующую очередь.

С моей текущей реализацией я использую Тонкий сервер и делаю что-то вроде следующего, но ищу лучшую архитектуру, которая является более быстрой и более масштабируемой:

require "bunny"
require "thin"


@amqp ||= Bunny.new(:logging => false)
@amqp.start

@direct_exchange ||= @amqp.exchange('') 

app = Proc.new do |env|
  req = Rack::Request.new(env).params

  command = req['command'].strip rescue "no command"
  number  = req['number'].strip  rescue "no number"

  if command =~ /\A(create|c|r|register)\z/i      
    @direct_exchange.publish(number, :key => "create") 

  elsif command =~ /\A(update|u)\z/i
    @direct_exchange.publish(number , :key => "refresh") 

  end    

  [200, {'Content-Type' => "text/plain"} , command ]  

end

Rack::Handler::Thin.run(app, :Port => 4001)

Я уверен, что есть лучшая реализация.

Любая помощь / подсказка будет принята с благодарностью.

Заранее спасибо

1 Ответ

1 голос
/ 08 декабря 2011

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

  • http-балансировщик нагрузки, балансирующий http-запрос к нескольким веб-серверам
  • N веб-серверов, обрабатывающих http-запросы и разбирающих их, завершают публикацию команд на узлах RabbitMQ
  • Кластер RabbitMQ, состоящий из M узлов кролика
  • K рабочих узлов, получающих сообщения от кроличьего кластера и выполняющих команды

Теперь число http-серверов может отличаться от узлов RabbitMQ. Это зависит от того, где будут ваши узкие места. Возможно, вам понадобится только один узел RabbitMQ (поэтому нет кластера) или несколько из них. Например, если их 2, половина ваших http-серверов будет подключена к одному узлу rabbitmq, а половина - к другому. Независимо от того, к чему они подключены, они могут публиковать данные на одном и том же обмене amqp, а кластер rabbtimq позаботится о том, чтобы обрабатывать 2 узла и собирать все, что было опубликовано на этом обмене, под одной шляпой, без подключения к серверу http узла.

Эта же логика применима к «работникам», то есть серверам, которые принимают сообщения от rabbitmq и выполняют в них команды. Их может быть от 1 до K, в зависимости от того, сколько работы им нужно сделать. Вы также можете подключить их равномерно к существующим серверам rabbitMQ.

...