Pertanyaan Memcached vs. Redis?


Kami menggunakan aplikasi web Ruby Redis server untuk caching. Apakah ada titik untuk diuji Memcached sebagai gantinya?

Apa yang akan memberi kita kinerja yang lebih baik? Ada pro atau kontra antara Redis dan Memcached?

Poin yang perlu dipertimbangkan:

  • Kecepatan baca / tulis.
  • Penggunaan memori.
  • Disk I / O dumping.
  • Scaling.

1136
2018-05-11 20:52


asal


Jawaban:


Ringkasan (TL; DR)

Diperbarui 3 Juni 2017

Redis lebih kuat, lebih populer, dan lebih baik didukung daripada memcache. Memcached hanya dapat melakukan sebagian kecil dari hal-hal Redis dapat lakukan. Redis lebih baik meskipun fitur mereka tumpang tindih.

Untuk sesuatu yang baru, gunakan Redis.

Memcached vs Redis: Perbandingan Langsung

Kedua alat itu adalah penyimpanan data yang kuat, cepat, dan dalam memori yang berguna sebagai cache. Keduanya dapat membantu mempercepat aplikasi Anda dengan menyembunyikan hasil basis data, fragmen HTML, atau apa pun yang mungkin mahal untuk dihasilkan.

Poin yang Perlu Dipertimbangkan

Ketika digunakan untuk hal yang sama, di sini adalah bagaimana mereka membandingkan menggunakan "Points to Consider" pertanyaan asli:

  • Kecepatan baca / tulis: Keduanya sangat cepat. Tolak ukur bervariasi berdasarkan beban kerja, versi, dan banyak faktor lainnya, tetapi umumnya menunjukkan bahwa pemindahan ulang sama cepat atau hampir secepat memcache. Saya merekomendasikan redis, tetapi bukan karena memcache lambat. Ini bukan.
  • Penggunaan memori: Redis lebih baik.
    • memcached: Anda menentukan ukuran cache dan ketika Anda memasukkan item, daemon dengan cepat tumbuh menjadi sedikit lebih dari ukuran ini. Tidak pernah ada cara untuk merebut kembali ruang tersebut, tidak perlu memulai ulang memcache. Semua kunci Anda bisa kadaluwarsa, Anda bisa menyiram database, dan masih akan menggunakan potongan penuh RAM yang Anda konfigurasikan.
    • redis: Pengaturan ukuran maksimal terserah Anda. Redis tidak akan pernah menggunakan lebih dari yang seharusnya dan akan memberi Anda kembali memori yang tidak lagi digunakan.
    • Saya menyimpan 100,000 ~ 2KB string (~ 200MB) dari kalimat acak ke keduanya. Penggunaan RAM yang dipcached tumbuh menjadi ~ 225MB. Penggunaan Redis RAM tumbuh hingga ~ 228MB. Setelah disiram keduanya, redis turun menjadi ~ 29MB dan memcached tetap di ~ 225MB. Mereka juga sama efisien dalam cara mereka menyimpan data, tetapi hanya satu yang mampu mengambilnya kembali.
  • Disk I / O dumping: Kemenangan yang jelas untuk redis karena ini dilakukan secara default dan memiliki ketekunan yang sangat dapat dikonfigurasi. Memcached tidak memiliki mekanisme untuk membuang ke disk tanpa alat pihak ke-3.
  • Scaling: Keduanya memberi Anda banyak headroom sebelum Anda membutuhkan lebih dari satu instance sebagai cache. Redis termasuk alat untuk membantu Anda melampaui itu sementara memcached tidak.

memcache

Memcached adalah server cache mudah menguap sederhana. Ini memungkinkan Anda untuk menyimpan pasangan kunci / nilai yang nilainya terbatas menjadi string hingga 1 MB.

Ini bagus dalam hal ini, tetapi hanya itu yang dilakukannya. Anda dapat mengakses nilai-nilai tersebut dengan kunci mereka pada kecepatan yang sangat tinggi, sering menjenuhkan jaringan yang tersedia atau bahkan bandwidth memori.

Ketika Anda me-restart memcached data Anda hilang. Ini bagus untuk cache. Anda tidak boleh menyimpan sesuatu yang penting di sana.

Jika Anda membutuhkan kinerja tinggi atau ketersediaan tinggi, ada alat, produk, dan layanan pihak ke-3 yang tersedia.

