Proqramlaşdırılmış ticarət üçün real vaxtın diqqət məsələləri haqqında əvvəlki iki məqaləyə baxın:

Sərt material - Kəmiyyət ticarət sisteminin avtomatlaşdırılmış real vaxt detal və düşüncə (I Problemlər və çətinliklər)

Kəmiyyət ticarət sistemi - Avtomatlaşdırılmış real vaxt detal və düşüncə (II Real vaxt məqsədi)

Burada kod dizaynı ilə bağlı bəzi detal işlənmələri haqqında daha çox danışaq.

Veritabanı

Öncəki iki məqalədə qeyd edildiyi kimi, mürəkkəb bir strategiya birləşməsinin vəziyyət qeydi çox vacibdir, buna görə də veritabanı istifadə edilməlidir.

Əslində, əksər proqramlaşdırma işləri CRUD kateqoriyasına aid edilə bilər, yəni əsas proses veritabanının əlavə edilməsi, silinməsi, dəyişdirilməsi və axtarılmasıdır. Ticarət kodu da istisna deyil. Orta və aşağı tezlikli ikinci dərəcəli bazar ticarət davranışı, əslində, insanların bir alış-veriş platformasında alış-veriş etməsindən çox fərqlənmir, hər ikisi də alqı-satqıdır. Avtomatlaşdırılmış ticarətin həyata keçirilməsinin əsas məqamı strategiya vəziyyətinin idarə edilməsindədir.

Əgər SQL kimi əlaqəli verilənlər bazası ilə artıq tanış deyilsinizsə, Redis kimi NoSQL yaddaş bazasını öyrənməyi tövsiyə edirəm. Bunun üstünlüyü, istifadəsinin asan olması, yüksək performansı, doğuştan tək iplik olmasıdır, buna görə də oxumaq/yazmaq zamanı verilənlərin kilidini bağlamaq kimi aşağı səviyyəli əməliyyatları düşünməyə ehtiyac yoxdur. Ancaq çatışmazlığı, əsas açarın olmaması, avtomatik nömrələmənin və ya artırmanın mümkün olmamasıdır. Lazım olarsa, öz kodunuzu yazmalısınız. Ancaq bu funksiyanı, mən özüm avtomatik ticarətlə məşğul olduğum zaman bir çox istifadə etmirəm.

Başqa bir əhəmiyyətsiz məsələ isə, yaddaş bazasıdır, əgər saxlanılacaq məlumat miqdarı çoxdursa, serverin yaddaşı bir az daha böyük olmalıdır, amma adətən kvant ticarətinin real ticarəti üçün 4G, hətta 2G yaddaş kifayətdir, bu qədər məlumatı saxlamağa ehtiyac yoxdur.

Redis-in real ticarətdəki funksiyası həqiqətən güclüdür, əgər strategiyanızın bir az yüksək tezlik tələbi varsa, o, eyni zamanda pub/sub mesaj abunə modeli həyata keçirə bilər, əlavə müxtəlif MQ modullarını daxil etməyə ehtiyac yoxdur. Əgər MySQL kimi əlaqəli verilənlər bazasından istifadə edirsinizsə, əvvəlcə qeyd etdiyimiz kimi, əgər əvvəlcədən real praktikada tanış olmasanız, o zaman çətin başa düşülən bir proqramlaşdırma dili olan SQL öyrənməyə yenidən zaman və enerji sərf etməlisiniz. Diqqət yetirin ki, hamı kvant ticarəti etməyə gəlir, kod yazmağı öyrənməyə deyil, mümkün qədər sadə bir həll yolu seçin.

Başqa bir tərəfdən, əgər bazar mərkəzi qurmaq istəyirsinizsə, performansı nəzərə alaraq, Redis verilənlər bazasını da istifadə etməli, mesaj sırası ilə birləşdirərək rahatlıq təmin etməlisiniz. Həll sadədir, əksər ssenarilərə uyğundur. Bir server (ya da bir neçəsi) istifadə oluna bilər.

Kod dizaynı

Əsasən, kod yazarkən, əsas məlumat strukturu ən vacibdir. Məlumat strukturu dizaynı yetərincə düzgün olmadıqda, kod necə yazılırsa, o qədər də qəribə olur, çünki bu, müxtəlif modullar arasında qaçınılmaz olaraq bağlılığa səbəb olur, dəyişdirmək isə çətindir. Ancaq düzgün dizayn etmək üçün bir az ticarət təcrübəsi olmalıdır, yəni biznes təcrübəsi. Bunlar kod yazmağın yollarıdır, bununla bağlı daha çox deməyə ehtiyac yoxdur. Hər kəsin strategiyası fərqlidir, eyni cür yanaşmaq olmaz. Ancaq bəzi prinsipial məsələlər bənzərdir.

