Каковы решения проблемы распределенной очереди?

23

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

Реализация столкнется со многими проблемами и будет вынуждена пойти на компромисс:

  • У него сильный или слабый порядок?
  • Есть ли у него идемпотент?
  • Можем ли мы иметь больше очередей, чем можно разместить на одной машине?
  • Можем ли мы иметь больше данных в очереди, чем то, что может поместиться на одной машине?
  • Сколько машин может дать сбой, прежде чем мы потеряем данные?
  • Может ли он терпеть чистые сплиты?
  • Может ли он автоматически согласовывать данные при фиксированном разделении сети?
  • Это может гарантировать доставку, когда клиенты могут потерпеть крах?
  • Может ли это гарантировать, что одно и то же сообщение не будет доставлено более одного раза?
  • Может ли узел дать сбой в любой заданной точке, вернуться обратно и не отправить ненужную информацию?
  • Можете ли вы добавить или удалить узлы из работающего кластера без простоев?
  • Можете ли вы обновить узлы в работающем кластере без простоев?
  • Может ли он работать без проблем на разнородных серверах?
  • Можете ли вы «прикрепить» очереди к группе серверов? (пример: «эти очереди разрешены только в европейском центре обработки данных»)
  • Можно ли разместить реплики данных как минимум в двух центрах обработки данных, если таковые имеются?

У меня нет иллюзий, что любая реализация сможет сказать «да» на все это. Мне просто интересно услышать о различных реализациях; как они работают, какие компромиссы они сделали и, возможно, почему они выбрали свой конкретный набор компромиссов.

Также, если есть какие-либо проблемы, которые я мог пропустить в приведенном выше списке.

Крис Вест
источник

Ответы:

13

Написание базовой системы очередей довольно просто, но, как вы отметили выше со всеми проблемами, сделать это правильно - это другой вопрос. Я использовал домашние системы, для которых я написал исходный код, сторонние системы и различные JMS-провайдеры. JMS (Java Messaging Service) на сегодняшний день является наиболее полным решением, с которым я когда-либо сталкивался. Многое из того, что вы спрашиваете, доступно в JMS. Мой любимый провайдер JMS - ActiveMQ. Бесплатный, производительный, простой в установке и, что еще важнее, простой встраивание в мое приложение с помощью Spring. Поставщики JMS не предоставляют все, о чем вы просили, «из коробки», но они предоставляют набор инструментов для обработки большей части того, о чем вы просили, если это потребуется вашему приложению. Я не нашел много приложений, которым нужно все, что вы перечислили. Заказ не может быть важным (лучше, если это не так),

http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html

У него сильный или потерянный порядок? Да. Это имеет как в зависимости от потребностей ваших программ. Вот подробности: http://activemq.apache.org/total-ordering.html .

Есть ли у него идемпотент? Нет, но это просто реализовать на уровне приложений, если вам это нужно.

Можем ли мы иметь больше очередей, чем можно разместить на одной машине? Да. У вас могут быть кластерные серверы, и если вы хотите настроить несколько машин с разными очередями, вы можете выбрать один из них.

Можем ли мы иметь больше данных в очереди, чем то, что может поместиться на одной машине? Да, большинству провайдеров JMS приходится использовать своего рода БД / постоянное хранилище, чтобы гарантировать, что сообщения не будут отброшены или потеряны в случае сбоя провайдера JMS.

Сколько машин может дать сбой, прежде чем мы потенциально потеряем данные? Это немного сложнее ответить, потому что это связано со временем. Тем не менее, вы можете аварийно завершить работу JMS-провайдера, и, если диск не поврежден, он вернется и запустится там, где он получил последний коммит. Это означает, что сообщения могут быть доставлены дважды, но если вы кодируете свое приложение для обработки, это не проблема. Если у вас есть хотя бы один из каждого типа (производители, потребители или JMS-серверы), он будет завершен. Вы также можете использовать нагрузку / балансирование / восстановление после сбоя для избыточности, если на вас выходит диск.

Может ли это повлиять на сетевые сплиты? Думаю, я понимаю, что вы имеете в виду под «net-split», но я не совсем уверен. Я предполагаю, что вы имеете в виду, если JMS-серверы кластеризованы, и мы потеряем связь с одним из серверов, он перейдет на другой сервер и перехватит, где он остановился. Да, но опять же, эти типы ситуаций могут привести к дублированию сообщений в зависимости от того, в какой момент клиент потерял соединение.

