Отслеживание сообщений в чате

мы создали систему чата в Node.JS. Где у нас есть три канала для доставки сообщений: один с использованием протокола mqtt, второй с использованием каналов отправки сторонних сервисов и третий сервис извлечения сообщений на основе полученного gcm. Как только сообщение отправляется от одного пользователя второму пользователю, оно сохраняется в Redis до тех пор, пока оно не будет доставлено второму пользователю. проблема, с которой мы сталкиваемся, заключается в том, что мы не можем отслеживать недостающие сообщения, которые не доставлены. Как мы можем отслеживать сообщения в чате?

Мы попробовали ack сообщений со стороны клиента. Но иногда из-за сбоя api и т. д. мы также не можем получить acks. Из-за чего мы не можем отслеживать сообщения.

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


node.js javascript mqtt redis pusher
person Community    schedule 16.09.2019    source источник
comment
Вы проверяли Redis Streams?   -  person Guy Korland    schedule 16.09.2019
comment
Этот вопрос слишком широк, пожалуйста, прочитайте справку о том, что нужно для хороших вопросов о переполнении стека stackoverflow.com/help/how-to- спросить   -  person hardillb    schedule 16.09.2019

Ответы (1)


arrow_upward
0
arrow_downward

Возможно (если не особый случай) pub/sub не может быть подходящим инструментом, который вам нужен здесь, проблема с pub/sub (mqtt) для этого случая заключается в том, что это широковещательная публикация, что означает, что вы просто публикуете сообщение для кого угодно подписан в теме. Pub/Sub имеет то, что называется качеством обслуживания (QoS), которое имеет 3 уровня, где поведение брокера, обрабатывающего это сообщение, будет зависеть от надежности доставки, которую вы хотите:

QoS:

  • Максимум один раз (0)
  • Хотя бы раз (1)
  • Ровно раз (2)

Уровень QoS 2 может быть тем, который вам нужен, когда сообщение будет повторяться до тех пор, пока оно не будет доставлено получателю, поэтому, если он (получатель) недоступен, брокер будет продолжать пытаться доставить сообщение, но проблема с уровнем QoS 2 заключается в том, что доступен не во всех службах pub/sub (я думаю, что Redis не имеет его, по крайней мере, я знаю)... и, во-вторых, вам нужно знать, кто все получатели, чтобы установить этот уровень QoS.

Здесь вы можете найти более подробную информацию о QoS: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/

Я думаю, что лучшие (и, возможно, самые простые) инструменты, которые вам понадобятся для этого проекта, это

  1. Хранилище данных документов (NoSQL) для хранения сообщений с UUID и временными метками.
  2. Веб-сокет для уведомления всех подключенных клиентов о новых сообщениях. Это будет канал для доставки новых входящих сообщений (а также может работать для извлечения старых сообщений, но зависит от уровня спроса).
  3. Локальное хранилище для хранения сообщений, пока сервер чата недоступен.

И это все.

Может быть, может показаться проще использовать службу публикации/подписки, потому что она связана со сложностью получения, управления и доставки сообщений, но они больше предназначены для отделения от клиентов, которые приходят и уходят с течением времени без осведомлены о других.

person Ruy Garcia    schedule 16.09.2019