การจัดเก็บเซสชันด้วย Redis ปลอดภัยแค่ไหน?


95

ฉันกำลังใช้ MySql เพื่อจัดเก็บเซสชันของฉัน ใช้งานได้ดี แต่ช้าไปหน่อย

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

มีใครประสบปัญหาดังกล่าวบ้าง?


1
เนื่องจาก Redis กล่าวว่ามีความทนทานเป็นทางเลือกดังนั้นฉันจึงบอกว่าปลอดภัยที่จะใช้หากคุณเลือกใช้ HDD ต่อเนื่อง อย่างไรก็ตามสำหรับข้อมูลเซสชัน - ฉันจะบันทึกลงใน RAM อย่างแน่นอน (หมายความว่าฉันไม่ต้องกังวลกับส่วนความทนทานของการทดสอบทั้งหมด) สิ่งที่เลวร้ายที่สุดที่ควรเกิดขึ้นในกรณีที่คุณสูญเสียข้อมูลเซสชันคือการที่ผู้ใช้ของคุณออกจากระบบ
NB

1
ใช่ แต่นี่เป็นส่วนหนึ่งของความต้องการของฉันผู้ใช้ไม่ควรต้องลงชื่อเข้าใช้อีกครั้งเนื่องจากข้อมูลผู้ใช้บางส่วนยังคงอยู่ตลอดเซสชันในขณะที่ผู้ใช้ไม่ได้ล็อกอิน (ผู้ใช้ทั่วไป) พวกเขาจะใช้ Redis RAM แต่เปิดใช้งานการบันทึกและ / หรือการสำรองข้อมูล หากเราทำบางช่วงหายไปก็ยอมรับได้
เทรน

1
ข้อกังวลหลักของฉันเกี่ยวกับการเขียนล่าช้าจะเกิดอะไรขึ้นหากผู้ใช้เข้าสู่ระบบและมีการเขียนเซสชันด้วยความล่าช้าเขาจะถูกเปลี่ยนเส้นทาง แต่ไม่ได้เข้าสู่ระบบ
เทรนต์

2
ลองนึกภาพไซต์อีคอมเมิร์ซหากเซสชันสูญหายรถเข็นปัจจุบันก็หายไปเช่นกันนั่นไม่น่ากลัว แต่อาจเป็นเรื่องแปลกสำหรับผู้ใช้ ผู้ใช้ที่เป็นแขกจะถูกระบุด้วยเซสชันเท่านั้นดังนั้นจึงไม่มีวิธีกู้คืนรถเข็นของพวกเขา
Boris Guéry

1
@ BorisGuéry - ไม่ใช่ว่าฉันไม่เห็นด้วย แต่ถ้าต้องเพิ่มประสิทธิภาพ - ต้องมีการประนีประนอมเมื่อมีสิ่งผิดปกติเกิดขึ้น ใช่เป็นเรื่องแปลกที่ผู้ใช้จะออกจากระบบโดยกะทันหันนั่นเป็นเรื่องที่แน่นอน - แต่คำถามคือคาดว่าจะเกิดขึ้นบ่อยแค่ไหน? หากเป็นปีละครั้งหรือสองครั้งที่โหนด Redis ทั้งหมดหยุดทำงานฉันก็ไม่เห็นเหตุผลที่จะลดประสิทธิภาพการทำงานในช่วงเวลาที่แยกไม่กี่ครั้งเมื่อคลัสเตอร์ทั้งหมดไม่พร้อมใช้งาน แต่นั่นเป็นแค่ฉัน
NB

คำตอบ:


150

Redis เหมาะสำหรับจัดเก็บเซสชัน การดำเนินการทั้งหมดจะดำเนินการในหน่วยความจำดังนั้นการอ่านและเขียนจะรวดเร็ว

ด้านที่สองคือความคงอยู่ของสถานะเซสชัน Redis ช่วยให้คุณมีความยืดหยุ่นอย่างมากในการที่คุณต้องการคงสถานะเซสชันไว้ในฮาร์ดดิสก์ของคุณ คุณสามารถไปที่http://redis.io/topics/persistenceเพื่อเรียนรู้เพิ่มเติม แต่ในระดับสูงนี่คือตัวเลือกของคุณ -

  1. หากคุณไม่สามารถสูญเสียเซสชันใด ๆ ได้ให้ตั้งค่าappendfsync alwaysในไฟล์กำหนดค่าของคุณ ด้วยเหตุนี้ Redis จึงรับประกันได้ว่าการดำเนินการเขียนใด ๆ จะถูกบันทึกลงในดิสก์ ข้อเสียคือการดำเนินการเขียนจะช้าลง
  2. หากคุณโอเคกับการสูญเสียเกี่ยวกับมูลค่า 1s appendfsync everysecของข้อมูลการใช้งาน สิ่งนี้จะให้ประสิทธิภาพที่ยอดเยี่ยมพร้อมการรับประกันข้อมูลที่สมเหตุสมผล

14

โดยทั่วไปมีสองประเภทหลักที่มีอยู่: async snapsnots และfsync(). เรียกว่า RDB และ AOF ตามลำดับ เพิ่มเติมเกี่ยวกับโหมดการติดตาในหน้าอย่างเป็นทางการ

การจัดการสัญญาณของกระบวนการดีมอนจะซิงค์กับดิสก์เมื่อได้รับ SIGTERM เป็นต้นดังนั้นข้อมูลจะยังคงอยู่ที่นั่นหลังจากรีบูต ฉันคิดว่าภูตหรือระบบปฏิบัติการต้องขัดข้องก่อนที่คุณจะเห็นความเสียหายของความสมบูรณ์แม้ว่าจะมีการตั้งค่าเริ่มต้น (สแน็ปช็อต RDB)

การตั้งค่า AOF ใช้ไฟล์ Append Only ที่บันทึกคำสั่งที่เซิร์ฟเวอร์ได้รับและสร้างฐานข้อมูลใหม่ตั้งแต่เริ่มต้นเมื่อเริ่มเย็นจากไฟล์ที่บันทึกไว้ นโยบายการซิงค์ดิสก์เริ่มต้นคือการล้างหนึ่งครั้งทุกวินาที (IIRC) แต่สามารถตั้งค่าให้ล็อกและเขียนทุกคำสั่งได้

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

ฉันใช้การตั้งค่า RDB เริ่มต้นด้วยตัวเองและบันทึกสแนปชอตไปยัง FTP ระยะไกล ฉันยังไม่เห็นความล้มเหลวที่ทำให้ข้อมูลสูญหายเลย ความล้มเหลวของฮาร์ดแวร์เฉียบพลันหรือไฟฟ้าดับเป็นไปได้มากที่สุด แต่ฉันโฮสต์บน VPS มีโอกาสเกิดขึ้นบ้าง :)


13

คำถามนี้เกี่ยวกับเซสชันแบบเรียลไทม์จริงๆและดูเหมือนว่าส่วนหนึ่งเกิดจากความเข้าใจผิดเกี่ยวกับวลี 'การดำเนินการเขียนล่าช้า' ในขณะที่รายละเอียดถูกล้อเลียนในความคิดเห็นในที่สุดฉันแค่อยากทำให้มันชัดเจนมากขึ้น ..

คุณจะไม่มีปัญหาในการใช้งานเซสชันแบบเรียลไทม์

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.