Написание базовой системы очередей довольно просто, но, как вы отметили выше со всеми проблемами, сделать это правильно - это другой вопрос. Я использовал домашние системы, для которых я написал исходный код, сторонние системы и различные 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 сообщений / с. Большая капля.