Melanjutkan dua artikel sebelumnya mengenai hal-hal yang perlu diperhatikan dalam programmatic trading:

Barang kering hard-core - detail dan pemikiran tentang perdagangan real-time otomatis dari sistem perdagangan kuantitatif (1. Masalah dan kesulitan)

Sistem Perdagangan Kuantitatif - Detail dan Pemikiran Penawaran Perusahaan Otomatis (2. Tujuan Penawaran Perusahaan)

Di sini kita akan terus membicarakan beberapa keterampilan penanganan mendetail dalam desain kode.

basis data

Seperti disebutkan dalam dua artikel sebelumnya, catatan status kombinasi strategi yang lebih kompleks sangatlah penting dan memerlukan penggunaan database.

Faktanya, sebagian besar bisnis pemrograman dapat digolongkan ke dalam kategori CRUD, yaitu proses intinya hanya menambah, menghapus, mengubah, dan memeriksa database. Kode perdagangan tidak terkecuali. Perilaku perdagangan pasar sekunder frekuensi menengah dan rendah sebenarnya tidak jauh berbeda dengan ketika orang berbelanja harta karun tertentu, keduanya fokus pada perdagangan otomatis terletak pada pengelolaan status strategis.

Jika Anda belum terbiasa dengan database relasional seperti SQL, disarankan agar Anda langsung mempelajari cara menggunakan database dalam memori NoSQL seperti Redis. Keuntungannya adalah mudah untuk memulai, memiliki kinerja yang sangat baik, dan bersifat single-threaded. Tidak perlu mempertimbangkan operasi tingkat rendah seperti mengunci data saat membaca dan menulis. Namun kekurangannya adalah tidak adanya kunci utama dan fungsi seperti penambahan angka otomatis tidak dapat dilakukan. Jika perlu, Anda harus menulis kode untuk mengimplementasikannya sendiri. Namun, saya belum pernah menggunakan fungsi ini dalam perdagangan otomatis selama ini.

Masalah lain yang tidak penting adalah bahwa untuk database dalam memori, jika jumlah data yang perlu disimpan relatif besar, maka memori server harus lebih besar. Namun, untuk perdagangan kuantitatif umum, memori 4G atau bahkan 2G sudah cukup tidak diperlukan.

Redis sangat kuat di dunia nyata. Jika strategi Anda memiliki persyaratan frekuensi tinggi, Redis juga dapat menerapkan model berlangganan pesan pub/sub, sehingga menghilangkan kebutuhan untuk menambahkan berbagai modul MQ tambahan. Jika Anda menggunakan database relasional seperti MySQL, seperti yang disebutkan sebelumnya, selama Anda belum pernah menggunakannya dalam praktik sebelumnya, Anda harus menginvestasikan waktu dan energi untuk mempelajari SQL, bahasa pemrograman yang relatif menjijikkan dan sulit. Perhatikan bahwa semua orang di sini untuk melakukan perdagangan kuantitatif, bukan untuk belajar menulis kode.

Selain itu, jika Anda ingin membangun pusat pasar, dengan mempertimbangkan kinerjanya, Anda juga akan menggunakan database Redis dan bekerja sama dengan antrian pesan untuk kenyamanan. Solusinya sederhana dan cocok untuk sebagian besar skenario. Satu server (atau beberapa server) dapat digunakan.

desain kode

Pada dasarnya, ketika menulis kode, struktur data inti adalah yang paling penting. Desain struktur data tidak cukup masuk akal, dan kode akan ditulis dengan canggung, karena hal ini pasti akan menyebabkan berbagai modul digabungkan bersama, sehingga modifikasi menjadi sangat merepotkan. Namun untuk mendesainnya dengan benar, Anda memerlukan pengalaman trading, yaitu pengalaman bisnis. Ini semua tentang cara menulis kode, tidak banyak yang bisa dikatakan. Strategi setiap orang berbeda dan tidak dapat diperlakukan sama. Namun, beberapa prinsipnya mungkin sama.

Misalnya, setelah pesanan diajukan, tidak ada jaminan keberhasilan, meskipun itu pesanan pasar, karena bisa saja ditolak oleh bursa. Misalnya, pertukaran terlalu sibuk, atau terjadi kehilangan paket data jaringan sementara. Kemudian, yang terbaik adalah merancang beberapa status peralihan mirip dengan 2 Phase Commit. Jika gagal, teruslah mencoba (tentu saja jangan terlalu sering, jika tidak maka akan dibanned jika melebihi batas. Ada dekorator coba ulang khusus untuk melakukan ini) , atau tambahkan lebih banyak metode A untuk memperbaiki status kesalahan.

