Halo! Nama saya Alexei Pyankov, saya seorang pengembang di perusahaan Sportmaster. Karena Saya menceritakan bagaimana pengerjaan situs web Sportmaster dimulai pada tahun 2012, inisiatif apa yang berhasil kami “teruskan” dan sebaliknya, apa yang kami kumpulkan.
Hari ini saya ingin berbagi pemikiran yang mengikuti topik lain - memilih sistem caching untuk backend java di area admin situs. Plot ini memiliki arti khusus bagi saya - walaupun ceritanya hanya berlangsung selama 2 bulan, selama 60 hari tersebut kami bekerja 12-16 jam dan tanpa satu hari libur pun. Saya tidak pernah berpikir atau membayangkan bahwa bekerja sekeras itu bisa dilakukan.
Oleh karena itu, saya membagi teks menjadi 2 bagian agar tidak memuatnya sepenuhnya. Sebaliknya, bagian pertama akan sangat ringan - persiapan, pengenalan, beberapa pertimbangan tentang apa itu caching. Jika Anda sudah menjadi developer berpengalaman atau pernah bekerja dengan cache, dari sisi teknis kemungkinan besar tidak akan ada hal baru di artikel ini. Namun bagi seorang junior, ulasan kecil seperti itu dapat memberi tahu dia arah mana yang harus diperhatikan jika dia berada di persimpangan jalan.
Ketika versi baru situs web Sportmaster mulai diproduksi, data diterima dengan cara yang, secara halus, tidak terlalu nyaman. Dasarnya adalah tabel yang disiapkan untuk versi situs sebelumnya (Bitrix), yang harus ditarik ke ETL, dibawa ke bentuk baru dan diperkaya dengan berbagai hal kecil dari selusin sistem lainnya. Agar gambar atau deskripsi produk baru muncul di situs, Anda harus menunggu hingga keesokan harinya - update hanya pada malam hari, sehari sekali.
Pada awalnya, ada begitu banyak kekhawatiran sejak minggu-minggu pertama memasuki tahap produksi sehingga ketidaknyamanan bagi pengelola konten hanyalah hal yang sepele. Namun, setelah semuanya beres, pengembangan proyek berlanjut - beberapa bulan kemudian, di awal tahun 2015, kami mulai aktif mengembangkan panel admin. Pada tahun 2015 dan 2016, semuanya berjalan dengan baik, kami merilis secara teratur, panel admin mencakup lebih banyak persiapan data, dan kami sedang mempersiapkan fakta bahwa tim kami akan segera dipercayakan dengan hal yang paling penting dan kompleks - produk sirkuit (persiapan penuh dan pemeliharaan data pada semua produk). Namun pada musim panas 2017, tepat sebelum peluncuran sirkuit komoditas, proyek ini akan berada dalam situasi yang sangat sulit - justru karena masalah dengan caching. Saya ingin membicarakan episode ini di bagian kedua dari publikasi dua bagian ini.
Namun pada postingan kali ini saya akan memulai dari jauh, saya akan menyajikan beberapa pemikiran – ide tentang caching, yang akan menjadi langkah yang baik untuk menelusuri sebelum proyek besar.
Ketika tugas cache terjadi
Tugas caching tidak muncul begitu saja. Kami adalah pengembang, sedang menulis produk perangkat lunak dan ingin produk tersebut diminati. Jika produknya laris dan sukses, pengguna akan datang. Dan semakin banyak lagi yang datang. Dan kemudian ada banyak pengguna dan produk menjadi sangat dimuat.
Pada tahap pertama, kami tidak memikirkan tentang optimasi dan kinerja kode. Hal utama adalah fungsionalitas, dengan cepat meluncurkan uji coba dan menguji hipotesis. Dan jika beban bertambah, kami memompa setrika. Kita tingkatkan dua atau tiga kali lipat, lima kali lipat, mungkin 10 kali lipat. Di suatu tempat di sini – keuangan tidak memungkinkan lagi. Berapa kali jumlah pengguna akan meningkat? Tidak akan seperti 2-5-10, tapi jika berhasil akan menjadi 100-1000 hingga 100 ribu kali lipat. Artinya, cepat atau lambat, Anda harus melakukan optimasi.
Katakanlah beberapa bagian kode (sebut saja bagian ini sebagai fungsi) membutuhkan waktu yang sangat lama, dan kita ingin mengurangi waktu eksekusi. Suatu fungsi dapat berupa akses ke database, atau dapat berupa eksekusi logika yang kompleks - yang utama adalah penyelesaiannya membutuhkan waktu lama. Seberapa banyak Anda dapat mengurangi waktu eksekusi? Dalam batasnya, Anda dapat menguranginya menjadi nol, tidak lebih. Bagaimana cara mengurangi waktu eksekusi menjadi nol? Jawaban: hilangkan eksekusi sama sekali. Sebaliknya, segera kembalikan hasilnya. Bagaimana cara mengetahui hasilnya? Jawaban: hitung atau cari di suatu tempat. Butuh waktu lama untuk menghitungnya. Dan memata-matai, misalnya, mengingat hasil yang dihasilkan fungsi terakhir kali ketika dipanggil dengan parameter yang sama.
Artinya, pelaksanaan fungsi tersebut tidak penting bagi kami. Cukup mengetahui parameter apa yang menentukan hasilnya. Kemudian, jika nilai parameter direpresentasikan dalam bentuk objek yang dapat digunakan sebagai kunci dalam suatu penyimpanan, maka hasil perhitungannya dapat disimpan dan dibacakan pada saat diakses berikutnya. Jika penulisan dan pembacaan hasilnya lebih cepat daripada menjalankan fungsinya, kita mendapat keuntungan dalam hal kecepatan. Jumlah keuntungannya bisa mencapai 100, 1000, dan 100 ribu kali lipat (10^5 agaknya merupakan pengecualian, tetapi dalam kasus basis yang cukup tertinggal, hal itu sangat mungkin terjadi).
Persyaratan dasar untuk sistem caching
Hal pertama yang mungkin menjadi persyaratan untuk sistem caching adalah kecepatan baca yang cepat dan, pada tingkat yang lebih rendah, kecepatan tulis. Hal ini benar, namun hanya sampai kita meluncurkan sistem ke produksi.
Mari kita mainkan kasus ini.
Katakanlah kita telah menyediakan beban saat ini dengan perangkat keras dan sekarang secara bertahap memperkenalkan caching. Jumlah pengguna bertambah sedikit, beban bertambah - kami menambahkan sedikit cache, mengencangkannya di sana-sini. Ini berlanjut selama beberapa waktu, dan sekarang fungsi-fungsi berat praktis tidak dipanggil lagi - seluruh beban utama ada pada cache. Jumlah pengguna selama ini meningkat sebanyak N kali lipat.
Dan jika persediaan awal perangkat keras bisa 2-5 kali lipat, maka dengan bantuan cache kita bisa meningkatkan kinerja sebanyak 10 kali lipat atau, dalam kasus yang baik, sebanyak 100 kali lipat, di beberapa tempat mungkin sebanyak satu kali lipat. dari 1000. Artinya, pada perangkat keras yang sama – kami memproses permintaan 100 kali lebih banyak. Hebat, Anda layak mendapatkan roti jahe!
Namun sekarang, pada suatu saat, secara kebetulan, sistem mogok dan cache runtuh. Tidak ada yang istimewa - lagi pula, cache dipilih berdasarkan persyaratan "kecepatan baca dan tulis yang tinggi, sisanya tidak masalah".
Dibandingkan dengan beban awal, cadangan besi kami adalah 2-5 kali lipat, dan beban selama ini meningkat 10-100 kali lipat. Dengan menggunakan cache, kami menghilangkan panggilan untuk fungsi-fungsi berat dan karenanya semuanya berfungsi. Dan sekarang, tanpa cache, berapa kali sistem kita akan melambat? Apa yang akan terjadi pada kita? Sistem akan jatuh.
Meskipun cache kita tidak rusak, tetapi hanya dibersihkan sebentar, cache tersebut perlu dihangatkan, dan ini akan memakan waktu. Dan selama ini, beban utama akan jatuh pada fungsionalitas.
Kesimpulan: proyek produksi dengan muatan tinggi memerlukan sistem caching tidak hanya untuk memiliki kecepatan baca dan tulis yang tinggi, tetapi juga untuk memastikan keamanan data dan ketahanan terhadap kegagalan.
Pilihan tepung
Dalam proyek dengan panel admin, pilihannya seperti ini: pertama kami menginstal Hazelcast, karena Kami sudah familiar dengan produk ini dari pengalaman situs utama. Namun di sini pilihan ini ternyata tidak berhasil - berdasarkan profil pemuatan kami, Hazelcast tidak hanya lambat, tetapi juga sangat lambat. Dan saat itu kami sudah mendaftar untuk tanggal rilisnya.
Spoiler: bagaimana tepatnya keadaan berkembang sehingga kami melewatkan banyak hal dan berakhir dengan situasi yang akut dan tegang - saya akan memberi tahu Anda di bagian kedua - dan bagaimana kami berakhir dan bagaimana kami keluar. Tapi sekarang - saya hanya akan mengatakan bahwa itu sangat membuat stres, dan "untuk berpikir - entah bagaimana saya tidak dapat berpikir, kami mengocok botolnya." “Mengocok botolnya” juga merupakan spoiler, lebih lanjut tentang itu nanti.
Apa yang kita lakukan:
- Kami membuat daftar semua sistem yang disarankan Google dan StackOverflow. Sedikit di atas 30
- Kami menulis pengujian dengan beban khas produksi. Untuk melakukan ini, kami mencatat data yang melewati sistem di lingkungan produksi - semacam sniffer untuk data yang tidak ada di jaringan, tetapi di dalam sistem. Data inilah yang digunakan dalam pengujian.
- Dengan seluruh tim, setiap orang memilih sistem berikutnya dari daftar, mengonfigurasinya, dan menjalankan pengujian. Ia tidak lulus ujian, tidak membawa beban – kami membuangnya dan melanjutkan ke yang berikutnya.
- Pada sistem ke-17 menjadi jelas bahwa segala sesuatunya tidak ada harapan. Berhenti mengocok botolnya, saatnya berpikir serius.
Namun ini adalah opsi ketika Anda perlu memilih sistem yang akan “melewati kecepatan” dalam pengujian yang telah disiapkan sebelumnya. Bagaimana jika belum ada tes seperti itu dan Anda ingin segera memilih?
Mari kita contohkan opsi ini (sulit untuk membayangkan bahwa pengembang menengah+ hidup dalam ruang hampa, dan pada saat seleksi belum memformalkan preferensinya mengenai produk mana yang akan dicoba terlebih dahulu - oleh karena itu, alasan lebih lanjut lebih merupakan ahli teori/filsafat/ tentang seorang junior).
Setelah memutuskan persyaratannya, kami akan mulai memilih solusi yang siap pakai. Mengapa menemukan kembali roda: kita akan pergi dan mengambil sistem caching yang sudah jadi.
Kalau baru memulai dan googling, maka beri atau terima perintahnya, tapi secara umum pedomannya akan seperti ini. Pertama-tama, Anda akan menemukan Redis, terdengar di mana-mana. Kemudian Anda akan mengetahui bahwa EhCache adalah sistem tertua dan paling terbukti. Selanjutnya kami akan menulis tentang Tarantool, pengembangan dalam negeri yang memiliki aspek solusi yang unik. Dan juga Ignite, karena kini sedang naik daun popularitasnya dan mendapat dukungan dari SberTech. Diakhir juga ada Hazelcast, karena di dunia enterprise sering muncul di kalangan perusahaan besar.
Daftar ini tidak lengkap; ada lusinan sistem. Dan kami hanya akan mengacaukan satu hal. Mari kita ambil 5 sistem terpilih untuk “kontes kecantikan” dan menentukan pilihan. Siapa yang akan menjadi pemenangnya?
Redis
Kami membaca apa yang mereka tulis di situs resminya.
- proyek sumber terbuka. Menawarkan penyimpanan data dalam memori, kemampuan untuk menyimpan pada disk, partisi otomatis, ketersediaan tinggi, dan pemulihan dari pemadaman jaringan.
Tampaknya semuanya baik-baik saja, Anda dapat mengambilnya dan memasangnya - semua yang Anda butuhkan, berfungsi. Tapi sekedar iseng, mari kita lihat kandidat lainnya.
EhCache
- “cache yang paling banyak digunakan untuk Java” (terjemahan slogan dari situs resminya). Juga sumber terbuka. Dan kemudian kami memahami bahwa Redis bukan untuk Java, tetapi umum, dan untuk berinteraksi dengannya Anda memerlukan pembungkus. Dan EhCache akan lebih nyaman. Apa lagi yang dijanjikan sistem ini? Keandalan, terbukti, fungsionalitas penuh. Ya, itu juga yang paling umum. Dan menyimpan data berukuran terabyte.
Redis dilupakan, saya siap memilih EhCache.
Namun rasa patriotisme mendorong saya untuk melihat apa yang baik tentang Tarantool.
Tarantool
- memenuhi sebutan “Platform integrasi data waktu nyata”. Kedengarannya sangat rumit, jadi kami membaca halaman tersebut secara mendetail dan menemukan pernyataan keras: “Caches 100% data dalam RAM.” Hal ini seharusnya menimbulkan pertanyaan - lagi pula, mungkin terdapat lebih banyak data daripada memori. Penjelasannya berarti Tarantool tidak menjalankan serialisasi untuk menulis data ke disk dari memori. Sebaliknya, ia menggunakan fitur sistem tingkat rendah, ketika memori hanya dipetakan ke sistem file dengan kinerja I/O yang sangat baik. Secara umum, mereka melakukan sesuatu yang luar biasa dan keren.
Mari kita lihat implementasinya: jalan raya perusahaan Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Jika masih ada keraguan tentang Tarantool, maka kasus implementasi di Mastercard menghabisi saya. Saya mengambil Tarantool.
Tapi bagaimanapun…
Terbakar
… apakah masih ada lagi , disebut sebagai “platform komputasi dalam memori...kecepatan dalam memori sebesar petabyte data.” Ada juga banyak keuntungan di sini: cache dalam memori terdistribusi, penyimpanan nilai kunci dan cache tercepat, penskalaan horizontal, ketersediaan tinggi, integritas yang ketat. Secara umum ternyata yang tercepat adalah Ignite.
Implementasi: Bank Tabungan, American Airlines, Yahoo! Jepang. Dan kemudian saya mengetahui bahwa Ignite tidak hanya diterapkan di Bank Tabungan, tetapi tim SberTech mengirimkan orang-orangnya ke tim Ignite sendiri untuk menyempurnakan produknya. Ini benar-benar menawan dan saya siap menggunakan Ignite.
Benar-benar tidak jelas alasannya, saya melihat poin kelima.
Siaran Hazel
Saya pergi ke situs itu , membaca. Dan ternyata solusi tercepat untuk cache terdistribusi adalah Hazelcast. Solusi ini jauh lebih cepat dibandingkan semua solusi lain dan secara umum merupakan pemimpin dalam bidang jaringan data dalam memori. Dengan latar belakang ini, mengambil sesuatu yang lain berarti tidak menghargai diri sendiri. Ia juga menggunakan penyimpanan data redundan untuk pengoperasian cluster yang berkelanjutan tanpa kehilangan data.
Itu saja, saya siap menggunakan Hazelcast.
Сравнение
Namun jika dicermati, kelima kandidat tersebut dideskripsikan sedemikian rupa sehingga masing-masing merupakan yang terbaik. Bagaimana cara memilih? Kita bisa melihat mana yang paling populer, mencari perbandingannya, dan sakit kepala pun akan hilang.
Kami menemukan yang seperti ini , pilih 5 sistem kami.
Di sini mereka diurutkan: Redis di posisi teratas, Hazelcast di posisi kedua, Tarantool dan Ignite semakin populer, EhCache telah dan tetap sama.
Tapi mari kita lihat : tautan ke situs web, minat umum pada sistem, tawaran pekerjaan - bagus! Artinya, ketika sistem saya gagal, saya akan berkata: “Tidak, ini dapat diandalkan! Ada banyak tawaran pekerjaan..." Perbandingan sederhana seperti itu tidak akan berhasil.
Semua sistem ini bukan hanya sistem caching. Mereka juga memiliki banyak fungsi, termasuk ketika data tidak dipompa ke klien untuk diproses, tetapi sebaliknya: kode yang perlu dieksekusi pada data dipindahkan ke server, dieksekusi di sana, dan hasilnya dikembalikan. Dan mereka tidak sering dianggap sebagai sistem cache yang terpisah.
Oke, jangan menyerah, mari kita cari perbandingan langsung sistemnya. Mari kita ambil dua opsi teratas - Redis dan Hazelcast. Kami tertarik pada kecepatan, dan kami akan membandingkannya berdasarkan parameter ini.
Hz vs Redis
Kami menemukan ini :
Biru adalah Redis, merah adalah Hazelcast. Hazelcast menang di mana-mana, dan ada alasannya: ini multi-thread, sangat dioptimalkan, setiap thread bekerja dengan partisinya sendiri, jadi tidak ada pemblokiran. Dan Redis adalah single-threaded; tidak mendapat manfaat dari CPU multi-core modern. Hazelcast memiliki I/O asinkron, Redis-Jedis memiliki soket pemblokiran. Lagi pula, Hazelcast menggunakan protokol biner, dan Redis berpusat pada teks, artinya tidak efisien.
Untuk berjaga-jaga, mari beralih ke sumber perbandingan lain. Apa yang akan dia tunjukkan pada kita?
Redis vs Hz
Satu lagi :
Di sini, sebaliknya, merah adalah Redis. Artinya, Redis mengungguli Hazelcast dari segi performa. Hazelcast memenangkan perbandingan pertama, Redis memenangkan perbandingan kedua. menjelaskan dengan sangat tepat mengapa Hazelcast memenangkan perbandingan sebelumnya.
Ternyata hasil yang pertama benar-benar dicurangi: Redis diambil di kotak dasar, dan Hazelcast disesuaikan untuk uji kasus. Ternyata: pertama, kita tidak bisa mempercayai siapa pun, dan kedua, ketika kita akhirnya memilih suatu sistem, kita masih perlu mengkonfigurasinya dengan benar. Pengaturan ini mencakup lusinan, hampir ratusan parameter.
Mengocok botolnya
Dan saya dapat menjelaskan seluruh proses yang telah kita lakukan dengan metafora berikut: “Mengocok botolnya.” Artinya sekarang tidak perlu memprogram, nah yang utama bisa membaca stackoverflow. Dan saya memiliki seseorang di tim saya, seorang profesional, yang bekerja persis seperti ini pada saat-saat kritis.
Apa yang dia lakukan? Dia melihat sesuatu yang rusak, melihat jejak tumpukan, mengambil beberapa kata darinya (yang merupakan keahliannya dalam program ini), mencari di Google, menemukan stackoverflow di antara jawabannya. Tanpa membaca, tanpa berpikir, di antara jawaban pertanyaan, ia memilih yang paling mirip dengan kalimat “lakukan ini dan itu” (memilih jawaban seperti itu adalah bakatnya, karena tidak selalu jawaban yang paling banyak disukai), berlaku , terlihat: jika ada sesuatu yang berubah, maka bagus. Jika belum berubah, putar kembali. Dan ulangi peluncuran-periksa-pencarian. Dan dengan cara intuitif ini, dia memastikan bahwa kode tersebut berfungsi setelah beberapa waktu. Dia tidak tahu kenapa, dia tidak tahu apa yang dia lakukan, dia tidak bisa menjelaskan. Tetapi! Infeksi ini berhasil. Dan “apinya padam.” Sekarang mari kita cari tahu apa yang kita lakukan. Ketika program ini berhasil, itu jauh lebih mudah. Dan itu menghemat banyak waktu.
Metode ini dijelaskan dengan sangat baik dengan contoh ini.
Dulunya sangat populer untuk mengoleksi perahu layar di dalam botol. Pada saat yang sama, perahu layarnya besar dan rapuh, dan leher botolnya sangat sempit, tidak mungkin untuk mendorongnya ke dalam. Bagaimana cara merakitnya?
Ada metode seperti itu, sangat cepat dan sangat efektif.
Kapal itu terdiri dari banyak benda kecil: tongkat, tali, layar, lem. Kami memasukkan semua ini ke dalam botol.
Kami mengambil botol itu dengan kedua tangan dan mulai mengocoknya. Kami mengguncang dan mengguncangnya. Dan biasanya ternyata menjadi sampah belaka tentunya. Tapi terkadang. Terkadang ternyata itu sebuah kapal! Lebih tepatnya, sesuatu yang mirip dengan kapal.
Kami menunjukkan sesuatu ini kepada seseorang: “Seryoga, kamu lihat!?” Dan memang dari jauh terlihat seperti kapal. Namun hal ini tidak bisa dibiarkan terus berlanjut.
Ada cara lain. Mereka digunakan oleh orang-orang yang lebih mahir, seperti peretas.
Saya memberi orang ini tugas, dia melakukan segalanya dan pergi. Dan Anda lihat - sepertinya sudah selesai. Dan setelah beberapa saat, ketika kodenya perlu diselesaikan, ini dimulai karena dia... Untung dia sudah berhasil kabur jauh. Inilah orang-orang yang, dengan menggunakan contoh botol, akan melakukan ini: Anda lihat, di mana bagian bawahnya berada, kacanya tertekuk. Dan tidak sepenuhnya jelas apakah transparan atau tidak. Kemudian para “peretas” memotong bagian bawah ini, memasukkan sebuah kapal ke sana, lalu merekatkannya kembali bagian bawahnya, dan seolah-olah memang begitulah seharusnya.
Dari sudut pandang perumusan masalah, semuanya tampak benar. Tetapi dengan menggunakan kapal sebagai contoh: mengapa membuat kapal ini, siapa yang membutuhkannya? Itu tidak menyediakan fungsionalitas apa pun. Biasanya kapal seperti itu merupakan hadiah kepada orang-orang berpangkat tinggi, yang meletakkannya di rak di atasnya, sebagai semacam simbol, sebagai tanda. Dan jika orang seperti itu, kepala perusahaan besar atau pejabat tinggi, bagaimana bendera tersebut melambangkan peretasan seperti itu, yang lehernya telah dipotong? Akan lebih baik jika dia tidak pernah mengetahuinya. Lantas, bagaimana mereka akhirnya bisa membuat kapal-kapal tersebut yang bisa diberikan kepada orang penting?
Satu-satunya tempat penting yang tidak dapat Anda lakukan apa pun adalah tubuh. Dan lambung kapal pas di leher. Sedangkan kapalnya dirakit di luar botol. Tapi ini bukan sekedar merakit kapal, ini adalah kerajinan perhiasan sungguhan. Tuas khusus ditambahkan ke komponen, yang kemudian memungkinkannya untuk diangkat. Misalnya, layarnya dilipat, dimasukkan dengan hati-hati ke dalam, lalu dengan bantuan pinset, layarnya ditarik dan diangkat dengan sangat tepat dan presisi. Hasilnya adalah sebuah karya seni yang dapat dihadiahkan dengan hati nurani yang bersih dan kebanggaan.
Dan jika kita ingin proyek ini sukses, setidaknya harus ada satu pembuat perhiasan di tim. Seseorang yang peduli terhadap kualitas produk dan memperhatikan segala aspek, tanpa mengorbankan apapun, bahkan di saat-saat stres, ketika keadaan mengharuskan melakukan hal yang mendesak dengan mengorbankan hal yang penting. Semua proyek yang sukses dan berkelanjutan, yang telah teruji oleh waktu, dibangun berdasarkan prinsip ini. Ada sesuatu yang sangat tepat dan unik tentang mereka, sesuatu yang memanfaatkan semua kemungkinan yang ada. Dalam contoh kapal di dalam botol, fakta bahwa lambung kapal melewati leher diperlihatkan.
Kembali ke tugas memilih server caching kita, bagaimana metode ini bisa diterapkan? Saya menawarkan opsi untuk memilih dari semua sistem yang ada - jangan kocok botolnya, jangan memilih, tetapi lihatlah pada prinsipnya apa yang mereka miliki, apa yang harus dicari ketika memilih suatu sistem.
Di mana mencari kemacetan
Mari kita mencoba untuk tidak mengocok botolnya, tidak membahas semua yang ada di sana satu per satu, tetapi mari kita lihat masalah apa yang akan muncul jika kita tiba-tiba, untuk tugas kita, merancang sendiri sistem seperti itu. Tentu saja, kami tidak akan merakit sepedanya, tetapi kami akan menggunakan diagram ini untuk membantu kami mengetahui hal-hal apa yang perlu diperhatikan dalam deskripsi produk. Mari kita buat sketsa diagram seperti itu.
Jika sistemnya terdistribusi, maka kita akan memiliki beberapa server (6). Katakanlah ada empat (lebih mudah untuk menempatkannya dalam gambar, tetapi, tentu saja, jumlahnya bisa sebanyak yang Anda suka). Jika server berada di node yang berbeda, itu berarti mereka semua menjalankan beberapa kode yang bertanggung jawab untuk memastikan bahwa node ini membentuk sebuah cluster dan, jika terjadi kerusakan, terhubung dan mengenali satu sama lain.
Kita juga memerlukan logika kode (2), yang sebenarnya tentang caching. Klien berinteraksi dengan kode ini melalui beberapa API. Kode klien (1) dapat berada dalam JVM yang sama atau mengaksesnya melalui jaringan. Logika yang diterapkan di dalamnya adalah keputusan objek mana yang akan dibiarkan di cache dan objek mana yang akan dibuang. Kami menggunakan memori (3) untuk menyimpan cache, tetapi jika perlu, kami dapat menyimpan sebagian data di disk (4).
Mari kita lihat di bagian mana beban akan terjadi. Sebenarnya, setiap panah dan setiap node akan dimuat. Pertama, antara kode klien dan api, jika ini adalah komunikasi jaringan, penurunan permukaan tanah bisa sangat terlihat. Kedua, dalam kerangka api itu sendiri - jika kita berlebihan dengan logika yang rumit, kita dapat mengalami masalah dengan CPU. Dan alangkah baiknya jika logika tidak membuang waktu pada ingatan. Dan masih ada interaksi dengan sistem file - dalam versi biasa ini adalah serialisasi/pemulihan dan tulis/baca.
Berikutnya adalah interaksi dengan cluster. Kemungkinan besar akan berada dalam sistem yang sama, namun bisa juga secara terpisah. Di sini Anda juga perlu memperhitungkan transfer data ke dalamnya, kecepatan serialisasi data, dan interaksi antar cluster.
Sekarang, di satu sisi, kita bisa membayangkan “roda apa yang akan berputar” di sistem cache saat memproses permintaan dari kode kita, dan di sisi lain, kita bisa memperkirakan apa dan berapa banyak permintaan yang akan dihasilkan kode kita ke sistem ini. Ini cukup untuk membuat pilihan yang kurang lebih bijaksana - memilih sistem untuk kasus penggunaan kita.
Siaran Hazel
Mari kita lihat bagaimana menerapkan dekomposisi ini ke daftar kita. Misalnya Hazelcast.
Untuk memasukkan/mengambil data dari Hazelcast, kode klien mengakses (1) api. Hz memungkinkan Anda menjalankan server sebagai tertanam, dan dalam hal ini, mengakses api adalah pemanggilan metode di dalam JVM, yang dapat dianggap gratis.
Agar logika di (2) berfungsi, Hz bergantung pada hash array byte dari kunci serial - yaitu, kuncinya akan diserialkan dalam hal apa pun. Ini adalah overhead yang tidak bisa dihindari untuk Hz.
Strategi penggusuran diterapkan dengan baik, tetapi untuk kasus-kasus khusus Anda dapat menambahkan strategi Anda sendiri. Anda tidak perlu khawatir tentang bagian ini.
Penyimpanan (4) dapat dihubungkan. Besar. Interaksi (5) untuk tertanam dapat dianggap instan. Pertukaran data antar node dalam cluster (6) - ya, ada. Ini adalah investasi pada toleransi kesalahan dengan mengorbankan kecepatan. Fitur Hz Near-cache memungkinkan Anda mengurangi harga - data yang diterima dari node lain di cluster akan di-cache.
Apa yang bisa dilakukan dalam kondisi seperti itu untuk meningkatkan kecepatan?
Misalnya, untuk menghindari serialisasi kunci di (2) - pasang cache lain di atas Hazelcast, untuk data terpanas. Sportmaster memilih Kafein untuk tujuan ini.
Untuk memutar pada level (6), Hz menawarkan dua jenis penyimpanan: IMap dan RelicedMap.
Perlu disebutkan bagaimana Hazelcast masuk ke dalam tumpukan teknologi Sportmaster.
Pada tahun 2012, ketika kami sedang mengerjakan uji coba pertama situs masa depan, Hazelcast-lah yang menjadi tautan pertama yang dikembalikan oleh mesin pencari. Perkenalan dimulai "pertama kali" - kami terpikat oleh kenyataan bahwa hanya dua jam kemudian, ketika kami memasang Hz ke dalam sistem, itu berhasil. Dan itu bekerja dengan baik. Pada akhirnya kami telah menyelesaikan sejumlah tes dan merasa bahagia. Dan cadangan kekuatan ini cukup untuk mengatasi kejutan yang dilontarkan Hz seiring berjalannya waktu. Kini tim Sportmaster tidak punya alasan untuk meninggalkan Hazelcast.
Namun argumen seperti “tautan pertama di mesin pencari” dan “HelloWorld dengan cepat dibuat”, tentu saja, merupakan pengecualian dan fitur pada saat pemilihan dilakukan. Pengujian sebenarnya untuk sistem yang dipilih dimulai dengan rilis ke produksi, dan pada tahap inilah yang harus Anda perhatikan ketika memilih sistem apa pun, termasuk cache. Sebenarnya dalam kasus kami, kami dapat mengatakan bahwa kami memilih Hazelcast secara tidak sengaja, tetapi ternyata kami memilih dengan benar.
Untuk produksi, yang jauh lebih penting: pemantauan, penanganan kegagalan pada masing-masing node, replikasi data, biaya penskalaan. Artinya, ada baiknya memperhatikan tugas-tugas yang akan muncul selama pemeliharaan sistem - ketika beban sepuluh kali lebih tinggi dari yang direncanakan, ketika kita secara tidak sengaja mengunggah sesuatu di tempat yang salah, ketika kita perlu meluncurkan versi baru. kode, ganti data dan lakukan tanpa disadari oleh klien.
Untuk semua persyaratan ini, Hazelcast tentu saja memenuhi kebutuhan tersebut.
Bersambung
Tapi Hazelcast bukanlah obat mujarab. Pada tahun 2017, kami memilih Hazelcast untuk cache admin, hanya berdasarkan kesan baik dari pengalaman sebelumnya. Ini memainkan peran kunci dalam lelucon yang sangat kejam, yang menyebabkan kami berada dalam situasi yang sulit dan “secara heroik” keluar dari situ selama 60 hari. Namun lebih lanjut tentang itu di bagian selanjutnya.
Sementara itu... Selamat Kode Baru!
Sumber: www.habr.com