Продовжуючи попередні три статті про реальний код програмної торгівлі:
Складні сухі товари - деталі та думки щодо автоматизованої торгівлі в реальному часі кількісних торгових систем (1. Проблеми та труднощі)
Система кількісної торгівлі - Автоматизована інформація про пропозицію фірми та думки (2. Мета пропозиції фірми)
Система кількісної торгівлі - Автоматизовані деталі реальної пропозиції та думки (3. Навички обробки)
Тут ми продовжимо говорити про багатостратегічну торгову систему та ринковий центр у загальній структурі реального коду пропозиції.
Передмова
У торговельній індустрії, особливо ф’ючерсних контрактів, час від часу з’являтимуться кілька майстрів трейдингу з високим кредитним плечем, і основна сума в 100 000 юанів може легко перетворитися на десятки мільйонів. Однак майже всі ці люди були схожі на метеори, що летіли по нічному небу, сліпучи на короткий проміжок часу, а потім безшумно зникали.
З іншого боку, інша група трейдерів-ветеранів, які ведуть бізнес протягом тривалого часу, цілими днями покірно говорять про невідоме майбутнє, боячись ринку та чорних лебедів, які приходять у будь-який час дуже низький рівень кредитного плеча для відкриття позицій і спроб робити помилки - це як трава на стіні, коливання вліво і вправо, без рішучості та сміливості майстра. Але чомусь ця група людей була активною на ринку. Незважаючи на те, що кредитне плече невисоке, їхні позиції не маленькі.
У людській природі торговельного світу зірки знайти легко, але зірок на день народження важко знайти.
Як кількісний трейдер, який вижив, я вважаю, що одним із найважливіших моментів у торгівлі є усвідомлення необхідності використання кількох стратегій. Все ще важко реалізувати мультистратегію в суб’єктивній торгівлі, оскільки робоча сила обмежена (якщо тільки не наймається кілька трейдерів, як установа), а ринок працює 24/7, і легко пропустити точки входу. Однак програмну торгівлю відносно легко реалізувати. Програмування втрачає здатність людського мозку та очей визначати моделі цінових тенденцій, але воно має сильнішу силу виконання та сильнішу здатність копіювати стратегії та розподіляти позиції, що має переваги та недоліки.
З кількома цілями, декількома стратегіями та декількома параметрами позиції капіталу природно розподіляються. Більше немає захоплюючого відкриття та закриття окремого прибутку чи збитку, а прагнення максимально згладити криву капіталу.
Огляд
На зображенні нижче зображено загальну діаграму архітектури набору мого реального коду.
Вся архітектура розділена на дві частини. Один — незалежний ринковий центр, а інший — торгова програма, відповідальна за реалізацію логіки стратегії.
Зазвичай я запускаю програму з одним обліковим записом, і їхні параметри політики та ключі облікових записів розрізняються конфігураційними файлами, щоб можна було повністю поділитися кодом і легше керувати версією коду. Деякі параметри стратегії можуть дещо відрізнятися, головним чином для розподілу певних операцій, щоб вони раптово не запускалися одночасно.
Коли раніше було мало стратегій, я запускав програму на Python з кожною підстратегією, але пізніше виявив, що пам’яті сервера недостатньо. Оскільки одна лише програма на Python займає близько 60 МБ пам’яті, якщо є більше стратегій і вони скопійовані в кілька облікових записів, вона швидко займе багато пам’яті. Хоча ви можете заплатити більше, щоб отримати більш потужний сервер, керування та обслуговування буде неприємним. Зрештою його змінили на те, що є зараз. На основі облікових записів схожі стратегії на різних валютах (кілька валют і кілька параметрів) згруповані в одну групу, а потім група стратегій є програмою Python. Після запуску я вважаю, що ця комбінована модель дуже хороша для компонування кількох облікових записів і кількох стратегій. Вона дуже зручна для керування кодом, а також роботи та обслуговування в реальному часі.
Перевага однієї підстратегії для однієї програми Python полягає в тому, що код може бути набагато простішим. Однак уявіть собі, якщо ваша стратегія працює на 40 основних монетах, а потім запускає 3 різні стратегії на кожній монеті, то це буде 120 підстратегій, якщо ви додасте ще три облікові записи, це буде 360 під-стратегій. стратегії. Ця модель була б нежиттєздатною.
Коли додатків мало, ви можете спочатку використовувати термінал, наприклад tmux, для виведення інформації журналу в реальному часі, що дуже зручно для моніторингу на ранніх етапах роботи програми. Після того, як код стане стабільним протягом наступного періоду, для керування використовуватиметься програмне забезпечення для експлуатації та обслуговування, наприклад pm2. Просто аналізуйте файл журналу регулярно в майбутньому.
У випадку кількох цілей і кількох стратегій незалежний ринковий центр має бути стандартним. Різноманітну отриману ринкову інформацію можна обмінювати між декількома торговими програмами, тобто модулями стратегії в лівій частині зображення вище.
Цитатний центр
На малюнку нижче показано більш детальне зображення модуля торгового центру.
Перш за все, ви можете встановити символи k-рядків, які будуть отримані через файл конфігурації, щоб було легше змінити тип у майбутньому.
Якщо він багатоперіодний, то ви можете отримати K-лінію періоду спільного дільника, а потім кожна стратегія може повторно виконувати вибірку відповідно до власних потреб.
Якщо ви хочете раз і назавжди спростити речі, то найкраще безпосередньо отримати 15-хвилинну K-лінію, тому що середньо- та низькочастотні стратегії, особливо слідування тренду, з циклом менше 15 хвилин, в основному важко заробити гроші в довгостроковій перспективі.
Наприклад, якщо у вас є 15-хвилинна, 1-годинна або 4-годинна стратегія, тоді ринковий центр повинен отримати лише 15-хвилинну К-лінію. Якщо довжини k-рядка великого періоду після повторної вибірки недостатньо, тоді вам доведеться зберегти більше k-рядків 15 хвилин у базі даних під час запуску.
Оскільки websocket надсилає лише останню оновлену інформацію k-line, якщо ваша стратегія використовує відносно великий цикл k-line та тривалий час огляду, наприклад 4 години ma150, тоді це буде 600 годин (25 днів) даних, 15 Якщо потрібно один k рядків на хвилину, потрібно 2400. Це залежить від одноразового отримання та збереження через решту API під час запуску Market Center, як основи для наступних безперервних оновлень.
Я розділив весь торговий центр на два додатки. Насправді його також можна об’єднати в одну програму, але надійніше розділити їх. Давайте спочатку поговоримо про вторинний план Б.
План Б
Як згадувалося в кількох попередніх статтях, це в основному для того, щоб запобігти відключенню веб-сокета PlanA. Він використовується як тимчасова резервна копія, особливо в момент виходу зі стратегії, щоб уникнути того, що ціна вже змінилася на певну відстань і вийшла. не було виходу з позиції.
PlanB дуже простий. Він в основному використовує функцію public_get_ticker_price для отримання останніх цін усіх безстрокових контрактів одночасно. Це також остання інформація про ціни, яку зібрав сам Бі Ан.
Наразі B'an має понад 200 безстрокових контрактів, ми повинні забезпечити оновлення ціни кожного продукту кожні 3 секунди. яка повинна перевищувати ліміт можливого. Однак вага api функції, згаданої раніше, становить лише 2. Якщо її використовувати раз на 3 секунди, вона споживатиме лише 40 квот api за хвилину. Не потрібно турбуватися про перевищення квоти.
Після мого тесту в основному Binance агрегує ціни всіх контрактів приблизно за 1-2 секунди, тому для резервної ціни середньо- та низькочастотних стратегій цілком достатньо затримки приблизно в 5 секунд.
Якщо ваші вимоги невисокі, ви навіть можете використовувати його для синтезу приблизних K-ліній для всіх контрактів, повністю уникаючи використання websocket. Навіть якщо цей тип К-лінії не можна використовувати для торгівлі, його також можна використовувати для сканування всієї ринкової інформації, а потім надання точок входу для суб’єктивних трейдерів на основі їх власно розроблених алгоритмів стратегії, таких як розбіжність і конвергенція ковзного середнього, просте розпізнавання образів тощо Сигнал. Інакше як можна побачити стільки монет? Якщо у вас є хороший денний трейдер, цей інструмент може бути корисним для допомоги в торгівлі. Я вже писав подібні інструменти для інших. Це дійсно добре, коли ринок хороший, але останнім часом ринок був поганим.
Звичайно, це рішення має практичну користь лише при торгівлі великою кількістю монет. В іншому випадку краще безпосередньо отримати гандикапну ціну BBO кожного сорту.
Також зауважте, що резервну інформацію про ціну потрібно часто використовувати в основному коді, наприклад, вона використовується для розрахунку суми фіатних коштів, що відповідає позиції, і приблизного прибутку та збитку, для чого не потрібні дуже точні дані. Тому що фрагменти коду та інформація, які не часто використовуються, можуть давно вийти з ладу, і ви можете навіть не знати про це, поки їх не використаєте. Кожен, хто писав багато коду, знає, що такий код додатка можна легко випадково змінити, не усвідомлюючи цього.
План А
Основний код ринкового центру. Ця програма має 4 основні функції.
Отримайте історичні базові свічники. Як згадувалося раніше в цій статті, кожного разу, коли ви починаєте, ви повинні переконатися, що кожен рядок K, який вимагається для всіх стратегій, присутній.
керування веб-сокетами. Цей модуль трохи складніший і потребує обробки різних ситуацій відключення, повторного підключення тощо. Щоразу, коли обмін надсилає нові дані k-лінії, дані останнього стовпчика k-лінії в базі даних оновлюються.
На додаток до даних K-line, я також розміщую оновлення інформації про точність кожного сорту в ринковому центрі. Тобто функція public_get_exchangeinfo отримує різні ціни замовлення та мінімальну точність кількості замовлення, а потім перетворює їх у зручний тип словника. Таким чином можна поділитися всіма стратегіями.
Останній крок — перевірка, достатньо простої перевірки здоров’я. Перевірте, чи отримані K-лінії безперервні та чи немає пропусків, а потім регулярно порівнюйте їх одну за одною з K-лініями, отриманими рештою api, чи є розрив у ціні з ціною, отриманою PlanB, занадто великим тощо. Коротше кажучи, це лише питання порівняння та перевірки, щоб помилки можна було виявити на ранніх стадіях.
Це, напевно, основна структура мого ринку стратегій середньої та низької частоти. За потреби інформацію про оновлення облікового запису також можна отримати через websocket. Але це трохи більше клопоту і не буде використовуватися більшу частину часу.