Redis และ Memcache หรือแค่ Redis?


85

ฉันใช้ memcached สำหรับการแคชในแอป Rails 3 ของฉันผ่านRails.cacheอินเทอร์เฟซที่เรียบง่ายและตอนนี้ฉันต้องการประมวลผลงานเบื้องหลังด้วย redis และ resque

ฉันคิดว่ามันแตกต่างกันมากพอที่จะรับประกันการใช้ทั้งสองอย่าง แม้ว่าใน heroku จะมีค่าธรรมเนียมแยกต่างหากสำหรับการใช้ทั้ง memcached และ redis มันสมเหตุสมผลหรือไม่ที่จะใช้ทั้งสองอย่างหรือฉันควรย้ายไปใช้ redis เท่านั้น

ฉันชอบใช้ memcached ในการแคชเพราะคีย์ที่ใช้น้อยที่สุดจะถูกผลักออกจากแคชโดยอัตโนมัติและฉันไม่ต้องการให้ข้อมูลแคชคงอยู่ Redis ส่วนใหญ่เป็นของใหม่สำหรับฉัน แต่ฉันเข้าใจว่ามันคงอยู่ตามค่าเริ่มต้นและคีย์นั้นจะไม่หมดอายุในแคชโดยอัตโนมัติ

แก้ไข: แค่อยากให้คำถามของฉันชัดเจนขึ้น ฉันรู้ว่าเป็นไปได้ที่จะใช้เฉพาะ Redis แทนทั้งสองอย่าง ฉันเดาว่าฉันแค่อยากรู้ว่ามีข้อเสียเฉพาะในการทำเช่นนั้นหรือไม่? เมื่อพิจารณาถึงการใช้งานและโครงสร้างพื้นฐานมีเหตุผลใดบ้างที่ฉันไม่ควรใช้ Redis (กล่าวคือ memcached เร็วขึ้นสำหรับการแคชแบบง่ายหรือไม่) ฉันไม่พบอะไรที่ชัดเจนทั้งสองวิธี


5
สำหรับใครก็ตามที่พิจารณาสิ่งนี้: มีปลั๊กอินredis-storeสำหรับรางที่ให้คุณใช้ redis เป็นที่เก็บแคช
markquezada

คำตอบ:


49

สมมติว่าการย้ายจาก memcached ไปยัง redis สำหรับแคชที่คุณทำนั้นง่ายพอฉันจะใช้ redis เพียงเพื่อให้สิ่งต่างๆง่าย

ในการคงอยู่เป็นทางเลือกดังนั้นคุณสามารถใช้มันได้เหมือนกับ memcached หากนั่นคือสิ่งที่คุณต้องการ คุณอาจพบว่าการทำให้แคชของคุณคงอยู่นั้นมีประโยชน์ในการหลีกเลี่ยงการพลาดแคชจำนวนมากหลังจากรีสตาร์ท นอกจากนี้ยังมีการหมดอายุ - อัลกอริทึมแตกต่างจาก memcached เล็กน้อย แต่ไม่เพียงพอที่จะมีความสำคัญสำหรับวัตถุประสงค์ส่วนใหญ่ - ดูที่http://redis.io/commands/expireรายละเอียดที่


1
ขอบคุณสำหรับคำตอบและเอกสารที่เกี่ยวข้อง ฉันแก้ไขคำถามเล็กน้อยเพื่อให้ชัดเจนยิ่งขึ้นว่าฉันกำลังมองหาอะไร ฉันไม่ได้คิดถึงการคงอยู่ของแคชหลังจากรีสตาร์ท ... นั่นเป็นคุณสมบัติที่ดี (แม้ว่าฉันจะไม่แน่ใจว่ามันมีประโยชน์แค่ไหนที่คิดว่าจะใช้ redis ร่วมกับ heroku ก็ตาม)
markquezada

1
หากคุณต้องการเก็บบางรายการไว้ชั่วคราว (การแคชแฟรกเมนต์) และบางรายการคงอยู่ใน redis คุณต้องสร้างอินสแตนซ์ Redis แยกกันสองอินสแตนซ์หรือไม่
Brian Armstrong

