Cassandra пишет дросселирование с несколькими клиентами

Question

У меня есть два клиента (отдельные док-контейнеры), оба пишут в кластер Cassandra.

Первый - это запись данных в реальном времени, которые поступают со скоростью, с которой может справиться кластер, хотя и с небольшим запасом емкости. Это считается высокоприоритетными данными, и мы не хотим отбрасывать их. Скорость проглатывания варьируется от минуты к минуте. Иногда данные резервируются в очереди, из которой клиент читает, а в других случаях клиент очищает очередь и (кратко) ожидает получения дополнительных данных.

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

Используя драйвер Python DataStax и сохраняя два клиента раздельными (то есть им не нужно знать или взаимодействовать друг с другом), как я могу ограничить запись со второго клиента так, чтобы он максимизировал пропускную способность записи при условии отсутствия влияния пропускная способность записи первого клиента?

Answer 1

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

Чтобы выполнить требование, чтобы объемные данные с низким приоритетом не мешали оперативным данным с высоким приоритетом, я заставил производителя данных с низким приоритетом проверить длину очереди, а затем добавить запись в очередь, только если длина очереди ниже подходящего порога (в моем случае 5 сообщений).

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

Я также разделил объемные данные на множество небольших сообщений, чтобы потребитель относительно быстро их обрабатывал.

У этого подхода есть три недостатка:

1. Нет никакой информации о том, сколько сообщений в очереди имеет низкий приоритет, а сколько - с высоким приоритетом. Однако мы знаем, что не может быть более 5 сообщений с низким приоритетом.
2. Производитель сообщений с низким приоритетом должен опросить очередь, чтобы получить текущую длину, что создает небольшую дополнительную нагрузку на сервер очереди.
3. Порог не применяется строго потому, что между двумя производителями идет гонка от проверки длины очереди до постановки в очередь сообщения. Это несерьезно, потому что производитель с низким приоритетом ставит в очередь только одно сообщение, когда проигрывает гонку и в следующий раз узнает, что очередь слишком длинная и ждет.