redis

Redis dapat melakukan pekerjaan yang sama seperti memcached can, dan dapat melakukannya dengan lebih baik.

Redis bisa bertindak sebagai cache demikian juga. Dapat menyimpan pasangan kunci / nilai juga. Dalam redis mereka bahkan bisa hingga 512MB.

Anda dapat menonaktifkan kegigihan dan dengan senang hati akan kehilangan data Anda saat memulai ulang juga. Jika Anda ingin cache Anda bertahan hidup, Anda dapat melakukannya juga. Faktanya, itulah standarnya.

Ini super cepat juga, sering dibatasi oleh bandwidth jaringan atau memori.

Jika satu contoh redis / memcached tidak cukup kinerja untuk beban kerja Anda, redis adalah pilihan yang jelas. Redis termasuk dukungan klaster dan dilengkapi dengan alat ketersediaan tinggi (redis-sentinel) kanan "di kotak". Selama beberapa tahun terakhir redis juga muncul sebagai pemimpin yang jelas dalam perkakas pihak ke-3. Perusahaan seperti Redis Labs, Amazon, dan lainnya menawarkan banyak alat dan layanan redis yang berguna. Ekosistem di sekitar redis jauh lebih besar. Jumlah penyebaran skala besar sekarang mungkin lebih besar daripada untuk memcache.

Redis Superset

Redis lebih dari cache. Ini adalah server struktur data di memori. Di bawah ini Anda akan menemukan gambaran singkat tentang hal-hal Redis dapat dilakukan di luar menjadi cache kunci / nilai sederhana seperti memcache. Paling fitur redis adalah hal yang tidak dapat dilakukan oleh memcache.

Dokumentasi

Redis lebih baik didokumentasikan daripada memcache. Meskipun ini bisa subjektif, tampaknya menjadi lebih dan lebih benar sepanjang waktu.

redis.io adalah sumber daya yang mudah dinavigasi dengan fantastis. Ini memungkinkan Anda coba redis di browser dan bahkan memberi Anda contoh interaktif hidup dengan setiap perintah dalam dokumen.

Sekarang ada 2x banyak hasil stackoverflow untuk redis sebagai memcache. 2x banyak hasil Google. Contoh yang lebih mudah diakses dalam lebih banyak bahasa. Pengembangan lebih aktif. Pengembangan klien yang lebih aktif. Pengukuran ini mungkin tidak berarti banyak secara individual, tetapi dalam kombinasi mereka menggambarkan gambaran yang jelas bahwa dukungan dan dokumentasi untuk redis lebih besar dan lebih up-to-date.

Kegigihan

Secara default redis menyimpan data Anda ke disk menggunakan mekanisme yang disebut snapshotting. Jika Anda memiliki cukup RAM, ia dapat menulis semua data Anda ke disk dengan hampir tidak ada penurunan kinerja. Hampir gratis!

Dalam mode snapshot ada kemungkinan bahwa tabrakan mendadak dapat mengakibatkan sejumlah kecil data hilang. Jika Anda benar-benar harus memastikan tidak ada data yang hilang, jangan khawatir, redis juga ada di belakang Anda dengan mode AOF (Append Only File). Dalam mode mode ketekunan ini dapat disinkronkan ke disk seperti yang tertulis. Ini dapat mengurangi throughput penulisan maksimum untuk seberapa cepat disk Anda dapat menulis, tetapi seharusnya masih cukup cepat.

Ada banyak opsi konfigurasi untuk menyempurnakan ketekunan jika Anda membutuhkannya, tetapi defaultnya sangat masuk akal. Opsi ini mempermudah pengaturan redis sebagai tempat aman dan berlebih untuk menyimpan data. Ini adalah sebuah nyata database.

Banyak Tipe Data

Memcached terbatas pada string, tetapi Redis adalah server struktur data yang dapat melayani banyak tipe data yang berbeda. Ini juga menyediakan perintah yang Anda butuhkan untuk membuat sebagian besar dari tipe data tersebut.

String (perintah)

Nilai teks atau biner sederhana yang dapat mencapai 512 MB. Ini adalah satu-satunya tipe data yang mem-redis dan memcache share, meskipun string memcach dibatasi hingga 1MB.