1
ในขณะที่เราใช้ Redis สำหรับทั้งคิวงานและแคชเราเรียกใช้งานด้วยการกำหนดค่าที่แตกต่างกันโดยเฉพาะเหตุผลที่ @BrianArmstrong ระบุ แคชเป็นแบบชั่วคราวดังนั้นเราจึงกำหนดค่าได้โดยที่มันเร็ว แต่ก็โอเคที่จะสูญเสียสิ่งต่างๆในหน่วยความจำและวาง LRU สำหรับคิวเราไม่ต้องการเสียงานจริงๆดังนั้นเราจึงกำหนดค่าด้วยความคงอยู่เพื่อให้สามารถกู้คืนได้
jwadsack

@jwadsack คุณมีโพสต์ที่แสดงวิธีใช้การกำหนดค่านี้หรือไม่?
Marklar

1
@Marklar ความคิดที่ดี. ฉันทำตอนนี้: ballardhack.wordpress.com/2015/09/30/…
jwadsack

44

ฉันเป็นผู้เขียนredis-storeไม่จำเป็นต้องใช้คำสั่ง Redis โดยตรงเพียงแค่ใช้:expires_inตัวเลือกดังนี้:

ActionController::Base.cache_store = :redis_store, :expires_in => 5.minutes

ประโยชน์ของการใช้ Redis คือความคงทนและมีอัญมณีของฉันคือการที่คุณมีอยู่แล้วสำหรับร้านค้าRack::Cache, หรือRails.cacheI18n


ขอบคุณสำหรับการตอบกลับ Luca ฉันสมมติว่าคุณสามารถแทนที่: expires_in ได้โดยตรงเมื่อคุณต้องการจัดเก็บบางสิ่งอย่างต่อเนื่อง? ฉันเดาว่าคำถามนั้นเกี่ยวกับการใช้ฟังก์ชันประเภท memcached และการใช้ redis เป็นร้านค้าถาวรควบคู่กันไป
markquezada

3
ฉันไม่คิดว่ามันสมเหตุสมผลที่จะมีทั้ง memcached และ redis ควบคู่ไปด้วยเนื่องจากพวกเขาอยู่ในกลุ่ม NoSQL เดียวกัน: ทั้งสองเป็นร้านค้า ak / v Redis PROS: 1. เร็วกว่า memcached 2. คำสั่งที่ทรงพลังกว่า 3. ไม่จำเป็นต้องอุ่นแคช 4. มีประโยชน์สำหรับการแก้ปัญหาอื่น ๆ (เช่นการเข้าคิวด้วย Resque) ข้อตกลง: 1. คุณต้องมีอัญมณีภายนอก 2. หลังจากรีสตาร์ทเซิร์ฟเวอร์ ไม่ยอมรับคำสั่งขณะอ่านข้อมูลจากไฟล์ต่อท้าย Memcached PROS: อบใน Rails CONS: 1. ช้ากว่า Redis 2. การอุ่นแคช
Luca Guidi

3
@LucaGuidi ปัจจุบันฉันใช้ RedisStore สำหรับแคช Rails ของฉัน ฉันคิดไม่ออกว่าจะตั้งค่า URL Redis และค่าเริ่มต้น:expires_inอย่างไร คุณสามารถช่วย?
Chris Vincent

เช่นฉันหากคุณกำลังประสบปัญหาในการตั้งค่า:expires_inโดยใช้ redis_store โปรดดูที่stackoverflow.com/questions/20907247/…
Anirudhan J

19

ฉันเคยเห็นไซต์รางขนาดใหญ่สองสามแห่งที่ใช้ทั้ง Memcached และ Redis Memcached ใช้สำหรับสิ่งชั่วคราวที่ดีในการเก็บความทรงจำ แต่อาจสูญหาย / สร้างใหม่ได้หากจำเป็นและ Redis สำหรับพื้นที่จัดเก็บถาวร ทั้งสองใช้ในการโหลดออกจากฐานข้อมูลหลักสำหรับการอ่าน / เขียนการดำเนินการที่หนักหน่วง