Dalam keadaan normal, meskipun bursa sedang turun, bursa akan pulih dalam waktu singkat. Jika tidak pulih, maka salah satu pihak akan down total, baik itu exchange atau server kode Anda sendiri. Hal ini perlu diwaspadai dan diwaspadai. Kode otomatis tidak mungkin mencakup semuanya. Jika tidak dapat diproses secara otomatis, diperlukan intervensi manual. Jika pemrosesan manual tidak ditangani tepat waktu, selama kita tidak terus membuka posisi untuk meningkatkan eksposur, masalahnya tidak akan terlalu besar, karena terdapat perintah stop-loss algoritmik untuk menutupi bagian bawah.

Berikut logika pembuka strategi yang saya urutkan sendiri:

Pada dasarnya, dengan menggambar diagram alur serupa, kode akan lebih terorganisir dan jumlah potensi bug akan berkurang. Oleh karena itu, sebelum menulis kode, yang terbaik adalah menggambar diagram alur atau memilah-milahnya saat menulis, sehingga logikanya jelas dan Anda memiliki gambaran.

Logika penutupan posisi jauh lebih rumit dari ini, karena terdapat lebih banyak kondisi untuk menutup posisi, seperti stop-profit, stop-loss, dan sinyal keluar dari berbagai strategi, yang akan memicu penutupan posisi. Singkatnya, pentingnya keluar lebih tinggi daripada masuk, dan tawaran sebenarnya juga sedikit lebih merepotkan.

Karena logika strategi setiap orang pasti berbeda-beda, saya tidak akan panjang lebar di sini. Yang utama adalah meluruskan logika strategis Anda dan mencegah terjadinya berbagai kemungkinan kesalahan.

Namun, ini terlihat rumit, dan hanya sekumpulan if else (Python bahkan tidak memiliki pernyataan switch). Jika syaratnya terpenuhi, lanjutkan ke langkah berikutnya. Jika tidak, keluar.

kontrol waktu

Dalam bertransaksi, timing tentu menjadi hal yang sangat penting. Di sini saya akan membagikan lebih banyak keterampilan kontrol waktu saya.

Dalam pemrograman umum, jika ada tugas yang perlu dieksekusi secara teratur, biasanya digunakan paket cron job seperti apscheduler. Misalnya, rencanakan tugas terjadwal untuk mendeteksi apakah harga garis K perlu membuka atau menutup posisi segera setelah waktunya tiba.

Paket semacam ini sebenarnya membuka thread baru segera pada waktu yang ditentukan (bisa akurat hingga level kedua), dan kemudian menjalankan tugas yang ditentukan. Masalahnya adalah jika waktu eksekusi tugas ini terlalu lama, maka tugas berikutnya akan dimulai lagi. Akan ada masalah. Meskipun bisa diselesaikan, masalah tersebut lebih merepotkan.

Saya biasanya menggunakan tugas terjadwal seperti itu ketika saya perlu mengeluarkan informasi log secara teratur dan melakukan koreksi mandiri dan pengujian mandiri program, yang merupakan fungsi frekuensi rendah yang dapat diselesaikan dengan cepat. Fungsi-fungsi ini hanya membaca data dalam database, dan tidak ada operasi tulis atau pembaruan, jadi tidak ada salahnya membiarkan apscheduler membuka thread lain untuk diproses.

Namun, logika yang memerlukan pertanyaan harga pasar atau status kebijakan lokal yang konstan dan sering tidak cocok untuk paket waktu seperti itu dan perlu dikendalikan oleh loop sementara.

Misalnya, jika strategi menggunakan sinyal di dalam bilah garis K, itu berarti sinyal dapat muncul kapan saja, dan Anda perlu terus-menerus memeriksa harga dasar atau volume perdagangan untuk menentukan apakah operasi terkait perlu dilakukan. Jika Anda memerlukan kontrol waktu yang lebih tepat saat ini, misalnya, jalankan logika rangkaian pembukaan posisi 10 detik sebelum akhir jam k-line saja. Jadi bagaimana Anda bisa menilai apakah ini 10 detik terakhir?

Saya mengambil sisa 3600 dengan menggunakan stempel waktu.

(Jika Anda belum familiar dengan stempel waktu di komputer, yaitu stempel waktu, dimulai dari Greenwich Mean Time 1970.1.1. Misalnya, sekitar 1691240298 detik. Tidak ada masalah dengan keakuratan komputer terhadap tingkat mikrodetik.)

Setelah mengambil sisa dari 3600, jika sisanya lebih besar dari 3590 detik, maka itu adalah sepuluh detik terakhir. Kesalahannya bisa sampai ke tingkat milidetik. Seperti disebutkan sebelumnya, yang terbaik adalah mengeksekusi operasi transaksi utama secara berurutan dalam satu thread. Dengan cara ini, waktu eksekusi dapat dikontrol secara kasar, atau periode waktu dapat dikaburkan, sehingga tidak ada masalah.

Kontrol semacam ini mengharuskan pengaturan waktu server Anda sendiri tidak terlalu menyimpang dari waktu standar. Namun pengendalian semacam ini tidak terlalu tepat, hanya bisa mencapai level kedua. Namun, Python tidak dapat mengontrol waktu dengan tepat, dan fungsi tidur tersebut akan menyebabkan kesalahan sekitar mikrodetik.

