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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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