Bila hendak memilih Redis

1. Untuk struktur data yang kompleks, redis lebih sesuai

Apabila nilai ialah struktur data yang kompleks seperti cincang, senarai, set, set tersusun, redis akan dipilih kerana. mc tidak dapat memenuhi keperluan ini.

Senario paling tipikal, senarai pesanan pengguna, mesej pengguna, senarai ulasan siaran, dsb.

2. Kegigihan, redis lebih sesuai

mc tidak dapat memenuhi keperluan kegigihan, jadi kita perlu memilih redis. Walau bagaimanapun, satu perkara yang perlu diberi perhatian ialah, adakah anda benar-benar memastikan bahawa anda menggunakan fungsi kegigihan Redis dengan betul?

Jangan sekali-kali menggunakan redis sebagai pangkalan data:

• Syot kilat biasa Redis tidak dapat menjamin bahawa data tidak akan hilang

• AOF redis akan mengurangkan kecekapan dan tidak dapat menyokong jumlah data yang besar; Menggunakan redis sebagai pangkalan data mungkin salah.

Apakah kebaikan dan keburukan menghidupkan fungsi pengawetan semasa meng-cache adegan? jika anda mendayakan fungsi pengawetan:

Kelebihannya ialah selepas redis digantung dan kemudian dimulakan semula, data panas boleh dipulihkan dengan cepat dalam ingatan, tanpa tekanan segera pada pangkalan data, dan tiada proses pemanasan awal cache.

Kelemahannya ialah semasa proses redis menggantung, jika terdapat pengubahsuaian data dalam pangkalan data, ia mungkin menyebabkan pangkalan data dan data redis tidak konsisten selepas redis dimulakan semula.

Oleh itu, untuk senario baca sahaja, atau untuk membenarkan beberapa senario perniagaan yang tidak konsisten, anda boleh cuba mendayakan fungsi pemejalan redis.

3. Untuk ketersediaan tinggi, redis lebih sesuai

Redis secara semula jadi menyokong fungsi pengelompokan dan boleh mencapai replikasi aktif dan pemisahan baca-tulis.

Redis secara rasmi juga menyediakan alat pengurusan kluster Sentinel, yang boleh merealisasikan pemantauan perkhidmatan tuan-hamba dan failover automatik. Semua ini telus kepada pelanggan dan tidak memerlukan perubahan program atau campur tangan manual. Suara Suara: Memcache, untuk mencapai ketersediaan tinggi, memerlukan pembangunan sekunder, seperti dwi bacaan dan dwi penulisan pada klien, atau penyegerakan kelompok pada pelayan.

Walau bagaimanapun, apa yang saya ingin ingatkan di sini ialah dalam kebanyakan senario perniagaan, adakah cache benar-benar perlu tersedia?

Dalam senario cache, cache miss adalah sering dibenarkan;

Cache dimatikan, dan data selalunya boleh dibaca melalui DB;
Jadi, anda perlu menganalisis perniagaan dengan teliti senario, ketersediaan tinggi dan sama ada ia benar Apakah permintaan utama untuk caching?

• Suara Suara: Dalam perniagaan pemesejan segera, status dalam talian pengguna mempunyai keperluan ketersediaan yang tinggi.

4. Kandungan yang disimpan agak besar, jadi lebih sesuai untuk memilih redis

Storan nilai memcache adalah sehingga 1M besar, hanya redis boleh digunakan.

Sudah tentu, berbanding dengan memcache, redis juga mempunyai beberapa "kelemahan" disebabkan oleh perbezaan dalam mekanisme pelaksanaan asas.

Senario 1: Disebabkan oleh perbezaan dalam mekanisme peruntukan memori, redis boleh menyebabkan pemecahan memori

Memcache menggunakan kumpulan memori yang telah diperuntukkan terlebih dahulu untuk mengurus memori, yang boleh menjimatkan memori masa peruntukan .

Redis digunakan untuk ruang buat sementara waktu, yang boleh menyebabkan pemecahan. Mulai saat ini, mc akan menjadi lebih pantas.

Senario 2: Disebabkan perbezaan dalam penggunaan memori maya, redis mungkin mengepam cakera dan menjejaskan prestasi

Memcache menyimpan semua data dalam memori fizikal.

Redis mempunyai mekanisme VM sendiri, yang secara teorinya boleh menyimpan lebih banyak data daripada memori fizikal Apabila data melebihi, swap akan dicetuskan untuk mengalirkan data sejuk ke cakera. Dari titik ini, apabila jumlah data adalah besar, mc akan menjadi lebih pantas. Suara Suara: Versi baharu redis telah dioptimumkan.

Kes 3: Disebabkan oleh perbezaan dalam model rangkaian, redis mungkin menjejaskan penjadualan IO disebabkan pengiraan CPU

Memcache menggunakan model pemultipleksan IO yang tidak menyekat, dan redis juga menggunakan model penggunaan semula IO yang tidak menyekat.

Tetapi kerana redis juga menyediakan beberapa fungsi pengisihan dan pengagregatan selain daripada storan KV, apabila melaksanakan fungsi ini, pengiraan CPU yang kompleks akan menyekat keseluruhan penjadualan IO. Dari sudut ini, memandangkan redis menyediakan lebih banyak fungsi, mc akan menjadi lebih pantas.

Senario 4: Disebabkan oleh perbezaan dalam model benang, sukar untuk redis menggunakan kesan khas berbilang teras untuk meningkatkan prestasi

memcache menggunakan berbilang benang, utas utama mendengar, dan sub-utas pekerja menerima permintaan dan melaksanakannya Semasa membaca dan menulis, mungkin terdapat konflik kunci.

Redis menggunakan satu utas Walaupun tiada konflik kunci, adalah sukar untuk menggunakan ciri berbilang teras untuk meningkatkan daya pemprosesan keseluruhan. Dari sudut ini, mc akan menjadi lebih pantas.

Senario 5: Disebabkan kekurangan auto-sharding, redis hanya boleh dikembangkan secara mendatar secara manual

Sama ada redis atau memcache, kluster pelayan tidak secara semula jadi menyokong pengembangan mendatar, dan perlu Pelanggan melakukan sharding, yang sebenarnya tidak mesra pemanggil. Ia akan menjadi lebih sempurna jika kluster pelayan boleh menyokong pengembangan mendatar.

Akhir sekali, ini mungkin salah satu sebab mengapa ramai orang menyukai redis: kod sumber sangat boleh dibaca dan kualiti kod sangat tinggi. Saya telah melihat kod sumber redis dan memcache Dari segi kebolehbacaan, redis ialah perisian dengan kod paling bersih yang pernah saya lihat, dan tiada perisian lain Mungkin kesederhanaan adalah niat asal redis reka bentuk. Menyusun redis tidak memerlukan konfigurasi, tidak perlu bergantung pada perpustakaan pihak ketiga, buat sahaja.

Bagi kod sumber memcache, ia mungkin menganggap terlalu banyak skalabiliti dan keserasian berbilang sistem Kod tersebut tidak jelas dan kelihatan susah payah.

Contohnya, untuk bahagian IO rangkaian, hanya 1-2 fail kod sumber redis diperlukan FD yang dihantar dari satu hujung ke hujung yang lain, melalui paip dan benang terutamanya mudah mengelirukan orang.

Atas ialah kandungan terperinci Bila hendak memilih Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!