Redis memberi Anda lebih banyak alat untuk memanfaatkan datatype ini dengan menawarkan perintah untuk operasi bitwise, manipulasi bit-level, dukungan floating point increment / decrement, range queries, dan operasi multi-key. Memcached tidak mendukung semua itu.

String berguna untuk semua jenis kasus penggunaan, itulah sebabnya memcached cukup berguna dengan tipe data ini saja.

Hash (perintah)

Hash adalah semacam penyimpanan nilai kunci dalam penyimpanan nilai kunci. Mereka memetakan antara bidang string dan nilai string. Field-> nilai peta menggunakan hash sedikit lebih efisien ruang daripada key-> value map menggunakan string reguler.

Hash berguna sebagai namespace, atau ketika Anda ingin mengelompokkan banyak kunci secara logis. Dengan hash Anda dapat mengambil semua anggota secara efisien, mengakhiri semua anggota bersama-sama, menghapus semua anggota bersama-sama, dll. Besar untuk setiap kasus penggunaan di mana Anda memiliki beberapa pasangan kunci / nilai yang perlu dikelompokkan.

Salah satu contoh penggunaan hash adalah untuk menyimpan profil pengguna di antara aplikasi. Sebuah redis hash disimpan dengan ID pengguna sebagai kunci akan memungkinkan Anda untuk menyimpan banyak bit data tentang pengguna yang diperlukan sambil menjaga mereka disimpan di bawah satu kunci. Keuntungan menggunakan hash alih-alih membuat serialisasi profil menjadi string adalah Anda dapat memiliki aplikasi yang berbeda untuk membaca / menulis bidang yang berbeda dalam profil pengguna tanpa harus khawatir tentang satu aplikasi yang menggantikan perubahan yang dibuat oleh orang lain (yang dapat terjadi jika Anda mengabadikan basi data).

Daftar (perintah)

Daftar Redis adalah kumpulan kumpulan string yang dipesan. Mereka dioptimalkan untuk memasukkan, membaca, atau menghapus nilai dari atas atau bawah (alias: kiri atau kanan) dari daftar.

Redis menyediakan banyak perintah untuk daftar leveraging, termasuk perintah untuk push / pop item, push / pop antara daftar, memotong daftar, melakukan kueri jangkauan, dll.

Daftar membuat antrean, atom, yang sangat tahan lama. Ini berfungsi baik untuk antrian pekerjaan, log, buffer, dan banyak kasus penggunaan lainnya.

Set (perintah)

Set adalah kumpulan nilai unik yang tidak diurutkan. Mereka dioptimalkan untuk membiarkan Anda dengan cepat memeriksa apakah nilai ada di set, dengan cepat menambah / menghapus nilai, dan mengukur tumpang tindih dengan perangkat lain.

Ini bagus untuk hal-hal seperti daftar kontrol akses, pelacak pengunjung unik, dan banyak hal lainnya. Sebagian besar bahasa pemrograman memiliki sesuatu yang serupa (biasanya disebut Kumpulan). Ini seperti itu, hanya didistribusikan.

Redis menyediakan beberapa perintah untuk mengatur set. Yang jelas seperti menambahkan, menghapus, dan memeriksa set ada. Jadi adalah perintah yang kurang jelas seperti popping / membaca item acak dan perintah untuk melakukan serikat dan persimpangan dengan set lainnya.

Set yang Diurutkan (perintah)

Set yang disortir juga merupakan kumpulan nilai unik. Yang ini, seperti namanya, diperintahkan. Mereka diperintahkan oleh suatu skor, kemudian secara leksikografis.

Tipe data ini dioptimalkan untuk pencarian cepat berdasarkan skor. Mendapatkan kisaran nilai tertinggi, terendah, atau apa pun di antaranya sangat cepat.

Jika Anda menambahkan pengguna ke set yang disortir bersama dengan skor tinggi mereka, Anda memiliki diri Anda sendiri sebagai pemimpin yang sempurna. Ketika skor tinggi baru masuk, tambahkan saja ke set lagi dengan skor tinggi mereka dan itu akan mengatur ulang kepemimpinan Anda. Juga bagus untuk melacak pengguna terakhir yang dikunjungi dan yang aktif dalam aplikasi Anda.

