การเรียนรู้การจำลอง Redis และความพร้อมใช้งานสูง:คู่มือปฏิบัติสำหรับสภาพแวดล้อมการผลิต

บทนำ

Redis รู้สึกมั่นคงเมื่อทุกอย่างแข็งแรง การทดสอบจริงเริ่มต้นเมื่อมีบางอย่างพัง โหนดขัดข้อง เครื่องเสมือนรีบูต คอนเทนเนอร์หายไป หรือปัญหาเครือข่ายแยกส่วนหนึ่งของระบบ

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

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

การจำลองแบบ Redis ทำอะไรได้บ้าง

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

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

การจำลองแบบทำงานอย่างไรภายใต้ประทุน

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

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

แนวทางนี้มีประสิทธิภาพและเรียบง่าย แต่นำมาซึ่งข้อดีข้อเสียที่สำคัญ การจำลองแบบเป็นแบบอะซิงโครนัสตามค่าเริ่มต้น ซึ่งหมายความว่าจะมีหน้าต่างเล็กๆ อยู่เสมอซึ่งมีข้อมูลอยู่บนต้นแบบแต่ยังไม่ได้อยู่บนแบบจำลอง

การจำลองแบบอะซิงโครนัสและความเสี่ยงในการสูญเสียข้อมูล

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

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

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

การใช้แบบจำลองเพื่อปรับขนาดการอ่าน

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

ซึ่งจะช่วยลดภาระบนต้นแบบและปรับปรุงปริมาณงานโดยรวม อย่างไรก็ตาม เนื่องจากการจำลองเป็นแบบอะซิงโครนัส แบบจำลองอาจส่งคืนข้อมูลเก่าเล็กน้อย

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

จะเกิดอะไรขึ้นเมื่อมาสเตอร์ล้มเหลว

การจำลองแบบเพียงอย่างเดียวไม่สามารถจัดการกับความล้มเหลวหลักได้ เมื่อต้นแบบหยุดทำงาน เรพลิกาจะยังคงซิงค์อยู่ แต่จะไม่เลื่อนระดับโดยอัตโนมัติหากไม่มีกลไกเฟลโอเวอร์ภายนอก

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

Redis Sentinel และความพร้อมใช้งานสูง

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

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

Sentinel แนะนำส่วนประกอบเพิ่มเติมและความซับซ้อน เพื่อให้มีประสิทธิภาพ โหนด Sentinel หลายโหนดต้องทำงานอยู่ Sentinel ตัวเดียวไม่เพียงพอสำหรับความพร้อมใช้งานสูงอย่างแท้จริง

วิธีที่ Sentinel ตัดสินใจที่จะล้มเหลว

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

การออกแบบนี้ปรับปรุงความน่าเชื่อถือแต่หมายถึงการเฟลโอเวอร์ไม่เกิดขึ้นทันที จะมีช่วงเวลาสั้นๆ เสมอเมื่อต้นแบบไม่พร้อมใช้งานและไม่มีการเปลี่ยนใหม่

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

คลัสเตอร์ Redis และความพร้อมใช้งานสูงในตัว

Redis Cluster รวมการจำลองและเฟลโอเวอร์เข้ากับระบบโดยตรง แต่ละชาร์ดมีต้นแบบและแบบจำลอง และการเฟลโอเวอร์จะเกิดขึ้นโดยอัตโนมัติเมื่อต้นแบบล้มเหลว

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

Redis Cluster ช่วยลดความพร้อมใช้งานสูงในขณะที่กำหนดขอบเขตทางสถาปัตยกรรมที่เข้มงวดยิ่งขึ้น

การเฟลโอเวอร์ไม่ได้หมายความว่าการหยุดทำงานเป็นศูนย์

ความเข้าใจผิดที่พบบ่อยคือ Redis เฟลโอเวอร์รับประกันเวลาหยุดทำงานเป็นศูนย์ ในความเป็นจริง การเฟลโอเวอร์นั้นรวดเร็วแต่ไม่เกิดขึ้นทันที

ในระหว่างการเฟลโอเวอร์ คำขอบางรายการจะล้มเหลวหรือต้องลองอีกครั้ง ระบบที่ได้รับการออกแบบมาอย่างดีคาดหวังถึงลักษณะการทำงานนี้และฟื้นตัวได้อย่างสวยงาม ระบบที่ออกแบบไม่ดีอาจหยุดทำงานหรือกระตุ้นให้เกิดความล้มเหลวแบบเรียงซ้อน

ความพร้อมใช้งานสูงช่วยเพิ่มความยืดหยุ่น ไม่ใช่ความสมบูรณ์แบบ

สมองแตกและความเสี่ยง

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

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

การเพิกเฉยรายละเอียดเหล่านี้เป็นสาเหตุของเหตุการณ์ที่เกิดขึ้นไม่บ่อยแต่รุนแรง

ความล่าช้าในการจำลองและผลกระทบด้านประสิทธิภาพ

ความล่าช้าในการจำลองมักจะน้อยแต่ไม่เคยเป็นศูนย์ ภายใต้ภาระการเขียนจำนวนมาก การจำลองอาจตามหลังต้นแบบได้

หากการเฟลโอเวอร์เกิดขึ้นในช่วงเวลาที่มีความล่าช้าสูง การสูญเสียข้อมูลจะเพิ่มขึ้น การตรวจสอบความล่าช้าของการจำลองเป็นสิ่งจำเป็นสำหรับระบบที่ความสมบูรณ์ของข้อมูลมีความสำคัญ

ความล่าช้าที่เพิ่มขึ้นอย่างกะทันหันมักส่งสัญญาณถึงปัญหาด้านประสิทธิภาพหรือทรัพยากรที่ซ่อนอยู่

เหตุใดการจำลองจึงไม่ใช่การสำรองข้อมูล

การจำลองแบบไม่ควรสับสนกับการสำรองข้อมูล หากข้อมูลบนต้นแบบถูกลบ การลบนั้นจะถูกจำลองแบบทันที

การสำรองข้อมูลป้องกันข้อผิดพลาดของมนุษย์และความเสียหายเชิงตรรกะ การจำลองแบบป้องกันความล้มเหลวของฮาร์ดแวร์หรือกระบวนการ จำเป็นต้องมีทั้งสองอย่างหาก Redis จัดเก็บข้อมูลอันมีค่า

ข้อผิดพลาด Redis HA ทั่วไป

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

ข้อผิดพลาดเหล่านี้ปรากฏซ้ำแล้วซ้ำอีกในรายงานการหยุดทำงานของโลกแห่งความเป็นจริง

การทดสอบความล้มเหลวเป็นส่วนหนึ่งของการออกแบบ

ความพร้อมใช้งานสูงที่ไม่เคยทดสอบจะมีอยู่บนกระดาษเท่านั้น ทีมควรจำลองความล้มเหลวเป็นประจำโดยการหยุดต้นแบบในสภาพแวดล้อมที่มีการควบคุม

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

แบบจำลองทางจิตที่ใช้งานได้จริงสำหรับ Redis HA

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

หาก Redis ล่มทำให้ระบบหยุดทำงานทั้งหมด ความพร้อมใช้งานสูงจะไม่สมบูรณ์

สรุป

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

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