Bagaimana untuk menyelesaikan masalah cache Redis

LevelDB ada di sini!

Ini ialah perpustakaan enjin storan NOSQL sumber terbuka oleh Google dan merupakan alat yang amat diperlukan dalam bidang storan teragih moden. Berdasarkannya, Facebook membangunkan satu lagi perpustakaan enjin storan NOSQL, RocksDB, yang mengikuti seni bina teknikal lanjutan LevelDB sambil juga menyelesaikan beberapa kelemahan LevelDB. Anda boleh membandingkan RocksDB dengan bom hidrogen, yang lebih berkuasa daripada LevelDB. Banyak pangkalan data sumber terbuka moden menggunakan RocksDB sebagai enjin storan asas, dan TiDB ialah salah satu contoh yang terkenal.

Tetapi mengapa saya perlu bercakap tentang LevelDB dan bukannya RocksDB? Sebabnya ialah seni bina teknikal LevelDB lebih ringkas, jelas dan mudah difahami. Jika kita memahami LevelDB dengan teliti terlebih dahulu dan kemudian melihat pada RocksDB, ia akan menjadi sangat mudah untuk difahami RocksDB hanyalah satu siri pengoptimuman berdasarkan LevelDB. Apabila kita memecahkan masalah RocksDB, kapal angkasa berkuasa nuklear TiDB sudah menyambut kita tidak jauh di hadapan.

Apa yang salah dengan cache Redis?

Apabila kami menggunakan Redis sebagai cache, biasanya masih terdapat pangkalan data berterusan yang merekodkan data sejuk dan panas yang lengkap. Ketekalan data antara Redis dan pangkalan data lapisan kegigihan dikawal oleh aplikasi itu sendiri. Apabila tiada data dalam cache, aplikasi perlu memuatkan data dari lapisan kegigihan dan memasukkannya ke dalam cache. Apabila kemas kini data berlaku, cache perlu tidak sah.

<code class="hljs javascript">function getUser(String userId) User {<br>  User user = redis.get(userId);<br>  if user == null {<br>    user = db.get(userId);<br>    if user != null {<br>      redis.set(userId, user);<br>    }<br>  }<br>  return user;<br>}<br><br>function updateUser(String userId, User user) {<br>  db.update(userId, user);<br>  redis.expire(userId);<br>}<br></code>

Rakan yang mempunyai pengalaman pembangunan dalam bidang ini tahu bahawa menulis kod sedemikian agak membosankan Semua kod perniagaan yang melibatkan caching perlu menambah bahagian logik ini.

Tegasnya, kami juga perlu mempertimbangkan isu konsistensi cache Contohnya, dalam kaedah kemas kiniUser, pangkalan data melakukan kemas kini dengan betul, tetapi redis yang dicache telah tidak sah disebabkan oleh kegelisahan rangkaian dan sebab-sebab lain data dalam cache Ia menjadi data tamat tempoh. Pembaca boleh menganggap bahawa walaupun susunan penyediaan cache dan pengemaskinian storan berterusan diterbalikkan, masalah lain mungkin masih timbul.

Situasi konkurensi yang tinggi dengan pelbagai proses juga boleh menyebabkan ketidakkonsistenan cache Contohnya, jika proses memanggil kaedah getUser() pada userId tertentu, ia perlu dimuatkan daripada pangkalan data kerana ia tidak berada dalam. cache. Hasilnya baru sahaja dimuatkan dan kami akan menyediakan cache Pada masa ini, kod memori fullgc dijeda untuk seketika Pada masa ini, proses lain memanggil kaedah kemas kini Pengguna untuk mengemas kini pangkalan data dan membatalkan cache (dalam sebenarnya, tiada cache dalam data cache). Kemudian proses sebelumnya akhirnya selesai fullgc dan mula menyediakan cache Pada masa ini, data yang telah tamat tempoh dicache.

Bagaimanakah LevelDB menyelesaikannya?

LevelDB menggabungkan cache Redis dan lapisan kegigihan menjadi satu, membantu anda mengendalikan cache dan lapisan kegigihan sekaligus. Dengan LevelDB, kod anda boleh dipermudahkan kepada yang berikut

