Как я вижу:
1.Разветвление тем на основе имени сценария
PROS
- Полный контроль отдельных заполнителей .Вы можете установить разные параметры репликации, постоянства, номера раздела для каждого из ваших источников.
- Простые проверки здоровья .Вы можете легко проверить, получает ли источник (например, Citigroup ) больше входящих данных, чем другие, или удалить данные из определенного источника, который влияет на процесс, и т. Д.
- Независимая шкала .Что касается предыдущего пункта, если у вас есть разные темы для каждого источника, это поможет в вопросах масштабирования.При втором подходе вы привязаны к количеству разделов только одной темы, чтобы масштабировать своих потребителей (и, возможно, вы только что достигли этого максимального числа потребителей).С этим первым подходом вы создаете разные темы (и, следовательно, разные разделы), позволяя запускать потребителей в тех местах (темах), в которых вы нуждаетесь, или увеличивать количество разделов отдельной темы.
CONS
- Множество тем, которые могут привести к большой репликации, постоянству, контролю смещения и т. Д .: больше работа для брокера ...
- ... и для сопровождающего.:)
2.Хранение всех тиковых данных в одной теме и разделение их по имени скрипта с помощью CustomPartitioner
PROS
- Меньше насыщенности брокера / сопровождающего .Все данные по теме, в которой вы "только" должны контролировать разделение.
- Запуск разных групп потребителей в одной теме - это нормально.В любом случае, у вас есть два варианта:
- Запускать разные CG для всех разделов : каждый работник должен проверить ключ сообщения и сбросить его, если это не его «источник».Это действительно быстро и не должно вызывать такой большой задержки.
- Забудьте о CG : если вы разбиваете разделы на основе источника, вы можете отправлять определенных работников в определенные разделы через назначить .Таким образом, даже если все данные находятся в одной теме, они будут эффективно разделены внутри разделов, поэтому ваши потребители ничего не откажутся.Помните, что вы можете иметь только одного потребителя на раздел, даже если метод assign не работает с правилами подписки, поскольку даже если можно назначить один и тот же раздел двум разным потокам, все данные в этом разделе будут обрабатываться дважды.
CONS
Может быть проще в обслуживании (из аппаратного обеспечения /ресурсов), но гораздо сложнее правильно разработать .
Ваш разделитель должен постоянно обновляться (если появляется новый источник, если номер раздела увеличивается, ...), и это может стать утомительной ручной задачей.
Забудьте о различном управлении источниками : все ваши входящие данные, независимо от источника, будут иметь одинаковые параметры темы, например, retention время;У вас не будет возможности сохранить некоторые источники в большей степени, чем другие, или (легко) распределить их в большем количестве разделов и т. Д.
Меньшие, более легкие источники будутзатронуты более крупные источники , так как все данные обрабатываются в одной и той же теме.Если вы запускаете группы потребителей, потребителям с «маленьким» источником придется отказаться от гораздо большего количества сообщений, чтобы получить доступ к своим собственным сообщениям.С другой стороны, , если вы не запускаете группы потребителей и assign потребителей вручную, вам нужно вручную увеличить количество разделов темы, назначая новыебольшие источники.Это будет включать постоянные изменения в вашем разделителе и в назначении ваших потребителей.
В любом случае, если у вас есть контроль над исходными сценариями, вы можете избавиться от второй темы / тем, поскольку вы можете создать ту же логику в исходной теме и избежать перемещения данных (, что, я считаю,не преобразуется, просто перемещается из одного места в другое ) из исходной темы в конечную тему.Это более заметно при втором подходе ( почему бы не разделить по первой теме ?)
Надеюсь, это поможет, некоторые из них являются полностью субъективными.:)