รายละเอียดเพิ่มเติม:

Memcached:ใช้สำหรับการแคชเพจ / / การตอบกลับและสามารถเข้าถึงขีด จำกัด หน่วยความจำบน Memcached ได้เนื่องจาก LRU (ใช้งานน้อยที่สุด) เพื่อทำให้สิ่งเก่าหมดอายุและมักจะทำให้คีย์ที่เข้าถึงร้อนอยู่ในหน่วยความจำ สิ่งสำคัญคือทุกสิ่งใน Memcached สามารถสร้างขึ้นใหม่จากฐานข้อมูลได้หากจำเป็น (ไม่ใช่สำเนาของคุณเท่านั้น) แต่คุณสามารถทิ้งสิ่งต่างๆลงไปได้เรื่อย ๆ และ Memcached จะคิดว่าสิ่งใดถูกใช้บ่อยที่สุดและเก็บสิ่งเหล่านั้นไว้ในความทรงจำ คุณไม่ต้องกังวลเกี่ยวกับการนำสิ่งต่างๆออกจาก Memcached

redis:คุณใช้สิ่งนี้สำหรับข้อมูลที่คุณไม่ต้องการสูญเสียและมีขนาดเล็กพอที่จะใส่ลงในหน่วยความจำได้ ซึ่งมักจะรวมถึงงาน resque / sidekiq ตัวนับสำหรับการ จำกัด อัตราผลการทดสอบแยกหรืออะไรก็ตามที่คุณไม่ต้องการสูญเสีย / สร้างใหม่ คุณไม่ต้องการใช้หน่วยความจำเกินขีด จำกัด ที่นี่ดังนั้นคุณต้องระมัดระวังมากขึ้นเกี่ยวกับสิ่งที่คุณจัดเก็บและทำความสะอาดในภายหลัง

Redis เริ่มประสบปัญหาด้านประสิทธิภาพเมื่อเกินขีด จำกัด หน่วยความจำ (แก้ไขฉันถ้าฉันผิด) เป็นไปได้ที่จะแก้ปัญหานี้โดยการกำหนดค่า Redis ให้ทำหน้าที่เหมือน Memcached และ LRU จะหมดอายุดังนั้นจึงไม่ถึงขีด จำกัด หน่วยความจำ แต่คุณไม่ต้องการทำสิ่งนี้กับทุกสิ่งที่คุณเก็บไว้ใน Redis เช่นงาน resque ดังนั้นแทนที่จะมีคนใช้ค่าเริ่มต้น Rails.cache จึงตั้งค่าให้ใช้ Memcached (โดยใช้dalliอัญมณี) จากนั้นพวกเขาจะเก็บตัวแปรส่วนกลาง $ redis = ... ไว้แยกต่างหากเพื่อดำเนินการ redis

# in config/application.rb
config.cache_store = :dalli_store  # memcached

# in config/initializers/redis.rb
$redis = $redis = Redis.connect(url: ENV['REDIS_URL'])

อาจมีวิธีง่ายๆในการทำสิ่งนี้ทั้งหมดใน Redis โดยอาจมีอินสแตนซ์ Redis สองอินสแตนซ์ที่แยกจากกันหนึ่งอินสแตนซ์มีขีด จำกัด หน่วยความจำฮาร์ด LRU คล้ายกับ Memcache และอีกอันสำหรับพื้นที่เก็บข้อมูลถาวร? ฉันไม่เคยเห็นสิ่งนี้มาใช้ แต่ฉันเดาว่ามันน่าจะทำได้


15

ฉันจะพิจารณาตรวจสอบคำตอบของฉันในเรื่องนี้:

Rails และ caching มันง่ายไหมที่จะสลับระหว่าง memcache และ redis

โดยพื้นฐานแล้วจากประสบการณ์ของฉันฉันจะสนับสนุนให้แยกมันออกจากกัน: memcached สำหรับการแคชและการทำซ้ำสำหรับโครงสร้างข้อมูลและการจัดเก็บที่ต่อเนื่องมากขึ้น