<code class="hljs javascript">function getUser(String userId) User {<br>  return leveldb.get(userId);<br>}<br><br>function updateUser(String userId, User user) {<br>  leveldb.set(userId, user);<br>}<br></code>

Dan anda tidak perlu lagi bimbang tentang isu ketekalan cache sama ada kemas kini data LevelDB berjaya atau tidak, dan tiada keadaan Schrödinger perantaraan. Pengguna tidak perlu memberi perhatian kepada butiran ketekalan data kerana LevelDB menyepadukan cache memori dan fail cakera lapisan kegigihan secara dalaman.

Apakah sebenarnya LevelDB?

Kami menyebut sebelum ini bahawa ia adalah enjin storan bukan perhubungan, yang berbeza daripada konsep Redis. Redis ialah pangkalan data yang lengkap, manakala LevelDB hanyalah sebuah enjin. Jika pangkalan data itu dibandingkan dengan kereta sport mewah, enjin storan ialah enjinnya, iaitu teras dan jantungnya. Dengan enjin ini, kita boleh membungkusnya dengan beberapa siri aksesori dan hiasan untuk menjadi pangkalan data. Tetapi jangan memandang rendah aksesori dan hiasan Sangat sukar untuk mencapai tahap Pembungkusan LevelDB ke dalam pangkalan data yang ringkas dan mudah digunakan memerlukan terlalu banyak aksesori yang indah. LevelDB dan RocksDB telah wujud selama bertahun-tahun, tetapi sangat sedikit yang boleh membina pangkalan data peringkat pengeluaran yang lengkap berdasarkannya.

LevelDB boleh dilihat sebagai pangkalan data nilai kunci dalam memori. Ia menyediakan API Get/Set asas yang melaluinya kami boleh membaca dan menulis data dalam kod kami. Anda juga boleh menganggapnya sebagai HashMap lanjutan dengan saiz tanpa had Kami boleh memasukkan data Kunci/Nilai tanpa had ke dalamnya, selagi cakera boleh memuatkannya.

Oleh kerana ia hanya boleh dianggap sebagai pangkalan data dalam memori, data yang disimpan di dalamnya tidak boleh dikongsi antara proses atau mesin. Dalam bidang yang diedarkan, bagaimanakah LevelDB boleh menunjukkan bakatnya?

Untuk mencapai matlamat ini, API rangkaian perlu dibalut di atas pangkalan data dalam memori LevelDB. Apabila berbilang proses terletak pada mesin yang berbeza dan ingin mengakses sumber, mereka semua mesti mengaksesnya secara seragam melalui antara muka API rangkaian. Ini membentuk pangkalan data yang mudah. Gunakan protokol Redis untuk merangkum lapisan rangkaian, dan anda boleh menggunakan klien Redis untuk membaca dan menulis pangkalan data.

Jika kami ingin mempertimbangkan ketersediaan pangkalan data yang tinggi, kami boleh mengubahnya menjadi pangkalan data NOSQL yang diedarkan dengan struktur induk-hamba dengan menambahkan fungsi replikasi induk-hamba kepada pangkalan data yang berdiri sendiri di atas. Menambah lapisan proksi pemajuan (pengimbang beban seperti LVS, F5, dll.) di hadapan pangkalan data tuan-hamba boleh mencapai penukaran masa nyata pangkalan data tuan-hamba.

Jika kapasiti data yang anda perlukan terlalu besar sehingga cakera keras satu mesin tidak dapat menampungnya, maka mekanisme pemecahan data diperlukan untuk mengedarkan keseluruhan data pangkalan data kepada berbilang mesin. Setiap mesin hanya bertanggungjawab untuk membaca sebahagian daripadanya data tersebut. Terdapat banyak pilihan untuk pemecahan data Ia boleh dipecahkan melalui proksi pemajuan seperti Codis, atau ia boleh dipecahkan menggunakan mekanisme pemajuan klien seperti Redis-Cluster. Yang paling mudah dan paling mudah difahami ialah perpecahan proksi hadapan Codis.

Apabila jumlah data terus berkembang dan nod baharu diperlukan, data pada nod lama mesti dipindahkan sebahagiannya ke nod baharu Aksesori lanjutan baharu digunakan untuk mengurus pengimbangan dan pemindahan data -. peranti pengimbangan.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah cache Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!