Работа с дубликатами в очереди сообщений - PullRequest
0 голосов
/ 15 января 2019

Допустим, у меня высоконагруженный форум вопросов и ответов, например переполнение стека. Представьте, что есть только две темы: Первая и Вторая. Каждый раз, когда кто-то публикует ответ / ответ, он вызывает две вставки в очередь сообщений. 1. команда для вставки поста / ответа и 2. команда для восстановления кеша данного потока.

Предположим, у меня есть моментальный снимок очереди за определенное время:

0: insert First.1 answer
1: rebuild First
2: insert First.2 answer
3: rebuild First
4: insert Second.1 answer
5: rebuild Second
6: insert First.3 answer
7: rebuild First

A. / При обработке очереди на шаге 1, существует ли какой-либо механизм, который помог бы понять, что еще есть перестройки "First" в # 3 и # 7, и поэтому # 1 и # 3 могут быть отброшены, и только # 7 можно обработать?

Б. / Какой продукт очереди сообщений (RabbitMq, Kafka, ActiveMQ ...) может быть лучшим для этого использования? Важнейшим свойством здесь является производительность и масштабируемость, поскольку приложение должно обрабатывать> 100 000 требований / с, примерно с 10% операций записи (против 90% операций чтения из кэша).

Спасибо за любой совет. (не домашнее задание, просто упрощение слишком сложной задачи, чтобы описать ее более подробно)

1 Ответ

0 голосов
/ 17 января 2019

Я полагаю, что терминология, которую вы ищете здесь, - это «разоблачение». Если я служба перестройки индекса, я могу знать, что для перестройки индекса требуется 5 секунд. Таким образом, существует возможность получения нескольких сообщений в течение периода времени, необходимого для перестройки индекса. Подпрограмма debounce будет работать с постоянной времени, принимая множество сообщений, но создавая один запрос на перестроение за разумную единицу времени.

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

Вот ресурс , который, вероятно, касается того, чего вы пытаетесь достичь, по крайней мере, концептуально.

...