Подтвердить что ты не робот

RabbitMQ/ActiveMQ или Redis для более чем 250 000 msg/s

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

  • группа сборщиков событий записывает входящие сообщения в качестве ключа/значения. потребители извлекают и удаляют обработанные ключи
  • загрузка, начинающаяся с 100 тыс. msg/s и выходящая за пределы 250 тыс. за короткий промежуток времени (например, месяцы), предназначена для достижения миллиона мс/с
  • Постоянство не требуется строго. во время сбоя нормально потерять сообщения, не связанные с журналом.
  • производительность очень важна (так, количество систем, необходимых для обработки нагрузки)
  • сообщения не должны обрабатываться в порядке их поступления.

Знаете ли вы такие варианты использования, когда redis выбирается по сравнению с традиционным программным обеспечением для очередей сообщений? или вы считаете что-то еще?

Примечание: я также видел это, но не помог: новичок в режиме реального времени - Node.JS + Redis или RabbitMQ → клиент/сервер как?

спасибо

4b9b3361

Ответ 1

Учитывая ваши требования, я бы попробовал Redis. Он будет работать лучше, чем другие решения, и даст вам намного более тонкий контроль над характеристиками персистентности. В зависимости от языка, который вы используете, вы можете использовать осколочный кластер Redis (вам нужны привязки Redis, поддерживающие последовательное хеширование - не все). Это позволит вам масштабировать объем, указанный вами. Я видел 10k/sec на моем ноутбуке в некоторых базовых тестах.

Вероятно, вы захотите использовать операции списка в Redis (LPUSH для записи, BRPOP для чтения), если вам нужна семантика очереди.

У меня есть бывший клиент, который развернул Redis в качестве очереди сообщений spring, и они были очень довольны этим.