Menyimpan nilai dengan skor yang sama menyebabkannya dipesan secara leksikografis (pikirkan menurut abjad). Ini dapat berguna untuk hal-hal seperti fitur pelengkapan otomatis.

Banyak dari set yang diurutkan perintah mirip dengan perintah untuk set, terkadang dengan parameter skor tambahan. Juga termasuk adalah perintah untuk mengelola skor dan query dengan skor.

Geo

Redis memiliki beberapa perintah untuk menyimpan, mengambil, dan mengukur data geografis. Ini termasuk permintaan radius dan mengukur jarak antar titik.

Secara teknis, data geografis dalam redis disimpan dalam kumpulan yang diurutkan, jadi ini bukan jenis data yang benar-benar terpisah. Ini lebih merupakan perpanjangan di atas set yang diurutkan.

Bitmap dan HyperLogLog

Seperti halnya geo, ini bukan tipe data yang benar-benar terpisah. Ini adalah perintah yang memungkinkan Anda untuk memperlakukan data string seolah-olah itu adalah bitmap atau hyperloglog.

Bitmap adalah operator bit-level yang saya rujuk di bawah Strings adalah untuk. Tipe data ini adalah blok bangunan dasar untuk proyek seni kolaboratif terbaru milik reddit: r / Tempat.

HyperLogLog memungkinkan Anda untuk menggunakan jumlah ruang yang sangat kecil untuk menghitung nilai unik yang hampir tak terbatas dengan akurasi mengejutkan. Hanya dengan menggunakan ~ 16KB Anda dapat secara efisien menghitung jumlah pengunjung unik ke situs Anda, bahkan jika jumlah tersebut dalam jutaan.

Transaksi dan Atomicity

Perintah dalam redis adalah atom, yang berarti Anda dapat yakin bahwa segera setelah Anda menulis nilai untuk mem-redis nilai itu dapat dilihat oleh semua klien yang terhubung ke redis. Tidak perlu menunggu nilai itu menyebar. Secara teknis memcached adalah atom juga, tetapi dengan redis menambahkan semua fungsi ini di luar memcached itu patut dicatat dan agak mengesankan bahwa semua tipe data tambahan dan fitur juga atom.

Meskipun tidak sama dengan transaksi dalam basis data relasional, redis juga memiliki transaksi yang menggunakan "penguncian optimis" (MENONTON/MULTI/EXEC).

Pipelining

Redis menyediakan fitur yang disebut 'pipelining'. Jika Anda memiliki banyak perintah redis yang ingin Anda jalankan, Anda dapat menggunakan pipelining untuk mengirimnya untuk redis semua sekaligus bukan satu-pada-waktu.

Biasanya ketika Anda menjalankan perintah untuk redis atau memcache, setiap perintah adalah siklus permintaan / tanggapan yang terpisah. Dengan pipelining, redis dapat menyangga beberapa perintah dan menjalankannya sekaligus, merespons dengan semua tanggapan terhadap semua perintah Anda dalam satu balasan.

Ini dapat memungkinkan Anda untuk mencapai hasil yang lebih besar pada pengimporan massal atau tindakan lain yang melibatkan banyak perintah.

Pub / Sub

Redis punya perintah didedikasikan untuk fungsi pub / sub, memungkinkan redis bertindak sebagai penyiar pesan berkecepatan tinggi. Ini memungkinkan satu klien untuk mempublikasikan pesan ke banyak klien lain yang terhubung ke saluran.

Redis melakukan pub / sub serta hampir semua alat. Pialang pesan khusus seperti RabbitMQ mungkin memiliki kelebihan di bidang-bidang tertentu, tetapi fakta bahwa server yang sama juga dapat memberi Anda antrian yang tahan lama dan struktur data lain yang mungkin dibutuhkan pub / sub beban kerja Anda, Redis sering kali terbukti menjadi alat terbaik dan paling sederhana untuk pekerjaan tersebut.

Lua Scripting

Anda bisa memikirkannya skrip lua seperti redis's SQL sendiri atau prosedur yang tersimpan. Ini lebih dan kurang dari itu, tetapi analoginya kebanyakan bekerja.

Mungkin Anda memiliki perhitungan rumit yang ingin Anda lakukan. Mungkin Anda tidak mampu mengembalikan transaksi Anda dan membutuhkan jaminan setiap langkah proses kompleks akan terjadi secara atomis. Masalah-masalah ini dan banyak lagi dapat diselesaikan dengan lua scripting.

