Pada artikel terakhir dari siklus, kami berkenalan dengan jenis-jenis pesanan pertukaran. Hari ini kita akan menganalisis buku pesanan, pemrosesan aplikasi dan masalah yang berkaitan dengan organisasi penyimpanan informasi perdagangan.
Penawaran dan Permintaan
Tentunya Anda ingat hukum penawaran dan permintaan dari ekonomi, yang menunjukkan mekanisme pasar untuk pembentukan harga:
Mekanika yang sama bekerja pada pertukaran.
Buku pesanan adalah daftar di mana batas pesanan penjual dan pembeli dimasukkan, sehingga menunjukkan minat saat ini pada instrumen keuangan tertentu.
Jika Anda mengonversi grafik sebelumnya terkait dengan buku pesanan, Anda akan mendapatkan sesuatu seperti ini:
Di sini kita melihat bahwa harga pasar diperoleh ketika harga permintaan maksimum dan harga penawaran minimum sama. Spread adalah perbedaan harga ini. Ini merupakan indikator penting, karena dikaitkan dengan likuiditas instrumen. Semakin kecil penyebarannya, semakin cair instrumen tersebut. Untuk memastikan likuiditas dalam rangka perdagangan pertukaran, mereka sering memaksakan batasan pada spread maksimum, di atas mana perdagangan dapat dihentikan.
Pembuatan aplikasi
Pertimbangkan jalan hidup aplikasi dari masuk ke pertukaran untuk pemenuhan atau pembatalan. Untuk kesederhanaan kami akan mempertimbangkan kasus pasar valuta asing. Proses khusus bertanggung jawab atas logika pemrosesan pesanan, sebut saja pengontrol pasar.
Jadi, peserta membuat aplikasi, sampai ke pertukaran. Pengontrol harus memastikan bahwa peserta memiliki likuiditas yang cukup untuk membuat jenis pesanan yang diminta. Sumber informasi dapat berupa layanan akuntansi internal, atau API eksternal apa pun.
Untuk pelaksanaan segera aplikasi ini, aplikasi yang disebut pasangan harus ada di pasaran.
Jika ada perintah balasan, dari pasangan yang ditemukan, pesanan yang lebih kecil dijalankan secara penuh, dan sebagian besar. Tentu saja, jika eksekusi parsial diizinkan oleh instruksi perdagangan aplikasi. Dengan tidak adanya perintah balasan, sebuah pesanan baru masuk ke dalam buku pesanan dan mengambil tempatnya dalam daftar pesanan jenisnya.
Karena hanya pesanan yang tertunda yang termasuk dalam buku pesanan, untuk pesanan jenis lain Anda harus memilih daftar Anda.
Di semua daftar pesanan, sisi pembelian harus diurutkan dalam urutan menurun, dan sisi penjualan harus diurutkan dalam urutan harga naik. Unsur pertama dari daftar limit order untuk masing-masing pihak membentuk harga penawaran dan permintaan terbaik.
Poin penting lainnya adalah urutan eksekusi. Pengontrol harus mengimplementasikan FIFO. Oleh karena itu, jika harga kedua penawaran tersebut bersamaan, yang dibuat sebelumnya harus lebih tinggi.
Di antarmuka pengguna, buku terlihat seperti tabel yang terdiri dari serangkaian tingkat harga, yang menyajikan pesanan terbatas untuk pembelian dan penjualan.
Untuk perbedaan visual tambahan, aplikasi untuk jual beli memiliki warna yang berbeda.
Agregasi Tingkat
Book Depth - Jumlah level harga. Untuk pasar aktif dengan sejumlah besar pending order, dipisahkan oleh jarak minimum, kedalamannya bisa sangat besar untuk ditampilkan di terminal pedagang. Untuk mengevaluasi seluruh buku, Anda memerlukan alat pengelompokan level.
Dengan memotong satu tempat desimal dan mengelompokkan level, kita dapat mengurangi jumlahnya dengan setiap langkah.
Eksekusi dan pembatalan aplikasi
Setelah pesanan dalam buku dieksekusi atau dibatalkan, pengontrol harus memperbarui buku dengan menghapus pesanan ini dan memberi tahu semua orang yang tertarik dengan perubahan dalam buku tersebut.
Arsitektur dan Scaling Handler
Mengingat kinerja dan keandalan yang diperlukan, perlu untuk menentukan pendekatan untuk penskalaan aplikasi dan sistem penyimpanan.
Biasanya, pertukaran menggunakan penskalaan vertikal. Kode untuk memproses aplikasi dan akun pengguna dijalankan pada satu mesin dalam satu monolith. Pendekatan ini menunjukkan kinerja yang baik, tetapi memiliki batasan yang signifikan - dalam hal apa pun, penskalaan vertikal memiliki batas, baik dalam hal daya prosesor dan kapasitas penyimpanan.
Sebagai bagian dari percobaan, saya memutuskan bahwa pemrosesan pasar harus berskala horizontal. Setiap alat individu diproses oleh prosesnya sendiri. Proses didistribusikan di antara node cluster secara otomatis. Dalam hal kegagalan, pasar ditransfer ke node lain tanpa kehilangan status.
Rumus sistem ini sangat sederhana: Penangan M didistribusikan pada node K cluster dan menggunakan penyimpanan data L.
Skema serupa memungkinkan Anda untuk menskalakan sistem hingga sekitar 150 node. Dan setiap pengontrol pasar dapat menangani sekitar 30k RPS.
Karena aliran aplikasi di semua pasar berbeda dan tergantung pada aktivitas pengguna, pasar dapat dibagi menjadi beberapa kelompok: kecil, sedang dan besar. Setiap node memiliki pengaturan yang memungkinkan Anda menentukan batasan jumlah pasar yang bisa diproses. Wizard secara otomatis dan merata mendistribusikan pasar dengan tipe yang sama di antara node cluster. Dalam hal terjadi perubahan komposisi klaster, pasar didistribusikan kembali. Dengan demikian, distribusi yang kurang lebih seragam dari beban pada sistem tercapai.
Contoh tampilan node dalam antarmuka manajemen pertukaran:
Penyimpanan data
Buku pesanan terus berubah dan harus disimpan dalam memori. Untuk MVP, saya memilih Tarantool dengan WAL sebagai penyimpanan dalam memori. Semua data historis akan direkam dalam PostgreSQL.
Skema untuk menyimpan data saat ini dan historis harus sesuai dengan skema yang dipilih untuk penskalaan kode penangan. Setiap pasar dapat menggunakan postgres dan tarantool sendiri. Untuk melakukan ini, gabungkan pasangan postgresql dan tarantool ke dalam satu kesatuan - gudang data pasar.
Saat menyiapkan pasar, administrator memiliki kemampuan untuk mengelola repositori. Untuk menjaga fleksibilitas, alih-alih akses ke instance postgresql dan tarantool tertentu, kami akan menentukan pengidentifikasi kumpulan koneksi unik. Antarmuka kumpulan ini didukung oleh platform. Dengan demikian, repositori di antarmuka admin terlihat seperti ini:
Saat menyiapkan pasar, administrator harus menentukan setidaknya satu toko untuk setiap pasar. Jika Anda menentukan beberapa, Anda mendapatkan pasar dengan replikasi data logis. Fitur ini memungkinkan Anda untuk mengonfigurasi keandalan dan kinerja skema penyimpanan.
Pesan Buku Data
Tarantool menggunakan ruang untuk mengatur data yang disimpan. Deklarasi ruang yang diperlukan untuk buku pesanan adalah sebagai berikut:
book = { state = { name = 'book_state', id = 1, }, orders = { limit = { buy_orders = { name = 'limit_buy_orders', id = 10, }, sell_orders = { name = 'limit_sell_orders', id = 20, }, }, market = { buy_orders = { name = 'market_buy_orders', id = 30, }, sell_orders = { name = 'market_sell_orders', id = 40, }, }, ... }, orders_mapping = { name = 'orders_mapping', id = 50, }, }
Karena beberapa pasar dapat menyimpan data mereka pada satu contoh tarantool, kami akan menambahkan pengidentifikasi pasar ke semua entitas. Implementasi buku saat ini dibangun di atas prinsip penghitungan sekali, berkali-kali. Selama operasi pembaruan buku, pengelompokan secara otomatis dihitung ulang. Misalnya, kami menambahkan pesanan ke pasar, keakuratan harga adalah 6, ada 6 kelompok harga yang memungkinkan + satu irisan dengan data pesanan asli yang perlu diperbarui.
Ada banyak pesanan_petakan pesanan untuk mengeluarkan daftar pesanan klien aktif.
Berkat model data tarantool, menggunakan kombinasi indeks dan berbagai iterator pengambilan sampel, kode lua yang mengimplementasikan penyimpanan buku pesanan hanya membutuhkan 600 baris (bersamaan dengan inisialisasi).
Data historis
Data pasar disimpan dalam tabel terpisah untuk setiap pasar. Pertimbangkan satu set tabel dasar.
Riwayat aplikasi yang selesai
Untuk menyimpan hasil pemrosesan aplikasi, gunakan tabel histori. Ini termasuk aplikasi yang sepenuhnya selesai, serta dibatalkan, tetapi sebagian selesai.
CREATE TABLE public.history ( id uuid NOT NULL, ts timestamp without time zone NOT NULL DEFAULT now(), owner character varying(75) COLLATE pg_catalog."default" NOT NULL, order_type integer NOT NULL, order_side integer NOT NULL, price numeric(64,32) NOT NULL, qty numeric(64,32) NOT NULL, commission numeric(64,32) NOT NULL, opts jsonb NOT NULL, CONSTRAINT history_pkey PRIMARY KEY (id, ts) )
Atas dasar itu, penerbitan untuk pengguna akhir didasarkan pada riwayat tender mereka.
Umpan Data Historis
Untuk keperluan analisis, serta pembentukan umpan data historis, setelah setiap transaksi, pengontrol pasar harus menyimpan informasi tentang peristiwa ini. Untuk memperbaiki peristiwa perubahan pasar, gunakan tabel kutu:
CREATE TABLE public.ticks ( ts timestamp without time zone NOT NULL, bid numeric(64,32) NOT NULL, ask numeric(64,32) NOT NULL, last numeric(64,32) NOT NULL, bid_vol numeric(64,32), ask_vol numeric(64,32), last_vol numeric(64,32), opts jsonb DEFAULT '{}'::jsonb, CONSTRAINT ticks_pk PRIMARY KEY (ts) )
Ini menyimpan harga dan volume pasar setelah transaksi, dan bidang opts berisi informasi layanan, seperti deskripsi pesanan yang terlibat dalam transaksi.
Bagan Umpan Data
Untuk membangun grafik perdagangan, tabel kutu sudah cukup. Ini berisi apa yang disebut aliran mentah, tetapi postgresql memiliki fungsi analitik yang kuat dan memungkinkan Anda untuk mengumpulkan data berdasarkan permintaan.
Masalah mulai ketika ada terlalu banyak data dan sudah tidak ada daya yang cukup. Untuk mengatasinya, buat tabel dengan data yang sudah dihitung:
CREATE TABLE public.df ( t timestamp without time zone NOT NULL, r df_resolution NOT NULL DEFAULT '1m'::df_resolution, o numeric(64,32), h numeric(64,32), l numeric(64,32), c numeric(64,32), v numeric(64,32), CONSTRAINT df_pk PRIMARY KEY (t, r) )
Kita akan berbicara tentang bagaimana bekerja dengan deret waktu di Postgresql, menyiapkan data untuk tabel df dan bagaimana membuat grafik di artikel berikutnya.
Ringkasan
Kami menemukan poin-poin utama dalam mengatur buku pesanan dan mekanisme pemrosesan pesanan, dan juga sedikit membenamkan diri dalam praktik bekerja dengan data pasar.
Skema penyimpanan yang dipilih memungkinkan Anda untuk mulai dari satu toko untuk semua pasar dan, seiring proyek ini berkembang, mendistribusikan pasar ke toko yang berbeda, menempatkannya sedekat mungkin dengan prosesor pasar.