Чаты в режиме реального времени с использованием Redis - как не потерять сообщения? - PullRequest
Новая
       90

Чаты в режиме реального времени с использованием Redis - как не потерять сообщения?

0 голосов
/ 21 сентября 2019

Я хочу реализовать чат в реальном времени.Моя основная база данных - это PostgreSQL с бэкэндом, написанным на NodeJS.Клиентами будут мобильные устройства.

Насколько я понимаю, для достижения производительности обмена сообщениями в реальном времени мне нужно использовать Redis.Поэтому я планировал использовать Redis для X самых последних сообщений между 2 и более людьми (групповой чат), например 1000, и все синхронизируется и поддерживается в моей основной базе данных, которой является PostgreSQL.Однако, поскольку Redis - это, по сути, просто RAM, история чата может быть слишком «уязвимой» из-за нестабильности хранения данных в RAM.Поэтому, если на моем сервере Redis произойдет непредвиденный и временный сбой, последние сообщения в разговорах будут потеряны.

Каковы наилучшие практики в настоящее время для реализации чего-либо подобного?Мне просто нужно сохранить данные Redis на диск?но в этом случае, не повредит ли это производительности, так как это увеличит время записи для каждого отправленного сообщения?

Или, может быть, я должен просто подготовить метод восстановления, который извлекает недавнюю историю из PostgreSQL в случае, если мой список истории чата в Redis пуст?

PS - пока мы здесь, не могли бы выПожалуйста, предложите хороший подход для поддержания статуса пользователей (онлайн / оффлайн)?Это сделано и с Redis?

1 Ответ

1 голос
/ 21 сентября 2019

Каковы на сегодняшний день лучшие практики для реализации чего-то подобного?Мне просто нужно сохранить данные Redis на диск?но в этом случае, не повредит ли это производительности, поскольку это увеличит время записи для каждого отправленного сообщения?

  • Да, включение сохранения будет влиять на производительность redis.
  • Лучшей ставкой будет быстрый тест с ожидаемыми IOPS и типом операций из вашего приложения для определения воздействий на IOPS с включенным постоянством.

  • RBD против AOF:

    • При включенном постоянстве RDB родительский процесс не выполняет дисковый ввод-вывод для сохранения изменений данных в RDB.На основании значений save points redis разветвляет дочерний процесс для выполнения RDB.
    • Однако, исходя из конфигурации save points, вы можете потерять данные, записанные после последней точки сохранения - в случае событияперезапуска или сбоя сервера, если данные не были сохранены с последней точки сохранения
    • Если ваш вариант использования не может допустить потери данных за этот период, вам нужно взглянуть на метод персистентности AOF.AOF будет отслеживать все операции записи, которые можно использовать для построения данных при перезапуске сервера.
    • AOF с политикой fsync, установленной на каждую секунду, может быть медленнее, однако он может быть таким же хорошим, как RDB, если fsyncотключен.
    • Прочитайте компромисс использования RDB или AOF: https://redis.io/topics/persistence#redis-persistence

PS - пока мыпри этом, не могли бы вы предложить хороший подход для поддержания статуса пользователей (онлайн / оффлайн)?Это также сделано с Redis?

  • Да
...