Seluruh skrip dijalankan secara atomik, jadi jika Anda dapat menyesuaikan logika Anda ke dalam skrip lua, Anda sering dapat menghindari mengotak-atik transaksi penguncian yang optimis.

Scaling

Seperti disebutkan di atas, redis termasuk dukungan yang dibangun untuk pengelompokan dan dibundel dengan alat ketersediaan tinggi sendiri yang disebut redis-sentinel.

Kesimpulan

Tanpa ragu saya akan merekomendasikan redis atas memcached untuk setiap proyek baru, atau proyek yang sudah ada yang belum menggunakan memcache.

Di atas mungkin terdengar seperti saya tidak suka memcache. Sebaliknya: itu adalah alat yang kuat, sederhana, stabil, matang, dan mengeras. Bahkan ada beberapa kasus penggunaan yang sedikit lebih cepat daripada redis. Saya suka memcached. Saya hanya tidak berpikir itu masuk akal untuk perkembangan masa depan.

Redis melakukan semua memcached, sering lebih baik. Keuntungan kinerja apa pun untuk memcache kecil dan beban kerja spesifik. Ada juga beban kerja yang redis akan lebih cepat, dan banyak lagi beban kerja yang dapat dilakukan redis yang memcached tidak bisa. Perbedaan kinerja yang kecil tampak kecil dalam menghadapi jurang raksasa dalam fungsi dan fakta bahwa kedua alat sangat cepat dan efisien mereka mungkin menjadi bagian terakhir dari infrastruktur Anda, Anda akan pernah khawatir tentang penskalaan.

Hanya ada satu skenario di mana memcache lebih masuk akal: di mana memcache sudah digunakan sebagai cache. Jika Anda sudah melakukan cache dengan memcached maka tetap menggunakannya, jika itu memenuhi kebutuhan Anda. Ini mungkin tidak sebanding dengan upaya untuk pindah ke redis dan jika Anda akan menggunakan redis hanya untuk caching mungkin tidak menawarkan manfaat yang cukup untuk menjadi layak waktu Anda. Jika memcached tidak memenuhi kebutuhan Anda, maka Anda mungkin harus pindah ke redis. Ini benar, apakah Anda perlu melampaui skala memcache atau Anda membutuhkan fungsionalitas tambahan.


1638
2018-06-29 06:54



Gunakan Redis jika

  1. Anda perlu secara selektif menghapus / kadaluarsa item dalam cache. (Anda membutuhkan ini)

  2. Anda membutuhkan kemampuan untuk query kunci dari tipe tertentu. eq. 'blog1: posting: *', 'blog2: categories: xyz: posting: *'. Oh ya! ini sangat penting. Gunakan ini untuk membatalkan jenis item cache tertentu secara selektif. Anda juga dapat menggunakan ini untuk memvalidasi cache fragmen, cache halaman, hanya objek AR dari tipe yang diberikan, dll.

  3. Ketekunan (Anda akan membutuhkan ini juga, kecuali Anda tidak keberatan dengan cache harus melakukan pemanasan setelah setiap restart. Sangat penting untuk objek yang jarang berubah)

Gunakan memcache jika

  1. Memcached memberi Anda judul!
  2. umm ... bergerombol? meh. jika Anda akan pergi sejauh itu, gunakan Varnish dan Redis untuk cache fragmen dan Objek AR.

Dari pengalaman saya, saya memiliki stabilitas yang jauh lebih baik dengan Redis daripada Memcached


128
2017-07-05 06:04



Memcached adalah multithread dan cepat.

Redis memiliki banyak fitur dan sangat cepat, tetapi sepenuhnya terbatas pada satu inti karena didasarkan pada loop peristiwa.

Kami menggunakan keduanya. Memcached digunakan untuk cache objek, terutama mengurangi beban baca pada database. Redis digunakan untuk hal-hal seperti set yang diurutkan yang berguna untuk menggulung data time-series.


76
2018-05-03 16:41



Ini terlalu lama untuk diposting sebagai komentar untuk jawaban yang sudah diterima, jadi saya menyebutnya sebagai jawaban terpisah

Satu hal yang juga perlu dipertimbangkan adalah apakah Anda berharap memiliki batas atas memori yang sulit pada instance cache Anda.

