Вставить очередь сообщений или базу данных и выбрать - PullRequest
Новая
       36

Вставить очередь сообщений или базу данных и выбрать

0 голосов
/ 24 августа 2011

Я разрабатываю приложение и имею в виду две идеи (ниже). У меня есть процесс, который собирает данные AppX. 30 КБ, и эти данные будут собираться каждые 5 минут и должны обновляться на клиенте (веб-сайт - 100 пользователей в любой момент времени). Собранную информацию не нужно хранить для будущего использования.

Опции:

  1. Я могу получать данные и вставлять их в базу данных каждые 5 минут. И тогда клиентский вызов будет сделан в БД и получит данные и обновит пользовательский интерфейс.

  2. Соберите данные и поместите их в тему или очередь. Теперь несколько клиентов (потребителей) могут перейти в очередь и получить данные.

Я ищу вариант 2 как лучшее решение, потому что он быстрее (без вызовов БД) и без избыточности хранилища.

Кто-нибудь может подсказать, какое решение было бы идеальным и почему?

Ответы [ 2 ]

0 голосов
/ 07 февраля 2017

Мне кажется, что вам нужно использовать очередь и шаблон издателя / подписчика. Это статья о шаблоне RabitMQ и публикации / подписки .

Я могу получать данные и вставлять их в базу данных каждые 5 минут. После этого будет выполнен вызов клиента в БД, который получит данные и обновит пользовательский интерфейс.

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

Когда вы используете очередь, подписчик отменяет адресованное ему сообщение и, конечно, подчиняется порядку (FIFO). Кроме того, будет гарантия доставки, отличная от базы данных, в которой запись может быть удалена, и все же не каждый «подписчик» получил сообщение.

Подводные камни использования базы данных для достижения этой цели:

  • Создание индексов ускоряет запросы, но вставляет медленнее;
  • Придется контролировать гарантию доставки для каждого абонента;
  • Вам понадобится TTL (Time to Live) стратегия для очистки записей (с учетом гарантии доставки);
0 голосов
/ 24 августа 2011

Я не очень понимаю разницу. Данные должны временно храниться где-то до следующего обновления, верно.

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

Здесь могут иметь значение, записываются ли данные в нечто постоянное, например, в базу данных, или в нечто менее постоянное, например, часть веб-сервера или сервера приложений.

Кроме того, вы отметили это как реальное время, но я не вижу, как веб-клиенты получают обновления в режиме реального времени без какого-либо push / long-pull или чего-либо еще.

...