Ищу архитектурный совет относительно Redis vs RabbitMQ + Aerospike
Я нахожусь на распутье в планировании архитектуры и не имею достаточного производственного опыта с Redis, Aerospike или RabbitMQ, чтобы знать, как действовать дальше.
Есть 3+ производителей и 15+ рабочих нескольких типов. Система имеет переменную нагрузку в диапазоне 0-10 кОм / с. У меня есть четыре требования:
- очереди
- Блокировка
- Pub/Sub
- Обмен данными
Вот как работает архитектура в упрощенном виде:
Когда поступает новый клиентский запрос, мьютекс производителя блокирует этот маркер запроса вместе с ресурсами, которые будут использоваться работниками, которым он может немедленно отправить задачи, чтобы сказать "этот производитель отвечает за эти фрагменты данных". Производитель помещает динамически сгенерированные задачи в очереди. Разнообразные рабочие выскакивают из очередей и исполняют. Если рабочий отказывает, другой подхватывает ту же задачу по истечении времени ожидания. Когда работник закончил, он сохраняет свои результаты, а затем публикует "Идентификатор задачи завершен" для всех производителей. (Подробнее об этом позже) Если работнику требуется дополнительный пользовательский ввод, он сохраняет свой сеанс, а затем публикует "Идентификатор задачи требует дополнительной информации" всем производителям. Предполагая, что один из работников производителя запросил дополнительную информацию (полученную по подписке), и производитель все еще имеет клиентское соединение, которое он упаковывает и отправляет запрос данных клиенту, который завершает HTTP-соединение с производителем. Теперь производитель разблокирует токен запроса, потому что у него нет соединения. Другие работники могут все еще обрабатывать в этом состоянии "без головы", и тот же производитель может по-прежнему выдавать очередям больше задач, поскольку другие работники заканчивают свои задачи и удовлетворяют зависимости. (Пока клиент еще не подключился ни к одному производителю) Теперь, когда клиент восстанавливает HTTP-соединение, он может не подключиться к тому же производителю. Таким образом, производитель, который получает соединение, публикует другим производителям "Я получил возобновленное клиентское соединение с токеном X". Это скажет любому другому производителю, который все еще может блокировать ресурсы и выдавать новые задачи, чтобы остановить обработку рабочих результатов и выпуск новых задач. Этот новый производитель с клиентским подключением затем заблокирует маркер запроса вместе с ресурсами, которые будут использоваться теперь разблокированными работниками. (Наряду с обработкой результатов, связанных с рабочими местами, если таковые имеются). Производитель определяет, какие зависимости может разблокировать новая клиентская информация, и начинает выдавать больше задач, пока вся работа не будет завершена. Затем связывает результаты, сохраняет в Postgres, архивирует в S3 и отправляет окончательный ответ клиенту.
Это подводит меня к моей дилемме. Я мог бы использовать Redis для всех четырех моих требований для простоты, однако я слышал, что кластеры могут легко потерять записи, если основной отказывает. Кроме того, потому что мне всегда нужны свежие данные, которые никто из моих рабочих или производителей не мог прочитать от рабов. Поэтому я бы использовал кластер Redis для репликации в горячий резерв. (Нет требований к шардингу)
Более сложная, но более безопасная альтернатива - использовать RabbitMQ для организации очередей и обмена темами для "pub/sub". При использовании Aerospike для обмена данными и блокировки мьютексов.
В прошлом у меня был плохой опыт, когда NodeJS и Python могли поддерживать стабильные соединения AMQP с RabbitMQ, что заставляет меня опасаться повторять попытки. (Система, которую он заменяет, использует Redis + RabbitMQ) Но мне ДЕЙСТВИТЕЛЬНО нравится простота использования только Redis для всего.
Так как вы, ребята, думаете, что я могу безопасно использовать кластер AWS Elasticache Redis, не опасаясь возможной потери записей или чтения устаревших данных в случае сбоя основной системы? Или вы думаете, что повышенная сложность использования RabbitMQ + Aerospike будет более отказоустойчивой и избавит меня от долговременных головных болей?
Спасибо заранее и нашли время, чтобы прочитать эту стену текста.