Синхронизация одного экземпляра очереди с несколькими экземплярами Redis

Сценарий: У нас есть несколько узлов, распределенных географически, на которых мы хотим иметь очереди, собирающие сообщения для этого местоположения. А затем мы хотим отправить эти собранные данные из каждой очереди на каждом узле в соответствующие им очереди в центральном расположении. В центральном узле мы будем вытягивать данные, собранные в очередях (из других узлов ), обрабатывать их и сохранять персистентно.

Ограничения:

• Данные очень важны для нас. Поэтому мы должны убедиться, что мы ни в коем случае не теряем данные.
• Поэтому нам нужны постоянные очереди на каждом узле, чтобы даже если узел выйдет из строя по какой-то случайной причине, когда мы его поднимем, у нас будут собранные данные в безопасности, и мы сможем отправить их на центральный узел, где они могут быть обработаны.
• Точно так же, если центральный узел выйдет из строя, данные должны остаться на всех других узлах, чтобы, когда центральный узел включится, мы могли отправить все данные на центральный узел для обработки.
• Кроме того, данные на центральном узле не должны дублироваться или сохраняться повторно. То есть данные, собранные на одном из узлов, должны храниться на центральных узлах только один раз.
• Данные, которые мы собираем, очень важны для нас, и порядок доставки данных на центральный узел не имеет значения.

Наше решение Мы рассмотрели несколько решений, из которых я собираюсь перечислить то, которое, по нашему мнению, будет лучшим. Возможное решение (, по нашему мнению ), состоит в том, чтобы использовать Redis для поддержки очередей повсюду, поскольку Redis обеспечивает постоянное хранилище.Затем, возможно, запустите демон на всех географически разделенных узлах, который считывает данные из очереди и отправляет их на центральный узел. Центральный узел при получении данных отправляет ACK узлу, от которого он получил данные (, поскольку данные очень важны для нас ), а затем, получив ACK, узел удаляет данные из очереди. Конечно, будет период ожидания, в течение которого должен быть получен ACK.

Проблема Приведенное выше решение (по нашему )будет работать нормально, но проблема в том, что мы не хотим реализовывать весь протокол синхронизации самостоятельно по той простой причине, что здесь мы можем ошибаться. Нам не удалось найти именно этот способ синхронизации в Redis. Таким образом, мы открыты для других очередей на основе AMQP, таких как RabbitMQ, ZeroMQ и т. д. Мы снова не смогли выяснить, можем ли мы сделать это с этими решениями.

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