Karena redis adalah basis data nosql dengan banyak fitur dan caching hanya satu opsi yang dapat digunakan, ia mengalokasikan memori saat dibutuhkan - semakin banyak benda yang Anda letakkan di dalamnya, semakin banyak memori yang digunakannya. Itu maxmemory pilihan tidak ketat memaksakan penggunaan batas memori atas. Saat Anda bekerja dengan cache, kunci digusur dan kedaluwarsa; kemungkinan kunci Anda tidak semua ukuran yang sama, sehingga fragmentasi memori internal terjadi.

Secara default redis digunakan jemalloc pengalokasi memori, yang mencoba yang terbaik untuk menjadi memori-kompak dan cepat, tetapi itu adalah pengalokasi memori tujuan umum dan tidak dapat mengikuti banyak alokasi dan pemadaman objek terjadi pada tingkat tinggi. Karena itu, pada beberapa pola beban proses redis ternyata bisa mengeluarkan memori karena fragmentasi internal. Sebagai contoh, jika Anda memiliki server dengan 7 Gb RAM dan Anda ingin menggunakan redis sebagai cache LRU non-persistent, Anda mungkin menemukan bahwa proses redis dengan maxmemory diatur ke 5Gb dari waktu ke waktu akan menggunakan lebih banyak dan lebih banyak memori, akhirnya memukul batas total RAM sampai out-of-memory killer mengganggu.

memcached adalah lebih baik sesuai dengan skenario yang dijelaskan di atas, karena mengatur memori dengan cara yang sama sekali berbeda. memcached mengalokasikan satu bongkahan besar memori - semua yang dibutuhkannya - dan kemudian mengelola memori ini dengan sendirinya, menggunakan implementasinya sendiri pengalokasi slab. Selain itu, memcached berusaha keras untuk menjaga fragmentasi internal tetap rendah, karena sebenarnya menggunakan algoritma LRU per-slab, ketika pengusiran LRU dilakukan dengan ukuran objek yang dipertimbangkan.

Dengan demikian, memcached masih memiliki posisi yang kuat di lingkungan, di mana penggunaan memori harus ditegakkan dan / atau dapat diprediksi. Kami telah mencoba menggunakan redis stabil terbaru (2.8.19) sebagai pengganti memcached berbasis LRU non-persisten dalam beban kerja 10-15k op / s, dan memori bocor A LOT; beban kerja yang sama menabrak Amazon's ElastiCache contoh redis dalam satu atau dua hari karena alasan yang sama.


68
2018-03-02 11:13



Memcached baik menjadi toko kunci / nilai sederhana dan bagus dalam melakukan kunci => STRING. Ini membuatnya sangat bagus untuk penyimpanan sesi.

Redis bagus dalam melakukan key => SOME_OBJECT.

Itu benar-benar tergantung pada apa yang akan Anda letakkan di sana. Pemahaman saya adalah bahwa dalam hal kinerja mereka cukup impas.

Juga semoga beruntung menemukan tolok ukur obyektif apa pun, jika Anda menemukan beberapa dengan baik hati mengirimkannya kepada saya.


44
2018-05-11 23:27



Jika Anda tidak keberatan dengan gaya menulis yang kasar, Redis vs Memcached di blog Systoilet patut dibaca dari sudut pandang kegunaan, tetapi pastikan untuk membaca bolak-balik di komentar sebelum membuat kesimpulan tentang kinerja; ada beberapa masalah metodologis (single-threaded busy-loop tests), dan Redis telah melakukan beberapa perbaikan sejak artikel itu ditulis juga.

Dan tidak ada tautan patok yang lengkap tanpa membingungkan sedikit pun, jadi periksa juga beberapa tolok ukur yang saling bertentangan LiveJournal Dormondo dan Antirez Weblog.

Edit - seperti yang ditunjukkan Antirez, analisis Systoilet agak kurang dipahami. Bahkan di luar kekurangan single-threading, sebagian besar disparitas kinerja dalam benchmark tersebut dapat dikaitkan ke pustaka klien daripada throughput server. Tolok ukur di Antirez Weblog memang menyajikan lebih banyak apel-ke-apel (dengan mulut yang sama) perbandingan.


36
2018-06-15 22:38