Bir misal çəkək, sifariş təqdim edildikdən sonra, uğur qazanmağı təmin etmir, hətta bazar qiymətində olsa belə, çünki ticarət birjası tərəfindən rədd edilə bilər. Məsələn, ticarət birjası çox məşğuldur, ya da müvəqqəti şəbəkə məlumatı itir. Bunun üçün ən yaxşısı, iki mərhələli təqdimatı (2 Phase Commit) bənzər bir ara vəziyyət dizayn etməkdir, uğursuz olarsa, davamlı olaraq cəhd edin (təbii ki, çox tez-tez olmamalıdır, əks halda məhdudiyyətləri aşaraq qadağan edilə bilər, bunun üçün xüsusi retry dekoratoru var), ya da səhv vəziyyətlərini düzəltmək üçün bir neçə dəfə daha əlavə metodlar əlavə edin.

Adətən, ticarət birjası çöksə, qısa müddətdə bərpa olunur. Bərpa olunmazsa, o zaman bir tərəf tamamilə çökmüşdür, ya ticarət birjası, ya da sizin öz kod serveriniz. Bu məsələni yaxşı nəzarət altında saxlamaq lazımdır, xəbərdarlıq etməlidir. Avtomatik kod hər şeyi əhatə edə bilmir, həqiqətən avtomatik işləyə bilməzsə, xəbərdarlıq etməlidir, insan müdaxiləsi gərəkir. İnsan vaxtında müdaxilə etməzsə, yalnız açılış mövqelərini artırmadan davam edərsə, problem çox böyük olmayacaq, çünki hələ də algoritmik stop-loss sifarişi mövcuddur.

Aşağıda, özüm tərəfindən tərtib edilmiş bir strategiya açma məntiqi var:

Əsasən, oxşar bir axın sxemi çəkmək, kodu yazarkən daha sistematik olmağa kömək edəcək və mümkün olan xətaları azaldacaq. Buna görə, kod yazmazdan əvvəl, ən yaxşısı əvvəlcə axın sxemi çəkməkdir, ya da yazarkən düzəltməkdir, beləliklə, məntiqi aydın olacaq, başa düşəcəksiniz.

Bağlama məntiqi bununla müqayisədə daha mürəkkəbdir, çünki bağlanma şərtləri daha çoxdur, mənfəət və ziyan, müxtəlif strategiyaların çıxış siqnalları, hamısı bağlanmaya səbəb ola bilər. Ümumiyyətlə, çıxışın əhəmiyyəti daxil olmadan daha yüksəkdir, real ticarətdə də bir az çətindir.

Çünki hər kəsin strategiya məntiqi fərqli olmalıdır, burada daha çox danışmayacağam. Əsasən, strategiyanızın məntiqini düzəldin, mümkün olan müxtəlif xətaların qarşısını alın.

Ancaq bunlar yalnız mürəkkəb görünür, amma sadəcə bir dəstə if else-dır (Python-da hətta switch bəyanatı da yoxdur). Şərtlərə uyğun gəldikdə, növbəti addıma keçin, uğursuz olarsa, çıxın, böyük bir problem yoxdur.

Zaman nəzarəti

Ticarət edərkən, vaxtın dəqiq tutulması şübhəsiz ki, çox vacibdir. Burada, mənim zaman nəzarət texnikalarımı bir daha paylaşmaq istəyirəm.

Adətən proqramlaşdırmada, əgər müəyyən vaxtda icra olunması lazım olan vəzifələr varsa, ümumiyyətlə, apscheduler kimi cron job paketləri istifadə edilir. Məsələn, planlaşdırılmış bir vaxtda k xətti qiymətini açıq pozma və ya bağlamaq üçün yoxlayacaq vəzifə.

Bu cür paket, əslində müəyyən edilmiş vaxtda (dəqiqliklə saniyə səviyyəsində) dərhal yeni bir iplik açaraq, müvafiq vəzifəni icra edir, problem isə bu vəzifənin icra müddəti çox uzun olarsa, növbəti vəzifə təkrarən başlayacaq, bu zaman problem yarana bilər, baxmayaraq ki, bu həll oluna bilər, amma bir az çətindir.

