RabbitMQ как прокси между хранилищем данных и производителем?
У меня есть некоторый код, который производит много данных, которые должны храниться в базе данных. Проблема состоит в том, что база данных не может оставаться с данными, что это производится. Таким образом, я задаюсь вопросом, помог ли некоторый механизм организации очередей в этой ситуации - я думаю в особенности в RabiitMQ и выполнимо ли сохранить данные в его очередях, пока некоторый потребитель не вытаскивает данные из него и продвигает его к базе данных. Кроме того, я не конкретен, заинтересовал, добрались ли те данные до базы данных или не потому что довольно скоро, те же данные будут обновлены.
1 ответ
@hyperboreean Возможно, это звучит немного наигранно, но, возможно, то, что вам действительно нужно - это кэш, такой как Redis или MemcacheD ?
Технически вы могли бы использовать RabbitMQ с потребителями, обновляющими БД, но вам нужно реализовать механизм "очистки очереди", иначе ваши очереди будут расти все больше и больше, пока скорость ввода данных все еще превышает то, что может обработать БД. По мере роста очередей данные в них становятся несвежими - это означает, что обновление, которое было только что отправлено, все еще находится в очереди. Подумайте об этом как о магазине с одним контролером. Конечно, вы можете сформировать отдельные очереди, но это означает, что у вас будет несколько длинных очередей, а контролер все равно один. Вы все еще ограничены скоростью, с которой контролер может обработать ваших клиентов.
Из слишком краткого описания следует, что ваши данные действительно являются быстротечными, и система кэширования (или другая NoSQL-подобная система) может подойти лучше. Если вам нужно сохранить данные в конечном итоге, у вас может быть отдельный процесс, который извлекает текущие данные из механизма кэша и загружает их в вашу БД. Тогда вы будете ограничены тем, сколько времени ушло на извлечение данных по сравнению с тем, как часто вы можете загружать данные в БД.