Penggunaan cache Redis sangat meningkatkan kinerja dan efisiensi aplikasi, terutama untuk kueri data. Tetapi pada saat yang sama, itu juga membawa beberapa masalah. Di antara mereka, masalah terpenting adalah konsistensi data, yang sama sekali tidak dapat dipecahkan. Jika konsistensi data diperlukan, maka caching tidak dapat digunakan.
Masalah umum lainnya adalah penetrasi cache, longsoran cache, dan kerusakan cache. Saat ini, ada juga solusi yang lebih populer di industri ini. Artikel ini bukan untuk menyelesaikan ketiga masalah ini dengan lebih sempurna, juga bukan untuk menumbangkan solusi populer di industri. Sebagai gantinya, kami akan mendemonstrasikan ketiga fenomena masalah ini dari operasi kode yang sebenarnya. Alasan untuk melakukan ini adalah karena sulit untuk memiliki konsep yang sangat jelas di kepala hanya dengan melihat penjelasan akademis tentang masalah ini, dan dengan demonstrasi kode yang sebenarnya, Anda dapat memperdalam pemahaman dan pemahaman Anda tentang masalah ini.
Penetrasi cache
Penetrasi cache mengacu pada kueri data yang tidak ada dalam database. Jika kunci tidak ada atau kunci telah kedaluwarsa, database akan dikueri, dan objek yang dikueri dimasukkan ke dalam cache. Jika objek kueri database kosong, objek tersebut tidak di-cache.
Alur kode
- meneruskan ID kunci utama objek
- Dapatkan objek dari cache berdasarkan kunci
- Jika objek tidak kosong, objek akan kembali secara langsung
- Jika objek kosong, lakukan kueri database
- Jika objek yang dikueri dari database tidak kosong, masukkan ke dalam cache (atur waktu kedaluwarsa) Bayangkan situasi ini, apa yang akan terjadi jika parameter yang diteruskan adalah -1? -1 ini adalah objek yang tidak boleh ada. Database akan dikueri setiap saat, dan setiap kueri akan kosong, dan tidak akan di-cache setiap saat. Jika ada serangan berbahaya, kerentanan ini dapat dieksploitasi untuk menekan database atau bahkan membanjirinya. Bahkan jika UUID digunakan, mudah untuk menemukan KUNCI dan serangan yang tidak ada.
Dalam pekerjaan saya, saya akan menggunakan metode caching nilai null, yaitu langkah 5 dalam [proses kode], jika objek yang dikueri dari database kosong, itu juga dimasukkan ke dalam cache, tetapi waktu kedaluwarsa cache yang ditetapkan pendek, seperti mengaturnya menjadi 60 detik.
Longsoran cache
Longsoran cache mengacu pada kedaluwarsa cache yang ditetapkan selama periode waktu tertentu.
Salah satu alasan longsoran salju, misalnya, saat menulis artikel ini, akan segera pukul nol pada hari kedua belas, dan akan segera ada gelombang pembelian terburu-buru. Kemudian pada pukul satu pagi, cache batch barang ini akan kedaluwarsa. Kueri akses untuk kumpulan barang ini jatuh pada database, dan untuk database, akan ada puncak tekanan berkala.
Ketika Xiaobian melakukan proyek e-commerce, dia umumnya mengadopsi berbagai kategori barang dan menyimpan siklus yang berbeda. Barang dalam kategori yang sama, ditambah faktor acak. Dengan cara ini, waktu kedaluwarsa cache dapat disebarkan sebanyak mungkin, dan waktu cache produk dalam kategori populer lebih lama, dan waktu cache produk dalam kategori yang tidak populer lebih pendek, yang juga dapat menghemat sumber daya layanan caching.
Faktanya, kedaluwarsa terpusat tidak terlalu fatal, dan longsoran cache yang lebih fatal adalah bahwa node server cache mati atau terputus. Karena longsoran cache yang terjadi secara alami harus dibuat dalam jangka waktu tertentu, maka database dapat menahan tekanan, dan pada saat ini, database juga dapat menahan tekanan. Ini tidak lebih dari tekanan berkala pada database. Waktu henti simpul layanan cache menyebabkan tekanan yang tidak dapat diprediksi pada server database, dan kemungkinan besar akan membanjiri database dalam sekejap.
Perincian cache
Perincian cache mengacu pada kunci yang sangat panas, terus-menerus membawa konkurensi besar, konkurensi besar berkonsentrasi pada mengakses titik ini, ketika kunci ini gagal, konkurensi besar terus menerus menembus cache dan langsung meminta database, seperti mengebor lubang di penghalang.
Ketika Xiaobian sedang melakukan proyek e-commerce, dia menjadikan produk ini "hit".
Faktanya, dalam banyak kasus, ledakan semacam ini sulit untuk memberikan tekanan yang menghancurkan pada server database. Ada beberapa perusahaan yang telah mencapai level ini. Oleh karena itu, editor pragmatis telah mempersiapkan produk utama lebih awal, sehingga cache tidak akan pernah kedaluwarsa. Bahkan jika beberapa produk memfermentasi diri menjadi hit, mereka dapat diatur sebagai tidak pernah kedaluwarsa.
Jalan utamanya sederhana, dan kunci penolakan timbal balik kunci mutex benar-benar tidak digunakan.
|
Diposting pada 19/11/2019 09.55.04
|
|
|
|