Mən adətən log məlumatlarını vaxtında çıxartmaq, proqramın özünü düzəltmək və yoxlamaq üçün belə bir vaxtlı vəzifələrdən istifadə edirəm, yəni bir az aşağı tezlikli və tez başa çatdırıla bilən funksiyalar. Bu funksiyalar verilənlər bazasındakı məlumatlara yalnız oxu, yazma, yeniləmə əməliyyatları deyil, buna görə də apscheduler-in başqa bir iplik açaraq işləməsi də ziyan verməz.

Ancaq bazar qiymətini və ya yerli strategiya vəziyyətini daima yüksək tezlikdə sorğulamağı tələb edən məntiq, bu cür vaxtlı paketlər üçün uyğun deyil, bunun əvəzinə while döngüsü istifadə etməlisiniz.

Məsələn, strategiya k xətti bar içi siqnallarını istifadə edirsə, bu, siqnalların istənilən vaxt ortaya çıxa biləcəyi deməkdir, buna görə də müvafiq əməliyyatları həyata keçirmək üçün davamlı olaraq hədəf qiymətini və ya ticarət həcmini yoxlamaq lazımdır. Əgər bu anda, yalnız k xətti başa çatmadan 10 saniyə əvvəl icra etmək üçün daha dəqiq zaman nəzarəti tələb edirsinizsə, o zaman son 10 saniyə olduğunu necə asanlıqla müəyyənləşdirə bilərsiniz?

Mən 3600-ə mod almaq üçün zaman damğasından istifadə edirəm.

(Əgər kompüterdə timestamp ilə tanış deyilsinizsə, yəni zaman damğası, o, 1970.1.1 tarixindən başlayaraq Greenwich standart vaxtından hesablanır, məsələn, indiki dövrdə təxminən 1691240298 saniyədir, kompüterdə dəqiqliklə mikro saniyə səviyyəsində də problem yoxdur.)

3600-ə mod almaqdan sonra, əgər qalıq 3590 saniyədən böyükdürsə, bu, son on saniyədir. Səhv mikro saniyə səviyyəsinə qədər ola bilər. Daha əvvəl qeyd etdiyimiz kimi, əsas ticarət əməliyyatlarının bir iplikdə, ardıcıl icra edilməsi daha yaxşıdır, beləliklə, icra vaxtını belə bir şəkildə təxminən tənzimləmək mümkün olacaq, ya da bir az qeyri-dəqiq, zaman aralığı, beləliklə, daha az problem olacaq.

Bu cür nəzarət, öz serverinizin vaxtının tənzimlənməsi ilə standart vaxt arasındakı fərqin çox olmaması kifayətdir. Ancaq bu cür nəzarət də çox dəqiq olmayacaq, yalnız saniyə səviyyəsinə qədərdir. Ancaq Python-da vaxtı dəqiq tənzimləmək mümkün deyil, o qədər dəqiq olan yuxarıdakı yuxuların mikro saniyə səviyyəsində səhvlərə səbəb olacağıdır.

API müraciət tezliyini azaldın

Əgər artıq websocket-ə əsaslanan müstəqil bazar mərkəzi istifadə olunursa, müxtəlif strategiyalar, hətta fərqli ticarət kodları arasında k xətti kimi bazar açıq məlumatlarını paylaşmaq mümkündür, bu halda API tezlik məhdudiyyətləri ilə bağlı narahatlıq olmayacaq.

Ancaq hesab məlumatlarını, yəni vəsait, mövcudluq, sifariş bu üç növ məlumatı vaxtında əldə etməyə ehtiyacımız var. Hesab məlumatlarını websocket vasitəsilə də əldə edə bilsəniz, ticarət birjası serverinin sizə göndərməsini gözləmək əvəzinə, üç səbəbə görə, birbaşa rest api istifadə etmək daha asan olacaq.

Birinci, websocket-dən istifadə edilən hesab məlumatları, ticarət birjaları yükü azaltmaq üçün müəyyən müddət keçdikdən sonra yenidən bağlanma və ya listenKey yeniləməsi tələb edir (Binance üçün bu 60 dəqiqədir). Bu vəziyyət açıq şəkildə daha çətin baxılır. Hətta çox çətin olmur, amma əgər API-nin idarəsi edilibsə, bir çox hesabla eyni anda ticarət edirsinizsə, o zaman məlumatların anında dəqiqliyini təmin etmək üçün ayrıca bir proqram açmalısınız, bu da məntiqi xeyli çətinləşdirir.

