Redis Streams для реализации приложения Messaging System (чат) по сравнению с традиционными подходами - PullRequest
1 голос
/ 14 марта 2020

Я внедряю приложение чата, которое будет поддерживать как беседу один на один, так и групповые беседы.

До сих пор предполагалось использовать Redis Pub / Sub с PostgreSQL в качестве холодного хранилища. и WebSocket является транспортным средством. Каждый пользователь при запуске извлекает историю из postgresql (вплоть до отметки времени соединения WebSocket + redis), а затем подписывается на каналы, которые go, по собственному user_id.

Тем не менее, иметь двустороннее сообщение с DMBS с каждым новым сообщением звучит немного странно, хотя определенно выполнимо и просто git. Поэтому я решил изучить другие подходы. Одним из возможных подходов было использование Kafka и полное исключение необходимости в СУБД. Это звучит жизнеспособно и имеет свои преимущества.

Но оказалось, что на блоке появился новый ребенок - Redis Streams.

Из того, что я понял, на самом деле он очень похож на Кафку в этом конкретном c сценарии (чат). Он имеет много приятных функций, которые кажутся очень удобными для реализации системы чата.

И теперь я пытаюсь понять, является ли Streams + устойчивость диска разумным путем к go по сравнению с Kafka по сравнению с PostgreSQL + Redis pub / sub

Основные рассматриваемые аспекты:

  1. Производительность . Postgres и Kafka работают на диске, что означает более медленную, чем операции в памяти, в случае с redis. С другой стороны, очевидно, что сообщения должны быть постоянными и доступными в любое время и в любых событиях, поэтому redis будет сохраняться на диске. Разве это не сведет на нет весь прирост производительности в памяти? И даже если нет - будет ли заметно увеличение производительности при пиковой нагрузке и большой базе данных?
  2. Память / затраты . С Redis эти два тесно связаны между собой. В качестве небольшого стартапа усилия сосредоточены на том, чтобы быть готовыми справиться с внезапными пиками масштаба (до миллиона пользователей), но в то же время - затраты должны быть минимизированы. Будет ли хранение миллионов сообщений в потоках слишком дорогостоящим, что, в свою очередь, приведет к финансовым затратам?
  3. Восстановление, надежность и доступность, постоянство . с Postgres даже один экземпляр может обрабатывать большую нагрузку c, но он также может предлагать настройки главный-подчиненный и согласованность. Может ли Redis соответствовать этому? Кроме того, с DMBS я могу быть уверен, что данные останутся. Могу я узнать это с помощью redis?
  4. Масштабирование .
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...