Архитектура одного производителя и нескольких потребителей в получении рыночных данных от фондовой биржи - PullRequest
Новая
       28

Архитектура одного производителя и нескольких потребителей в получении рыночных данных от фондовой биржи

0 голосов
/ 13 мая 2019

У меня есть сценарий, в котором мне нужно использовать одного производителя (фондовую биржу), который предоставляет рыночные данные. Каждое сообщение рыночных данных содержит («символ», «цена» и «отметка времени»).

Между тем, у меня есть 3 потребителя (сервера), и каждый из них будет потреблять рыночные данные с определенным «символом». Например, потребитель a будет потреблять только рыночные данные, которые имеют символ «AAPL», «AMZN», потребитель B будет потребителем, который имеет символ «GOOS» и т. Д.

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

Существует еще одно требование, согласно которому потребители могут время от времени менять свои предпочтения. Как потребитель А может начать потреблять сообщение с символом «GOOS».

Как мне спроектировать эту архитектуру? Я знаю, что мне, возможно, придется воспользоваться Kafka MQ, но я не эксперт в этом. Может ли кто-нибудь рассказать, каким будет дизайн?

1 Ответ

2 голосов
/ 13 мая 2019

Ваш дизайн может содержать следующие компоненты :

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

Уровень обмена сообщениями : это будет ваш кластер Kafka (несколько брокеров, скажем, 3 для включения репликации).В этом кластере Kafka вам нужно создать тему (скажем, raw-market-data) с несколькими разделами.Например, если у вас есть всего 300 символов, вы можете создать 100 разделов (с номерами от 0 до 299), каждый из которых заканчивается 3 символами.

Уровень потребления : Здесь будут работать ваши потребители.Вы уже упоминали, что у вас будет 3 экземпляра этого потребителя.

Другие соображения дизайна :

Стратегия разбиения :

  • Производитель Kafka, работающий на уровне сбора данных, может структурировать сообщение как {7, { "stockSymbol": "AAPL", "marketPrice": 57.10, "timestamp": "May 13th, 10:03:18 AM "} }.Цифра 7 в начале сообщения, т. Е. Ключ сообщения, указывающий, на какой раздел следует перейти это сообщение.Вам нужно написать логику внутри производителя, которая отображает конкретный символ акции на выделенный раздел.

  • Другой вариант может состоять в структурировании сообщения как {"AAPL", { "stockSymbol": "AAPL", "marketPrice": 57.10, "timestamp": "May 13th, 10:03:18 AM "} }.Вы явно нажимаете символ акции в ключе сообщения, и тогда разделитель Kafka по умолчанию подключается и вычисляет хеш строки AAPL и выполняет модуль по количеству разделов.В результате этого вычисления будет определен раздел, в котором будет находиться это сообщение. У этой опции есть предостережение, что распределение символов по разделам не всегда может быть равномерным.Вот ссылка на фактический исходный код разделителя по умолчанию , если вы хотите изучить его самостоятельно.

  • Третий вариант - написать собственный настраиваемый разделитель,Вот справочная статья с примером .

  • Фактическое количество разделов будет зависеть от различных других факторов, таких как общая пропускная способность, количество брокеров, количество пользовательских экземпляров.т. е. единицы параллелизма и т. д.

Стратегия потребления :

  • Как правило, экземплярам-получателям автоматически назначаются разделыКафка - назначение по умолчанию выполняется с помощью RangeAssignor.Например, если у вас есть 8 разделов (пронумерованных от 0 до 7) и 3 потребителя (c1, c2 и c3), то Kafka назначит разделы {0, 1, 2} на c1, {3, 4, 5} на c2 и {6, 7} до c3.Вы можете либо назначить определенные разделы конкретному потребителю, буквально вызвав метод assign(), либо написать свой собственный присваиватель, реализовав этот интерфейс .

  • По вашему требованию дляупорядочение сообщений в соответствии с отметкой времени.Это то, что Кафка не может гарантировать.Сообщения будут перенесены в тему в том порядке, в котором они поступили, поэтому, если есть 2 сообщения с отметками времени t1 и t2 с t1 < t2 и по какой-то причине сначала приходит сообщение с отметкой t2, то это будетпотребляется до сообщения с отметкой времени t1.Поэтому вам придется иметь дело с этим в своем экземпляре пользовательского приложения - в прошлом я использовал TreeMap структуру данных с timestamp в качестве ключа для достижения этой цели.

  • По требованию об изменении предпочтений потребления - может быть лучше, если вы реализуете свой собственный присваиватель разделов (упомянутый в пункте 1 стратегии потребления), который позволит вам справиться с этим, поскольку это очень специфическое требование.

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

Надеюсь, это поможет!

...