Saya mendapat kesempatan untuk menggunakan baik memcached dan redis bersama-sama di proxy caching yang saya kerjakan, biarkan saya berbagi Anda di mana tepatnya saya telah menggunakan apa dan alasan di belakang yang sama ....

Redis>

1) Digunakan untuk mengindeks konten cache, melalui gugus. Saya memiliki lebih dari miliar kunci yang tersebar di kelompok redis, waktu respons Redis cukup kurang dan stabil.

2) Pada dasarnya, ini adalah kunci / nilai toko, jadi di mana pun di aplikasi Anda, Anda memiliki sesuatu yang mirip, seseorang dapat menggunakan redis dengan banyak mengganggu.

3) Redis persistensi, failover, dan cadangan (AOF) akan mempermudah pekerjaan Anda.

Memcache>

1) ya, memori yang dioptimalkan yang dapat digunakan sebagai cache. Saya menggunakannya untuk menyimpan konten cache yang sangat sering diakses (dengan 50 klik / detik) dengan ukuran kurang dari 1 MB.

2) Saya hanya mengalokasikan 2GB dari 16 GB untuk memcache itu juga ketika ukuran konten saya tunggal> 1MB.

3) Saat konten semakin mendekati batas, terkadang saya telah mengamati waktu respons yang lebih tinggi dalam statistik (bukan kasus dengan redis).

Jika Anda meminta pengalaman keseluruhan, Redis berwarna hijau karena mudah dikonfigurasi, jauh lebih fleksibel dengan fitur yang kuat dan stabil.

Selanjutnya, ada hasil pembandingan yang tersedia untuk ini link , di bawah ini beberapa higlight dari yang sama,

enter image description here

enter image description here

Semoga ini membantu!!


18
2017-10-16 10:20



Bonus lain adalah bahwa sangat jelas bagaimana memcache akan berperilaku dalam skenario caching, sementara redis umumnya digunakan sebagai datastore persisten, meskipun dapat dikonfigurasi untuk berperilaku seperti memcache alias evicting Item Least Recently Used saat mencapai max kapasitas.

Beberapa aplikasi yang saya kuasai hanya menggunakan keduanya untuk memperjelas bagaimana kami ingin data berperilaku - hal-hal di memcache, kami menulis kode untuk menangani kasus-kasus yang tidak ada di sana - hal-hal dalam redis, kami mengandalkannya ada di sana .

Selain itu Redis umumnya dianggap lebih unggul untuk sebagian besar kasus penggunaan yang lebih kaya fitur dan dengan demikian fleksibel.


11
2017-07-04 12:42



Uji. Jalankan beberapa tolok ukur sederhana. Untuk waktu yang lama, aku menganggap diriku badak sekolah tua karena aku kebanyakan memcached dan menganggap Redis sebagai anak baru.

Dengan perusahaan saya saat ini Redis digunakan sebagai cache utama. Ketika saya menggali beberapa statistik kinerja dan memulai pengujian, Redis, dalam hal kinerja, sebanding atau minimal lebih lambat dari MySQL.

Memcached, meskipun sederhana, meniup Redis keluar dari air sama sekali. Ini berskala lebih baik:

  • untuk nilai yang lebih besar (diperlukan perubahan dalam ukuran lempengan, tetapi berhasil)
  • untuk beberapa permintaan bersamaan

Juga, kebijakan pengusiran memcached dalam pandangan saya, jauh lebih baik dilaksanakan, sehingga secara keseluruhan lebih stabil waktu respon rata-rata sambil menangani lebih banyak data daripada cache dapat menangani.

Beberapa pembandingan mengungkapkan bahwa Redis, dalam kasus kami, berkinerja sangat buruk. Ini saya percaya ada hubungannya dengan banyak variabel:

  • jenis perangkat keras yang Anda jalankan Redis
  • jenis data yang Anda simpan
  • jumlah mendapat dan set
  • seberapa serentak aplikasi Anda
  • apakah Anda memerlukan penyimpanan struktur data

Secara pribadi, saya tidak berbagi tampilan Redis penulis tentang konkurensi dan multithreading.


11
2017-11-13 08:14



Itu tidak akan salah, jika kita mengatakan bahwa redis adalah kombinasi dari (cache + struktur data) sementara memcached hanyalah sebuah cache.


9
2018-06-16 05:45