Selama refactoring pertukaran crypto kami, diputuskan untuk merevisi konsep bekerja dengan tanggal pasar. Dalam kasus klasik, tanggal pasar didistribusikan dalam dua cara:
1. antarmuka REST;
2. Berlangganan WEBSocket broadcast.
Metode REST sering digunakan untuk memperoleh data historis, sementara WEBSocket mengirimkan informasi langsung secara online. Dalam beberapa kasus, WEBSocket tidak digunakan sama sekali, dan pembaruan dilakukan oleh permintaan reguler melalui REST.
Dan sepertinya semua orang senang. Tetapi, setelah diperiksa lebih dekat, overhead besar dari konsep semacam itu menjadi jelas. Sebagian besar mereka terletak pada REST. Untuk memastikan berfungsinya antarmuka REST, kita harus membuat backend yang memenuhi persyaratan sistem yang sangat dimuat. Secara alami, di sini Anda dapat memilih berbagai opsi solusi dari PHP ke Golang yang sekarang modis.
Hal ini juga diperlukan untuk membuat infrastruktur yang sangat mudah diakses, menerapkan hal-hal sepele seperti CI / CD untuk layanan, menyediakan semua ini dengan spesialis yang tepat untuk pengembangan, pemeliharaan, dll., Dll.
Pada saat yang sama, ini adalah tanggal pasar historis yang menempati sebagian besar ruang disk. Biasanya disimpan dalam database. Di satu sisi, ini memungkinkan kita untuk memecahkan masalah pengelompokan, tetapi pada ukuran kritis, ini menjadi beban yang tak tertahankan dan menimbulkan tugas-tugas non-sepele untuk tim dan pengembang DevOps.
Secara umum ... kesederhanaan dan konsistensi yang jelas dari konsep ini hancur menjadi kehidupan yang keras.
Secara terpisah, Anda perlu memperhatikan kekhasan tanggal pasar. Itu selalu terakumulasi (tumbuh). Yaitu dalam bahasa pemrogram basis data, kami selalu menyisipkan dan kemudian memilih. Tapi tidak habis dibagi. Yaitu fungsionalitas basis data yang luar biasa untuk sistematisasi, optimisasi, dll. Data yang disimpan menjadi tidak diklaim.
Properti penting lainnya dari tanggal pasar adalah strukturnya yang jelas. Misalnya, lilin dalam bagan hanya memiliki delapan parameter:
1. Momen waktu;
2. Eksposisi;
3. Harga maksimum;
4. Harga minimum;
5. Harga pembukaan;
6. harga penutupan;
7. Volume;
8. Harga rata-rata.
Hal yang sama dapat dikatakan tentang kesepakatan.
Berdasarkan prasyarat ini, serta mempersenjatai diri dengan pengalaman, saya dengan cepat sampai pada kesimpulan bahwa lebih tepat untuk menganggap tanggal pasar sebagai aliran terstruktur.
Misalnya, aliran dengan lilin dapat dianggap sebagai susunan struktur biner:
moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64Total: 56 byte.
Misalnya, lilin seperti itu di JSON akan dijelaskan sebagai berikut:
{ "date":1501004700, "high":0.08053391, "low":0.08020004, "open":0.08030001, "close":0.0803542, "volume":48.62169347, "weightedAverage":0.08038445 }
Total: 167 byte.
Keuntungan dalam ukuran jelas. Dan ini lebih sedikit lalu lintas, kecepatan pengiriman lebih tinggi ke klien.
Dan di sini, tentu saja, BSON muncul dalam pikiran. Tapi itu tidak menyelesaikan masalah perlunya backend, dan secara umum tidak menyelesaikan masalah secara mendasar. Selain itu, tidak didukung secara native oleh browser.
Saya melihat ke arah lain. Jaringan memiliki banyak sumber daya yang bekerja dengan utas. Ini adalah sumber daya audio dan video. Mereka menunjukkan semua tanda-tanda yang diperlukan:
- bekerja dengan data dalam jumlah besar;
- sempurna mengatasi beban tinggi;
- mereka mampu mengirimkan konten secara online, tetapi pada saat yang sama mereka memungkinkan untuk mengakses data historis.
Saya masuk sedikit lebih dalam ke video streaming, yang memungkinkan saya untuk secara radikal menyelesaikan semua masalah di atas dengan tanggal pasar. Semua keajaiban, ternyata, tersembunyi dalam teknologi
Content-Range yang didukung di luar kotak, misalnya, Nginx. Ini memungkinkan Anda untuk mengakses area mana pun dari sumber daya statis (file di server) tanpa menggunakan backend. Secara umum, ini terjadi sebagai berikut: Anda merujuk ke URL yang menunjukkan paparan yang ingin Anda kembalikan di header. Misalnya: kisaran: 100-200. Saya tidak akan membahas seluk-beluk, Anda dapat menemukan semua nuansa teknologi dalam artikel khusus. Saya pikir intinya jelas.
Bahkan, sekarang, di sisi depan, Anda dapat mengatur banding ke bagian yang diperlukan dari file, misalnya, berisi lilin. Dan karena diketahui persis berapa banyak byte yang diperlukan oleh satu candle (56 byte), kita dapat dengan mudah menentukan offset yang kita butuhkan. Benar, kita masih perlu tahu titik waktu dari mana jadwal dimulai. Dan ini sangat mudah diselesaikan dengan menambahkan header ke file, yang ukurannya juga konstan.
Yaitu pertama-tama, bagian depan mengakses file dari posisi nol, dan menerima
menuju. Pada saat yang sama, nginx akan mengembalikan ukuran file. Ini akan menentukan jumlah total lilin dalam file dan waktu mulai.
Sekarang, mengetahui titik awal waktu, memiliki gagasan yang jelas tentang jumlah lilin, kita dapat memperoleh salah satu dari mereka untuk jangka waktu dari depan, tanpa menggunakan backend.
Ah, ya ... saat lain ... kami memiliki parameter seperti pemaparan lilin. Di sini solusinya juga sederhana - kami menyimpan beberapa file sekaligus untuk eksposur yang berbeda. Sebagai bonus kecil tambahan, ukuran struktur lilin berkurang 4 byte lagi.
Secara umum, solusinya sudah cukup menarik untuk implementasi, tetapi ternyata, saya tidak malu untuk mengatakan - keuntungan yang sangat keren. Faktanya adalah bahwa browser dapat men-cache data yang diterima oleh metode jangkauan. Yaitu pada permintaan depan berikutnya ke server, jika bagian file ini diterima oleh browser sebelumnya, itu tidak akan sampai ke server Anda, tetapi akan mengambilnya dari cache.
Tetapi bahkan itu belum semuanya. Menggunakan CDN, caching juga dapat dikonfigurasi dengan caranya. Yaitu Singkatnya, Anda bisa mendapatkan sistem yang mampu memberikan volume besar dari tanggal pasar sambil meminimalkan beban pada infrastruktur dan server.
Tak perlu dikatakan, tidak ada lagi keraguan tentang kesetiaan ide? Sekarang ada hal-hal kecil yang nyata ... Anda perlu melakukan pembuatan file yang sama ini.
Seperti disebutkan di atas, biasanya, pertukaran mengoperasikan dua cara pengiriman tanggal pasar: REST dan WEBSocket. Yang terakhir menyiarkan online tanggal pasar saat ini. Ini biasanya layanan terpisah. Seperti yang telah ditunjukkan oleh praktik, menyelesaikan layanan ini sehingga menambahkan data ke file yang diperlukan tidak sulit dan diselesaikan secara harfiah dengan beberapa jam pekerjaan pengembang. Kita dapat mengatakan bahwa dia mencatat pada saat yang sama dengan buletin.
Masalah pengiriman file ke node adalah masalah sinkronisasi sistem file klasik. Tim DevOps memecahkannya dengan mudah dan alami. Misalnya menggunakan rsync.
Sekarang, kita dapat dengan aman mengatakan - BINGO!
Mungkin pertanyaan akan muncul - mengapa semua pertukaran crypto berbeda? Saya tidak punya jawaban yang bisa diandalkan untuk pertanyaan ini. Tetapi ada beberapa pemikiran:
- pertukaran dibuat oleh pengembang crypto yang simpatik. Mungkin mereka tidak tahu tentang karya pertukaran klasik, tidak memperhitungkan pengalaman mereka dan menggunakan solusi yang tersedia untuk mendapatkan hasil cepat. Dan ini adalah solusi templat: REST yang sama dan JSON yang menyertainya;
- seperti yang mereka katakan pada orang-orang - Apakah itu berhasil? Jangan disentuh. - Karena tren teknologi telah diciptakan oleh pertukaran kunci, dan pertukaran yang baru muncul telah meminjamnya.
Jika topik ini menarik bagi masyarakat, saya akan melanjutkan dengan artikel tentang solusi non-standar lainnya yang diterapkan pada proyek kami. Cara ini bekerja dalam praktiknya, Anda dapat melihat di situs web pertukaran (lihat profil saya). Saya terutama mengusulkan untuk memperhatikan pekerjaan grafik, yang dengan jelas menunjukkan semua keuntungan dari teknologi ini.