Kurangi frekuensi akses API

Jika Anda telah mengadopsi pusat pasar independen berdasarkan websocket untuk berbagi informasi publik pasar seperti garis K antara strategi yang berbeda atau bahkan kode perdagangan yang berbeda, maka tidak ada kekhawatiran tentang batasan frekuensi API dalam hal ini.

Namun kita juga perlu memperoleh informasi rekening secara tepat waktu, yaitu tiga jenis informasi: dana, posisi, dan pesanan. Meskipun informasi akun juga dapat menggunakan websocket dan menunggu server pertukaran untuk secara aktif mendorongnya, lebih mudah untuk langsung menggunakan api lainnya karena tiga alasan.

Pertama, untuk mengurangi beban informasi akun yang didorong oleh websocket, bursa mengharuskan bursa untuk menghubungkan kembali atau memperbarui ListenKey sesekali (Binance membutuhkan waktu 60 menit). Situasi ini jelas lebih sulit untuk dipertahankan. Meskipun tidak terlalu merepotkan, jika Anda melakukan hosting API dan memperdagangkan beberapa akun secara bersamaan, Anda harus mengaktifkan program terpisah untuk memastikan keakuratan informasi secara real-time, dan logikanya menjadi jauh lebih rumit.

Kedua, beberapa bursa tidak memiliki websocket push untuk pembaruan informasi akun. Dalam hal ini, logika perdagangan tidak bersifat universal, dan lebih merepotkan untuk mengganti kode perdagangan nyata di antara bursa yang berbeda. Tentu saja, kebanyakan orang tidak akan berdagang di banyak bursa dan tidak akan menghadapi situasi seperti itu.

Ketiga, jika link websocket rusak, atau mengalami masalah seperti update listeningKey atau kadaluwarsa yang disebutkan sebelumnya, jika program tidak menemukannya tepat waktu, dan kebetulan sedang ada transaksi saat ini, maka jika hanya mengandalkan websocket, itu akan menyebabkan masalah besar perbandingan, karena informasi pembaruan akun yang terlewat tidak akan didorong lagi. Untuk menghindari kemungkinan terjadinya masalah potensial seperti itu, Anda juga harus mengandalkan rest api untuk mendapatkan informasi akun tertentu. Jadi pada akhirnya harus mengandalkan rest api, bukankah itu tidak perlu?

Ringkasnya, untuk transaksi frekuensi menengah dan rendah, sebaiknya langsung menggunakan rest api untuk mendapatkan informasi akun. Untuk sumber data penting, yang terbaik adalah mengikuti SSOT (Single Source Of Truth), jika tidak maka dapat menimbulkan potensi kebingungan. Konsep ini dapat Anda cari di Google sendiri dan sangat berguna dalam pemrograman yang mengandalkan pemrosesan data.

Kemudian, jika Anda hanya menggunakan REST API untuk mendapatkan informasi akun, Anda dapat menyimpan tabel informasi akun sementara di memori kode lokal, terutama dana yang tersedia. Hal ini dapat mengurangi frekuensi kunjungan ke bursa Anda dapat mengirim semua pesanan sekaligus. Mirip dengan menempatkan pesanan dalam batch, dan kemudian secara perlahan memproses logika di balik pembaruan, semakin cepat pesanan dilakukan, tentu saja slippage akan semakin kecil.

Selain itu, untuk menentukan apakah order stop-loss algoritmik telah terisi, Anda dapat menggunakan harga tertinggi dan terendah terkini daripada langsung mendapatkan status pending order, karena untuk menentukan apakah order telah terisi, Anda perlu melakukan polling. terus menerus, yang relatif sering terjadi dan akan menyebabkan banyak akses api yang tidak valid. Pembaruan harga K-line dari websocket sangat tepat waktu dan tidak menempati batas frekuensi API.

Dengan cara yang sama, beberapa exit order juga bisa seperti ini. Jika sinyal keluar Anda bergantung pada harga dalam satu batang, mungkin lebih baik menggunakan harga tertinggi dan terendah terkini. Karena terkadang harga terpicu dan langsung kembali, jika frekuensi pengecekan Anda tidak terlalu tinggi bisa saja Anda melewatkannya. Untuk memastikan konsistensi dalam strategi trading Anda, periksa harga tertinggi dan terendah agar harga tidak terlewatkan. Pendekatan ini memiliki keuntungan tambahan karena harga transaksi aktual mungkin lebih menguntungkan dibandingkan harga pemicu sebenarnya.

Saya tidak tahu apakah dua poin di atas mudah dipahami. Ini mungkin memerlukan pengalaman kehidupan nyata.

Saya ingin berbagi beberapa pengalaman saya dalam mengembangkan kode nyata, berharap dapat bermanfaat bagi semua orang.