Может ли он автоматически согласовывать данные при фиксированном разделении сети? Если вы используете транзакционные сеансы, он только повторно доставит любое сообщение, для которого была вызвана фиксация, для существующих клиентов.

Это может гарантировать доставку, когда клиенты могут потерпеть крах? Да, это одна из главных целей JMS. Гарантированная доставка означает, что если сообщение поставлено в очередь, оно гарантированно будет обработано клиентом.

Может ли это гарантировать, что одно и то же сообщение не будет доставлено более одного раза? Да, если используются транзакции. Это означает, что клиент принял сообщение и вызвал commit / rollback. После вызова коммита сообщение не будет повторно доставлено.

Может ли узел дать сбой в любой заданной точке, вернуться обратно и не отправить ненужную информацию? В случае, если у вас есть длительные кластерные очереди. Да, он не извергает «мусор», если другой узел в кластере доставил сообщение. Он все еще может пересылать все, что не было подтверждено.

Можете ли вы добавить или удалить узлы из работающего кластера без простоев? Да.

Можете ли вы обновить узлы в работающем кластере без простоев? Мне немного сложнее ответить, но я верю, что да, вы можете сделать это.

Может ли он работать без проблем на разнородных серверах? Что это значит точно? Я обнаружил, что большинство провайдеров JMS очень легко работают в средах, использующих различное оборудование, ОС и т. Д. Хотя, если вы имеете в виду производительность, это совсем другое дело. Медленный узел может негативно повлиять на любую систему распределенной обработки. У меня было 2 8-ядерных сервера Intel, на которых работала очередь и потребители. Это вместе 16 ядер, и я получил лучшую производительность от использования только этих двух блоков, чем когда я добавил одноядерный компьютер в качестве потребителя. Эта одноядерная машина была настолько медленной, что замедляла всю сетку в 2 раза. Это не имело ничего общего с JMS.

Можете ли вы «прикрепить» очереди к группе серверов? Краткий ответ да. Я могу придумать, как можно запустить кластер только в европейском центре обработки данных и настроить там очередь. Затем в вашей весенней конфигурации настройте своих потребителей на использование этой очереди, а также других очередей в других кластерах. Вы можете обратиться к документации:

http://activemq.apache.org/clustering.html

Можно ли разместить реплики данных как минимум в двух центрах обработки данных, если таковые имеются? Опять же, я верю в это, но лучше обратиться к документации по кластеризации.

Опять же, у JMS есть множество опций, которые вы можете настроить в соответствии с вашими потребностями. Использование транзакционных сеансов и длительных очередей сопряжено с затратами на производительность. Я видел, как включение всех наворотов влияет на производительность в 10 раз. Когда я использовал JBossMQ, если мы отключили некоторые из этих функций, мы могли получить около 10000 сообщений / с, но их включение снизило до 1000 сообщений / с. Большая капля.

chubbsondubs
источник
Спасибо, что нашли время с этим ответом. Net-split - это когда некоторые узлы в кластере больше не могут связываться с остальными. Под гетерогенными серверами я в основном имею в виду разные объемы оперативной памяти - некоторые распределенные системы предпочитают, когда серверы выглядят одинаково.
Крис Вест
Тогда точно да на netsplits. Если потребитель отключается или не может общаться, он будет продолжать пытаться подключиться. Задания, которые были переданы ему и не получили коммит, будут позже доставлены другим потребителям. Если провайдер JMS выходит из строя, и у вас есть другие члены кластера, сообщения могут дублироваться по всему кластеру, чтобы избежать потери сообщений.
chubbsondubs
Нет никаких требований к тому, чтобы машины были идентичны, будь то ОЗУ, аппаратное обеспечение или ОС. Вы можете запустить смешанный пакет машин, если вам нужно. Единственное беспокойство, которое я заметил, касается производительности, связанной с тем, что разные машины будут обрабатывать сообщения с разной скоростью, что может привести к снижению пропускной способности. Тем не менее, JMS-модель несколько смягчает это тем, что вместо модели push она тянет. Push-модели гораздо более чувствительны к этим типам проблем.
chubbsondubs