İkinci, bəzi ticarət birjalarında hesab məlumatlarının yenilənməsinin websocket göndərilməsi yoxdur, bu halda, ticarət məntiqi uyğun deyil, real ticarət kodu müxtəlif ticarət birjaları arasında keçid edərkən daha çətin olur. Əlbəttə ki, adi insanlar bir neçə ticarət birjasında ticarət etməzlər, buna görə də belə bir vəziyyətlə qarşılaşmazlar.

Üçüncü, əgər websocket bağlantısı kəsilirsə, ya da əvvəl qeyd olunan listenKey yeniləməsi, ya da müddət bitməsi kimi problemlərlə qarşılaşırsa, əgər proqram bunu vaxtında aşkar etməzsə və bu anda ticarət baş verirsə, yalnız websocket-ə etibar edərək, daha böyük problemlərə səbəb ola bilər, çünki qaçırılan hesab yeniləmə məlumatları bir daha göndərilməyəcək. Bu cür potensial problemlərin baş vermə ehtimalını azaltmaq üçün, dəqiq hesab məlumatlarını əldə etmək üçün rest api-yə etibar etməlisiniz. Beləliklə, sonunda, rest api-yə etibar etmək lazımdır, bu da üst-üstə düşməzmi?

Yuxarıda qeyd olunanlar, orta və aşağı tezlikli ticarət üçün, birbaşa rest api istifadə edərək hesab məlumatlarını əldə etmək daha yaxşıdır. Vacib məlumat mənbələri üçün, SSOT (Single Source Of Truth - etibarlı tək məlumat mənbəyi) prinsipini təqib etmək daha yaxşıdır, əks halda potensial qarışıqlığa səbəb ola bilər, bu anlayışa özünüz google edə bilərsiniz, məlumat işlənməsi proqramlaşdırmasında çox faydalıdır.

Beləliklə, yalnız rest api vasitəsilə hesab məlumatlarını əldə edirsinizsə, yerli kod yaddaşında müvəqqəti bir hesab məlumatları cədvəli saxlamaq mümkündür, xüsusilə istifadə ediləcək vəsait, beləliklə, ticarət birjasına tez-tez müraciət etməyi azaldır, əsas məsələ sürətli olmaqdır, sifarişləri birdən göndərə bilərsiniz, kütləvi sifariş verməyə bənzər, sonra ardıcıllıqla yavaş-yavaş yeniləmələri həyata keçirirsiniz, sifariş vermək sürətli olduqda, sürüşmə təbii ki, bir az daha az olur.

Başqa bir tərəfdən, algoritm riskini qiymətləndirmək üçün son dövrlərin yüksək aşağı qiymətlərini istifadə edə bilərsiniz, çünki birbaşa sifarişin vəziyyətini əldə etməyə çalışmayın, çünki sifarişin yerinə yetib-yetmədiyini qiymətləndirmək üçün davamlı olaraq sorğu vermək lazımdır, bu da çox tez-tez baş verir və bir çox effektiv olmayan API müraciətinə səbəb ola bilər. Ancaq websocket-in k xətti qiymətinin yenilənməsi çox vaxtında baş verir və API tezlik məhdudiyyətini tutmur.

Eynilə, bəzi çıxış sifarişləri də belə ola bilər. Əgər çıxış siqnalınız bar içindəki qiymətə bağlıdırsa, o zaman son dövrlərin yüksək aşağı qiymətlərini istifadə etmək daha yaxşı ola bilər. Çünki bəzən qiymət tetiklenir, sonra dərhal geri dönür, əgər yoxlama tezliyiniz o qədər də yüksək deyilsə, o zaman qaçırma ehtimalınız ola bilər. Ticarət strategiyasının ardıcıllığını təmin etmək üçün, yüksək aşağı qiymətləri yoxlamaq qaçırma ehtimalını azaltmaz. Bu cür işləməkdə əlavə üstünlük var, çünki faktiki yerinə yetirmə qiyməti həqiqi tetikleme qiymətinə nisbətən daha əlverişli ola bilər.

Yuxarıdakı iki məsələni anlamaq çətin olub-olmadığını bilmirəm. Bəlkə də bir az real ticarət təcrübəsi tələb olunur.

Öz real ticarət kodu inkişafımdan bir neçə fikri paylaşmaq istəyirəm, ümid edirəm ki, bu, hər kəsə faydalı olacaq.