T: Jenis cache apa yang merupakan cache yang baik?
Cache yang menyelesaikan masalah adalah cache yang baik. Kalimat ini sungguh tidak masuk akal, setara dengan kucing putih, kucing hitam, dan yang menangkap tikus adalah kucing yang baik.
Jadi untuk menyelesaikan masalah, cache manakah yang merupakan cache terbaik? Jawaban saya terhadap pertanyaan ini adalah: cache dengan tingkat hit cache yang tinggi adalah cache yang baik.
Berdasarkan premis untuk menyelesaikan masalah, cache dengan hit rate yang tinggi mungkin memerlukan investasi perangkat keras yang lebih sedikit dibandingkan cache dengan hit rate yang rendah. Pada saat yang sama, jumlah cache mungkin lebih kecil daripada jumlah cache dengan hit rate yang rendah rate. Dengan cara ini, kecepatan pengalamatan pasti akan lebih cepat. Jadi cache dengan hit rate tinggi adalah cache yang bagus.
Tingkat pencapaian cache
Setelah entitas yang di-cache dimasukkan ke dalam cache, jika entitas tersebut belum pernah digunakan satu kali pun oleh dunia luar saat entitas tersebut di-cache (selama siklus hidup entitas yang di-cache), tingkat keberhasilan entitas yang di-cache adalah 0. Semakin sering entitas ini diminta, semakin tinggi tingkat cache hit-nya.
Apa yang disebutkan di atas adalah hit rate suatu entitas di cache. Untuk cache secara keseluruhan, hit rate-nya adalah diagram distribusi hit rate dari setiap individu yang di-cache di atas.
Untuk caching: biasanya individu yang paling umum digunakan adalah bagian yang sangat kecil dari total. Yang paling jarang digunakan merupakan sebagian besar dari keseluruhan.
Jadi kita sering melihat data seperti ini:
Dari 10.000 elemen yang di-cache, 100 di antaranya sering digunakan, hampir setiap menit. 2000 lembar data, diminta satu jam sekali. 3000 data diminta sekali sehari, dan sisa data belum digunakan bahkan satu kali pun setelah dimasukkan ke dalam cache.
Saat ini, perangkat keras berkembang pesat. Jika kita hanya perlu menyimpan 10.000 data dalam cache, kita dapat membuang seluruh 10.000 data ke dalam cache terlepas dari apakah data tersebut digunakan data di cache. Tidak perlu melakukan operasi tambahan atau membuat permintaan ke database.
Namun: perangkat keras berkembang pesat, begitu pula jumlah datanya. Untuk situs web kecil, jika 10.000 data di-cache, semuanya akan di-cache. Namun, situs web besar memiliki setidaknya jutaan data atau data tingkat T. Tentu saja, semua data ini tidak dapat dimasukkan ke dalam cache. Saat ini, sangat penting untuk merancang solusi caching yang masuk akal dan meningkatkan tingkat cache hit. Dan itu perlu.
Beberapa metode umum untuk meningkatkan tingkat cache hit
Dari sudut pandang teknis semata, kami hanya mencatat jumlah permintaan pengguna per satuan waktu, dan menyimpan data yang paling umum digunakan berdasarkan informasi ini.
Namun seringkali, kami meningkatkan tingkat cache hit berdasarkan logika bisnis. Misalnya: Tahun lalu dan blog diterbitkan setahun sebelumnya, permintaan penelusuran untuk artikel jenis ini biasanya setidaknya beberapa kali sehari. Umumnya tidak boleh di-cache di memori.
Contoh lainnya, postingan dengan banyak balasan umumnya akan dilihat oleh lebih banyak orang dibandingkan postingan dengan balasan lebih sedikit.
Kita harus menggunakan logika di atas dan menyediakan algoritma caching berdasarkan logika bisnis aktual kita untuk meningkatkan tingkat cache hit. Mari kita simpan data yang sesuai dalam cache, bukan semua data, sesuai kemampuan perangkat keras kita.
Contoh negatifnya adalah: Bagaimanapun, situs blog besar, ketika sebuah artikel diminta oleh pengguna, ternyata artikel tersebut tidak ada di cache memori, sehingga dibaca dari database dan kemudian dibuang ke cache.
Anda tahu, ada banyak crawler sekarang. Selain itu, untuk situs yang ramah mesin pencari seperti blog, sebagian besar tekanan aksesnya berasal dari mesin pencari. Kunjungan ini biasanya berlangsung selama satu jam atau satu hari, dengan hanya beberapa atau bahkan satu permintaan untuk artikel tertentu, dan tidak pernah lagi. Tingkat keberhasilan metode caching di atas akan sangat rendah.
Seseorang mungkin bertanya di sini, Guo Hongjun, karena Anda tidak menyarankan saya untuk menyimpan konten blog ini dalam cache, tetapi bagaimana cara meningkatkan kinerja situs saya? Setidaknya saya harus memastikan bahwa situs blog saya tidak akan terlalu lambat merespons untuk permintaan pengguna.
Ada banyak solusi untuk masalah ini. Salah satu metode paling sederhana adalah menjadikan blog ini menjadi halaman Html statis, yang merupakan cache sistem file. Karena hard disk, sistem file dapat dipahami secara sederhana dapat diperluas tanpa batas. sehingga banyak Konten dengan hit rate rendah yang di-cache.
Jika halaman Anda memerlukan penilaian logika dinamis, Anda dapat menyimpan data ke dalam cache ke dalam file XML, lalu segmen server mengintegrasikan file XML ini, atau menyertakan file. Ini juga merupakan pendekatan yang bagus.
Setelah menjelaskan begitu banyak masalah tentang tingkat cache hit, mari kita rangkum secara singkat pandangan tentang tingkat cache hit:
Situs web kecil dapat menyimpan semua data dalam cache, dan umumnya tekanannya tidak akan besar, sehingga masalah tingkat cache hit dapat diabaikan.
Layanan besar tidak dapat menyimpan semua data dalam cache, tetapi hanya sebagian dari data. Saat ini, arsitek perlu merancang metode caching yang sesuai dengan logika bisnis untuk meningkatkan tingkat cache hit sebanyak mungkin.
Sebagian besar metode untuk meningkatkan hit rate terkait dengan logika bisnis dan memerlukan analisis terperinci atas masalah tertentu. Untuk data yang tidak dapat di-cache di memori, cara paling sederhana untuk meningkatkan kinerja adalah dengan menggunakan file caching.
Caching file dapat menyimpan seluruh konten ke dalam file statis; ia juga dapat menyimpan area seluruh halaman ke dalam file dan kemudian memasukkannya; juga dapat membuat serial suatu entitas menjadi file XML untuk cache.
Mari kita lihat beberapa aspek lain yang kurang penting dari caching:
Aktivitas siklus hidup cache
Konten yang tidak pernah kadaluwarsa atau berubah selamanya tidak boleh disimpan dalam cache. Cache merupakan penyimpanan sementara, bukan permanen, sehingga siklus hidup cache terbatas.
Pada gilirannya dapat melalui kegiatan-kegiatan berikut:
Masukkan tembolok. (Saat memasukkan cache, Anda mungkin perlu menentukan kebijakan kedaluwarsanya di masa mendatang. Jika tidak ditentukan, Anda perlu menggunakan kebijakan kedaluwarsa default sistem)
Dapatkan dari cache. Perhatikan bahwa masalah keamanan thread perlu ditangani saat ini.
Saat memperbarui cache, perhatikan bahwa Anda juga perlu mempertimbangkan masalah keamanan thread saat meninggalkan cache. Ini mungkin permintaan eksternal, atau cache mungkin menghapusnya berdasarkan kebijakan kedaluwarsa.
Kebijakan kedaluwarsa cache
Secara umum saya akan bertanya, strategi kedaluwarsa cache apa yang Anda temui di cache yang Anda hubungi?
Strategi kedaluwarsa yang paling umum adalah sebagai berikut:
Jika sudah lama tidak diminta, maka akan habis masa berlakunya. Yang paling umum adalah fungsi Bagian yang disediakan oleh ASP dan ASP.net. Faktanya, ini adalah cache.
Cache yang bergantung pada perubahan file akan kedaluwarsa setelah file diubah, biasanya Web.config dari situs WEB. Setelah file berubah, cache tidak hanya akan dimulai ulang, tetapi proses IIS juga akan melakukan rilis.
Berdasarkan hal ini, Anda mungkin melihat kebijakan kedaluwarsa cache untuk banyak dependensi. Misalnya kebijakan kedaluwarsa cache yang bergantung pada database.
Tentu saja, mungkin ada strategi kedaluwarsa yang lebih kompleks dalam logika bisnis. Dalam versi baru forum sistem poin CSDN, cache daftar posting akan menghapusnya menjadi 550 buah data ketika cache data daftar mencapai 600.
Contoh lainnya adalah cache postingan forum berbasis poin baru akan kedaluwarsa ketika tidak ada daftar yang merujuk ke postingan tersebut, dan postingan tersebut akan kedaluwarsa.
Masalah sinkronisasi cache
Menggunakan cache berarti beberapa salinan dari data yang sama dapat hidup berdampingan. Jika kode Anda tidak mempertimbangkan situasi tertentu, kedua data tersebut akan tidak konsisten. Di sinilah masalah akan terjadi.
Solusinya sederhana. Pikirkan baik-baik logika bisnis Anda dan situasi pemicu kode, dan jangan tinggalkan area apa pun yang belum mencapai titik terendah.
Metode sederhana dapat membuat logika kode Anda menjadi sangat kompleks.
Inilah sebabnya mengapa beberapa orang menyarankan agar Anda tidak menggunakan caching jika tidak diperlukan. Setelah Anda mulai menggunakan caching, Anda harus bersiap untuk menambahkan banyak kode untuk menangani sinkronisasi data.
Inisialisasi dan isi data cache
Terkadang setelah cache diinisialisasi, beberapa data perlu diisi terlebih dahulu ke dalam cache. Ini adalah operasi inisialisasi data cache.
Persoalan berikut perlu dipertimbangkan selama operasi inisialisasi data cache:
Berapa lama waktu yang diperlukan untuk inisialisasi? Secara umum, jika itu adalah sebuah situs, kami dapat menangani pekerjaan inisialisasi ini di Application_OnStart dari Global.asa. Inisialisasi umumnya tidak memakan waktu terlalu lama. Saat ini, kemampuan pengoptimalan kode kami sedang diuji.
Selama inisialisasi, data biasanya diimpor dalam batch, alih-alih memproses satu data dalam satu waktu selama penggunaan normal.
Meringkaskan:
Artikel ini memperkenalkan beberapa pandangan saya tentang caching tanpa membahas teknologi caching tertentu secara mendalam. Saya berharap melalui uraian artikel ini, orang-orang yang hanya mengetahui kegunaan caching namun belum memahami konsep caching dapat memiliki pemahaman awal.
http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx