Tugas utama dari sistem WEB yang sangat dimuat adalah kemampuan untuk memproses sejumlah besar permintaan. Masalah ini dapat diselesaikan dengan berbagai cara. Dalam artikel ini, saya mengusulkan untuk mempertimbangkan metode yang tidak biasa untuk mengoptimalkan permintaan backend melalui teknologi range-range (rentang). Yaitu, untuk mengurangi jumlah mereka tanpa kehilangan kualitas sistem melalui caching yang efisien.
Untuk mulai dengan, saya mengusulkan untuk mempelajari
sebuah artikel di mana teknologi pembukaan dengan contoh untuk S2S disajikan dengan sangat ringkas dan cerdas. Lebih lanjut, disarankan untuk berkenalan dengan
artikel pertama saya tentang penggunaan teknologi ini untuk mengoptimalkan pekerjaan dengan data pasar pada proyek pertukaran cryptocurrency.
Pada artikel ini, saya ingin menunjukkan bahwa teknologi ini dapat digunakan secara lebih luas daripada yang diperlihatkan artikel pertama. Biarkan saya mengingatkan Anda bahwa ada informasi perdagangan (
lilin ) yang diperoleh dengan rentang-permintaan untuk file statis, yang disiapkan terlebih dahulu oleh layanan khusus. Sekarang, saya ingin mempertimbangkan permintaan untuk backend penuh menggunakan data pasar yang sama sebagai contoh, dan untuk lilin yang sama, tanpa kehilangan keuntungan utama.
Jadi apa yang direncanakan untuk dicapai:
- Optimalkan permintaan backend (kurangi jumlahnya);
- Tingkatkan kecepatan pengiriman konten ke pengguna akhir;
- Optimalkan lalu lintas.
Sekali lagi, saya tekankan bahwa teknologi jangkauan adalah standar (
RFC 2616 ). Ini secara asli didukung oleh browser dan mereka dapat men-cache bagian yang diterima dari data. Oleh karena itu, permintaan berikutnya dari browser, jika ada cache aktual dari bagian yang diminta, diterapkan pada klien tanpa mengganggu server Anda.
Jika Anda menambahkan
CDN antara klien dan server, Anda bisa mendapatkan lapisan caching yang kuat. Dan jika dalam kasus pertama, caching akan terjadi untuk klien akhir yang spesifik, kemudian dipasangkan dengan CDN, Anda mendapatkan kesempatan untuk melakukan cache data untuk sekelompok klien akhir.
Jadi, untuk membuat permintaan nyata ke server, permintaan harus mengatasi dua level caching, yang masing-masing mengurangi volume permintaan ke server tujuan. Tentu saja, "redoubt" terakhir, di jalur permintaan, bisa menjadi server Anda dengan cache-nya.
Dari fitur-fitur yang menggunakan teknologi jangkauan, Anda perlu mempertimbangkan bahwa ia bekerja dengan bagian-bagian byte. Yaitu dengan data biner. Dan kami dapat meminta interval byte yang tepat. Mereka harus merespons, masing-masing - dengan blok biner.
Saya pikir cukup pengantar. Mari kita beralih ke kasus khusus, dan sudah dengan contoh, kita akan mencari tahu bagaimana kita dapat menggunakan semua "kebahagiaan" ini dalam masalah tertentu - meminta lilin untuk interval tertentu dengan paparan yang diberikan.
Sebagai permulaan, sebagai kita perlu bekerja dengan struktur biner, mari kita enkode lilin kita. Untuk ini kami ambil, misalnya, struktur berikut:
moment: int32 // min: float64 // max: float64 // open: float64 // close: float64 // volume: float64 // average: float64 //
Dengan demikian, struktur kami akan menempati 52 byte. Kami menganggapnya sebagai kuantum - blok biner minimum.
Selanjutnya, kami mengimplementasikan pengontrol yang akan menerima permintaan GET dan menguraikan header rentang. Dalam hal ini, kami akan menerjemahkan interval yang diminta ke dalam kuanta dengan pembagian sederhana tanpa sisa, mis. misalnya, permintaan interval:
Range: 5200-52000Kita harus menafsirkan dalam dimensi kuantum kita sebagai:
Range: 100-1000Intinya, ini akan menjadi offset dan batas permintaan basis data kami.
Dengan definisi eksposur yang sangat sederhana, kita bisa memasukkannya ke dalam url. Sebagai contoh:
/api/v1/candles/7mYaitu kami akan meminta lilin dengan pencahayaan 7 menit. Secara alami, kami mengasumsikan bahwa parameter ini dapat diubah atas permintaan frontend.
Sekarang, mengetahui eksposur yang diperlukan, jumlah lilin pertama dan jumlah lilin terakhir yang diminta oleh frontend, kita dapat menjalankan kueri yang sesuai dengan database.
Secara umum, ini sangat mengingatkan pada masalah pagination klasik.
Ada hal-hal kecil yang tersisa. Setiap baris hasil kueri dikonversi menjadi struktur biner (kuantum yang sama) dan array biner yang dihasilkan ditampilkan sebagai hasil kueri, dan rentang konten dikembalikan ke header respons:
Content-Range: [ ] / [[ ] * [ ]]Berhenti Tetapi bagaimana depan dapat meminta interval waktu yang diinginkan, dan bahkan dalam interval byte? Bagaimana dia tahu ada nomor lilin di sana? Di sini juga, semuanya diciptakan. Rentang mendukung offset relatif, mis.
Range: -52Minta 52 byte dari akhir. Yaitu lilin terakhir. Sekarang, mengetahui saat terakhir dari waktu lilin terakhir, mengetahui, dari jawaban, ukuran total "file", Anda dapat menghitung jumlah total lilin, dan dari sini menentukan interval byte untuk meminta paparan waktu yang diinginkan.
Jika Anda tiba-tiba ingin mengajukan pertanyaan - mengapa kesulitan seperti itu? Harap kembali ke sasaran Anda. Teknologi ini "menutupi" kueri analitik ke database menjadi file biner untuk CDN dan browser. Ini memungkinkan Anda untuk mentransfer sebagian besar permintaan berulang ke CDN dan klien akhir.
Mungkin muncul pertanyaan lain - mengapa tidak menggunakan caching sederhana untuk permintaan GET? Bagus Mari kita perbaiki. Jika kami menjalankan permintaan seperti itu di REST klasik:
GET /api/v1/candles/7m?from=01-03-2018&to=31-03-2018Kami akan mendapatkan cache unik untuk permintaan ini. Dengan menjalankan kueri berikut:
GET /api/v1/candles/7m?from=15-03-2018&to=20-03-2018Kami akan mendapatkan cache unik lain .... meskipun, perhatikan, permintaan kedua meminta data dimasukkan dalam respons yang pertama.
Jadi, dalam hal implementasi yang diusulkan di atas (rentang), permintaan kedua tidak akan membentuk cache terpisah, tetapi akan menggunakan data yang sudah diterima dari permintaan pertama. Dan itu tidak akan masuk ke server. Dan ini, menghemat ukuran cache dan mengurangi jumlah panggilan ke server.
Apakah ada kelemahan pada teknologi ini? Ya Mereka jelas:
- Teknologi ini tidak cocok untuk perubahan data seiring waktu, karena berdasarkan caching total.
- CDN CloudFlare hanya membuat cache file sepenuhnya. Ini berarti bahwa jika klien akhir meminta interval, katakanlah, 1 hingga 100 byte, maka CloudFlare sebenarnya akan meminta seluruh file dari server. Yaitu dalam kasus kami, itu akan memuat semua lilin dengan eksposur tertentu. Dia akan menaruhnya sendiri dan sudah akan mendistribusikannya sendiri. Ini bahkan dapat dianggap sebagai nilai tambah, jika bukan karena pembatasan tempat. Dan jika Anda dapat membentuk jawaban "berat", dan banyak parameter, maka ... Secara umum, jelas bahwa tempat itu akan berakhir. Mungkin kami tidak dapat mengonfigurasinya dengan benar. Namun sejauh ini hasilnya adalah sebagai berikut.
- Diperlukan untuk mengelola cache dengan bijak. Ada mekanisme yang cukup untuk ini, tetapi mereka membutuhkan penyetelan.
- Frontend harus dapat mem-parsing data biner dan memiliki sesuatu ala dataset di papan untuk bekerja dengan berbagai permintaan.
Saya akan merumuskan kelayakan menerapkan strategi ini sebagai berikut - ketika Anda membutuhkannya, Anda akan mengerti. Jika sekarang ada keraguan, ada baiknya tahu tentangnya, tapi jangan repot-repot.