แม้ว่าในตอนแรกฉันวางแผนที่จะรวมพวกเขาตามคำตอบเดิมสำหรับคำถามของฉัน แต่ฉันก็ได้ข้อสรุปเดียวกันโดยพื้นฐานแล้ว ฉันใช้ memcache สำหรับการแคชขั้นพื้นฐานและ redis สำหรับ resque
markquezada

6

ฉันถามทีมงานที่Redis Labs (ซึ่งเป็นผู้ให้บริการเสริมMemcached CloudและRedis Cloud ) เกี่ยวกับผลิตภัณฑ์ที่พวกเขาจะแนะนำสำหรับการแคช Rails พวกเขากล่าวว่าโดยทั่วไปแล้วพวกเขาจะแนะนำ Redis Cloud ซึ่ง Memcached Cloud ส่วนใหญ่นำเสนอเพื่อวัตถุประสงค์เดิมและชี้ให้เห็นว่าบริการ Memcached Cloud ของพวกเขานั้นสร้างขึ้นจาก Redis Cloud


จึงไม่จำเป็นต้องมีทั้ง memcached และ redis ตามที่กล่าวไว้ในคำตอบของ Brian? "ผู้คนมักจะเก็บ Rails.cache เริ่มต้นไว้เพื่อใช้ memcached (โดยใช้ dalli gem) จากนั้นพวกเขาก็เก็บตัวแปรส่วนกลาง $ redis = ... ไว้แยกต่างหากเพื่อดำเนินการ redis"
Marklar

4

ฉันไม่รู้ว่าคุณใช้มันเพื่ออะไร แต่จริงๆแล้วการใช้ทั้งสองอย่างอาจทำให้คุณได้เปรียบด้านประสิทธิภาพ: Memcached มีประสิทธิภาพที่ดีกว่าการทำงานในหลายคอร์มากกว่า Redis ดังนั้นการแคชข้อมูลที่สำคัญที่สุดด้วย Memcached และการเก็บส่วนที่เหลือไว้ใน Redis การใช้ประโยชน์จากความสามารถเป็นฐานข้อมูลสามารถเพิ่มประสิทธิภาพได้


1
นั่นไม่เป็นความจริงทั้งหมด - redis ใช้หลายอินสแตนซ์แทนที่จะเป็นหลายเธรดดังนั้นการเปรียบเทียบอินสแตนซ์ redis คอร์เดียวกับอินสแตนซ์ memcached แบบมัลติคอร์จึงไม่ใช่การทดสอบที่เกี่ยวข้องโดยเฉพาะ นอกจากนี้เมื่อมีการวัดประสิทธิภาพแสดงให้เห็นว่าทั้งสองระบบเร็วที่สุดความแตกต่างไม่น่าจะมีความสำคัญในโลกแห่งความเป็นจริง
Tom Clarkson

วิธีการแบบหลายกระบวนการของ redis จะปรับขนาดได้ดีกว่าในระบบมัลติคอร์มากกว่าวิธีการ (ค่าเริ่มต้น) ของ memcached ด้วย multi-threading: antirez.com/post/update-on-memcached-redis-benchmark.html
Ludger Sprenker

3
ข้อบกพร่องที่สำคัญของ Redis นี้ถูกมองข้ามไปมาก หากคุณกำลังมองหาการทำงานพร้อมกันสูงและมีคอร์จำนวนมาก Memcached สามารถเรียกใช้วงกลมรอบ ๆ Redis ได้ Sharding ไม่ใช่วิธีแก้ปัญหาที่ดีเนื่องจากคุณต้องใช้การแฮชที่สม่ำเสมอในแอปพลิเคชันของคุณและคุณจะไม่ได้รับการกระจายที่สมบูรณ์แบบระหว่างอินสแตนซ์ Redis ตัวอย่างเช่นหากชาร์ด A แคชการกำหนดค่าแอปพลิเคชันของคุณที่ใช้ในทุกคำขอชาร์ด A จะได้รับคำขอมากกว่าส่วนอื่น ๆ ที่ไม่ได้รับผลกระทบสำหรับทุกคำขอ
ColinM
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.