В продолжение предыдущих трех статей о реальном коде программной торговли:
Хардкорные галантерейные товары - подробности и мысли по автоматизированной торговле количественными торговыми системами в реальном времени (1. Проблемы и трудности)
Количественная торговая система - автоматизированная информация и мысли о твердом предложении (2. Цель твердого предложения)
Количественная торговая система - Подробности и мысли об автоматизированных реальных предложениях (3. Навыки обработки)
Здесь мы продолжим говорить о мультистратегической торговой системе и рыночном центре в общей структуре реального кода предложения.
Предисловие
В торговой индустрии, особенно в сфере фьючерсных контрактов, время от времени появляются несколько мастеров торговли с высоким кредитным плечом, и основная сумма в 100 000 юаней может легко превратиться в десятки миллионов. Однако почти все эти люди были подобны метеорам, проносящимся по ночному небу. После короткого ослепительного мгновения они бесшумно исчезли.
С другой стороны, другая группа трейдеров-ветеранов, которые уже давно занимаются бизнесом, целыми днями покорно говорят о непознаваемом будущем, боятся рынка и черных лебедей, которые могут прийти в любой момент. очень низкое кредитное плечо для открытия позиций и попыток совершить ошибку. Направление похоже на траву на стене, раскачивающуюся влево и вправо, без решимости и смелости мастера. Но по какой-то причине эта группа людей проявляет активность на рынке. Хотя кредитное плечо невелико, их позиции не малы.
В человеческом мире торгового мира звезды найти легко, а именинников найти трудно.
Как выживший количественный трейдер, я считаю, что одним из наиболее важных моментов в трейдинге является осознание необходимости использования нескольких стратегий. В субъективной торговле по-прежнему сложно реализовать мультистратегию, поскольку рабочая сила ограничена (если только она не нанимает нескольких трейдеров, как организация), а рынок работает 24 часа в сутки, 7 дней в неделю, и легко пропустить точки входа. Однако программную торговлю относительно легко реализовать. Программирование теряет способность человеческого мозга и глаз распознавать закономерности ценовых тенденций, но оно имеет более сильную исполнительную силу и более сильную способность копировать стратегии и распределять позиции, что имеет свои преимущества и недостатки.
Благодаря множеству целей, множеству стратегий и множеству параметров позиции капитала естественным образом рассредоточены. Больше не существует захватывающего открытия и закрытия отдельной прибыли или убытка, а является стремление к максимальному сглаживанию кривой капитала.
Обзор
На рисунке ниже представлена общая схема архитектуры набора моего реального кода.

Вся архитектура разделена на две части. Один из них — независимый рыночный центр, а другой — торговая программа, отвечающая за реализацию логики стратегии.
Обычно я запускаю программу с одной учетной записью, а их параметры политики и ключи учетной записи различаются файлами конфигурации, так что код можно полностью использовать совместно, а версией кода легче управлять. Некоторые параметры стратегии могут немного отличаться, в основном для того, чтобы чередовать определенные операции, чтобы они не выполнялись внезапно одновременно.
Раньше, когда стратегий было мало, я запускал программу на Python с каждой подстратегией, но на более позднем этапе обнаружил, что памяти сервера недостаточно. Потому что одна программа на Python занимает около 60 МБ памяти. Если стратегий больше и они копируются в несколько учетных записей, она быстро займет много памяти. Хотя вы можете заплатить больше за более мощный сервер, им также сложно управлять и обслуживать. В итоге его изменили на то, что есть сейчас. На основе аккаунтов схожие стратегии на разных валютах (несколько валют и несколько параметров) группируются в одну группу, а затем группа стратегий представляет собой Python-приложение. После запуска я почувствовал, что эта комбинированная модель очень хороша для размещения нескольких учетных записей и нескольких стратегий. Она очень удобна для управления кодом, а также для работы и обслуживания в режиме реального времени.
Преимущество одной подстратегии для одного приложения Python заключается в том, что код может быть намного проще. Однако только представьте, если ваша стратегия запускается на 40 крупнейших монетах, а затем каждая монета запускает 3 разные стратегии, то это будет 120 подстратегий. Если вы добавите еще три учетных записи, это будет 360 подстратегий. стратегии. Эта модель была бы неустойчивой.
Когда приложений мало, вы можете сначала использовать терминал, например tmux, для вывода информации журнала в режиме реального времени, что очень удобно для мониторинга на ранних этапах работы программы. После того, как код станет стабильным в более поздний период, для управления будет использоваться программное обеспечение для эксплуатации и обслуживания, такое как pm2. Просто регулярно анализируйте файл журнала в будущем.
В случае нескольких целей и нескольких стратегий стандартным должен быть независимый рыночный центр. Полученная различная рыночная информация может использоваться несколькими торговыми программами, то есть стратегическими модулями в левой части изображения выше.
Центр котировок
На рисунке ниже представлено более детальное изображение модуля рыночного центра.

Прежде всего, вы можете установить символы k-линии, которые будут получаться через файл конфигурации, чтобы в дальнейшем было проще изменить тип.
Если она многопериодная, то вы можете получить их общий делитель периода k-линии, а затем каждая стратегия может выполнить повторную выборку в соответствии со своими потребностями.
Если вы хотите раз и навсегда упростить ситуацию, то лучше всего напрямую получить 15-минутную К-линию, потому что средне- и низкочастотные стратегии, особенно следование тренду, с циклом менее 15 минут, по сути, являются сложно заработать деньги в долгосрочной перспективе.
Например, если у вас есть 15-минутная, 1-часовая или 4-часовая стратегия, то рыночному центру достаточно получить только 15-минутную К-линию. Если длины k-строк большого периода после передискретизации недостаточно, то вам придется сохранить в базе данных еще k-строк по 15 минут во время запуска.
Поскольку веб-сокет передает только самую последнюю обновленную информацию о k-строке, если ваша стратегия использует относительно большой цикл k-строки и длительное время анализа, например 4 часа ma150, тогда это будет 600 часов (25 дней) данных, 15 Если требуется одна k строк в минуту, необходимо 2400. Это зависит от однократного приобретения и сохранения через rest API при запуске маркет-центра в качестве основы для последующих непрерывных обновлений.
Я разделил весь рыночный центр на два приложения. На самом деле, его также можно объединить в одно приложение, но удобнее их разделить. Давайте сначала поговорим о вторичном плане Б.
План B
Как упоминалось в нескольких предыдущих статьях, это делается главным образом для предотвращения отключения веб-сокета PlanA. Он используется в качестве временной резервной копии, особенно в момент выхода из стратегии, чтобы избежать разворота цены на определенное расстояние и выхода. позиция не была закрыта, что привело к более неожиданным потерям.
PlanB очень прост. Он в основном использует функцию public_get_ticker_price для одновременного получения последних цен всех бессрочных контрактов. Это также последняя информация о ценах, собранная самим Би Аном.
В настоящее время у B'an более 200 бессрочных контрактов. Если мы получим последние цены один за другим, мы должны гарантировать, что цена каждого продукта обновляется каждые 3 секунды. API будет вызываться более 4000 раз в минуту. который должен превышать лимит № возможно. Однако вес API упомянутой ранее функции составляет всего 2. Если она используется раз в 3 секунды, она будет потреблять только 40 квот API в минуту. Не нужно беспокоиться о превышении квоты.
После моего теста Binance в основном агрегирует цены всех контрактов примерно раз в 1-2 секунды, поэтому для резервной цены средне- и низкочастотных стратегий вполне достаточно задержки около 5 секунд.
Если у вас невысокие требования, вы даже можете использовать его для синтеза черновых K-линий для всех контрактов, полностью избегая использования вебсокета. Даже если этот вид K-линии нельзя использовать для торговли, его также можно использовать для сканирования всей рыночной информации, а затем предоставления точек входа для субъективных трейдеров на основе их собственных разработанных алгоритмов стратегии, таких как расхождение и схождение скользящих средних. простое распознавание образов и т. д. Сигнал. Иначе как можно увидеть столько монет? Если у вас есть хороший дневной трейдер, этот инструмент может оказаться полезным для помощи в торговле. Раньше я писал подобные инструменты для других. Это действительно хорошо, когда рынок хороший, но в последнее время рынок не был хорошим.
Конечно, это решение имеет практическое применение только при торговле большим количеством монет. В противном случае лучше напрямую получить цену гандикапного BBO для каждой разновидности.
Также обратите внимание, что резервная информация о цене должна часто использоваться в основном коде. Например, она используется для расчета суммы фиатных средств, соответствующих позиции, и приблизительного соотношения прибылей и убытков, что не требует очень точных данных. Потому что фрагменты кода и информация, которые не часто используются, возможно, уже давно вышли из строя, и вы можете даже не узнать об этом, пока они не будут использованы. Любой, кто написал много кода, знает, что такой код приложения можно легко случайно изменить, даже не осознавая этого.
План А
Основной код рыночного центра. Это приложение имеет 4 основные функции.
Получите исторические базовые свечи. Как упоминалось ранее в статье, каждый раз, когда вы начинаете, вы должны убедиться, что присутствуют все линии K, необходимые для всех стратегий.
управление веб-сокетами. Этот модуль немного сложнее и должен обрабатывать различные ситуации отключения, повторного подключения и т. д. Каждый раз, когда биржа отправляет новые данные k-линии, данные последнего бара k-линии в базе данных обновляются.
В дополнение к данным K-line я также размещаю обновления информации о точности каждого сорта в рыночном центре. То есть функция public_get_exchangeinfo получает различные цены заказов и минимальную точность количества заказов, а затем преобразует их в удобный тип словаря. Таким образом, все стратегии могут быть общими.
Последний шаг — проверка, достаточно простой проверки работоспособности. Проверяйте, являются ли полученные К-линии непрерывными и нет ли пропусков, а затем регулярно сравнивайте их одну за другой с К-линиями, полученными остальными API, не слишком ли велик ценовой разрыв с ценой, полученной PlanB и т.д. Короче говоря, это всего лишь вопрос сравнения и проверки, чтобы ошибки можно было обнаружить на ранней стадии.
Вероятно, это основная структура моего рынка средне- и низкочастотных стратегий. При необходимости информацию об обновлении учетной записи также можно получить через веб-сокет. Но это немного более хлопотно и большую часть времени не будет использоваться.