Redis Cluster กับ Redis Sentinel:คู่มือผู้เชี่ยวชาญที่ชัดเจนในการเลือกสถาปัตยกรรมที่เหมาะสม

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

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

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

ปัญหาหลัก Redis Sentinel แก้ไขได้

Redis Sentinel ได้รับการออกแบบมาเพื่อให้ความพร้อมใช้งานสูงสำหรับชุดข้อมูล Redis ชุดเดียว

ความรับผิดชอบหลักคือ:

• การตรวจสอบโหนดต้นแบบและแบบจำลอง Redis

• การตรวจจับความล้มเหลว

• ดำเนินการเฟลโอเวอร์อัตโนมัติ

• การอัปเดตลูกค้าเกี่ยวกับต้นแบบใหม่

Redis Sentinel ไม่แบ่งข้อมูล ยังคงมีอินสแตนซ์ Redis แบบลอจิคัลเพียงตัวเดียวที่เก็บคีย์ทั้งหมดไว้

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

วิธีการทำงานของ Redis Sentinel ภายใน

การตั้งค่า Redis Sentinel โดยทั่วไปประกอบด้วย:

• ผู้เชี่ยวชาญ Redis หนึ่งคน

• แบบจำลอง Redis หนึ่งรายการขึ้นไป

• กระบวนการ Sentinel หลายกระบวนการติดตามพวกเขา

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

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

ประเด็นสำคัญคือข้อมูลยังคงมีขนาดและรูปร่างเท่าเดิม ไม่มีการแจกจ่ายคีย์ซ้ำ

สิ่งที่ Redis Sentinel ไม่ทำ

Redis Sentinel ไม่ได้:

• เพิ่มความจุหน่วยความจำเกินกว่าโหนดเดียว

• เพิ่มปริมาณงานเขียนเกินกว่าหนึ่งคอร์

• แบ่งหรือกระจายข้อมูล

หากอินสแตนซ์ Redis ของคุณมีหน่วยความจำหรือ CPU ไม่เพียงพอ การเพิ่ม Sentinel ไม่ได้ช่วยอะไร Sentinel ทำให้ Redis พร้อมใช้งาน ไม่ใช่ใหญ่กว่า

ปัญหาหลักคลัสเตอร์ Redis ได้รับการแก้ไข

Redis Cluster เน้นความสามารถในการปรับขนาดมากกว่าความพร้อมใช้งานเพียงอย่างเดียว

มันแก้ได้:

• ขีดจำกัดหน่วยความจำของเครื่องเดียว

• ขีดจำกัดปริมาณงานที่เกิดจากการดำเนินการแบบเธรดเดียว

Redis Cluster แบ่งข้อมูลข้ามโหนดหลักหลายโหนด ต้นแบบแต่ละคนเป็นเจ้าของชุดย่อยของคีย์สเปซ

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

คลัสเตอร์ Redis ทำงานอย่างไรในระดับสูง

Redis Cluster แบ่งคีย์สเปซออกเป็นช่องแฮช 16,384 ช่อง

แต่ละโหนดหลักเป็นเจ้าของส่วนหนึ่งของช่องเหล่านี้ คีย์ถูกกำหนดให้กับช่องตามฟังก์ชันแฮช

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

หากต้นแบบล้มเหลว แบบจำลองตัวใดตัวหนึ่งจะถูกเลื่อนระดับโดยอัตโนมัติ คล้ายกับ Sentinel แต่สำหรับชิ้นส่วนนั้นเท่านั้น

การเปรียบเทียบรูปแบบความพร้อมใช้งาน

Redis Sentinel จัดเตรียม:

• มาสเตอร์ที่ใช้งานอยู่ครั้งละหนึ่งคน

• ชุดข้อมูลทั้งหมดบนโหนดเดียว

• เฟลโอเวอร์อัตโนมัติ

Redis Cluster ให้:

• ผู้เชี่ยวชาญหลายคน

• ข้อมูลกระจายข้ามโหนด

• เฟลโอเวอร์ในระดับชาร์ด

Sentinel ป้องกันความล้มเหลวของโหนด คลัสเตอร์ป้องกันทั้งความล้มเหลวของโหนดและขีดจำกัดความจุ

ลักษณะการปรับขนาด

Redis Sentinel ปรับขนาดในแนวตั้ง

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

คลัสเตอร์ Redis ปรับขนาดในแนวนอน

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

เมื่อโหนด Redis เดียวไม่เพียงพออีกต่อไป Sentinel เพียงอย่างเดียวก็ไม่เพียงพอ

ผลกระทบต่อการออกแบบแอปพลิเคชัน

Redis Sentinel มีความโปร่งใสสำหรับแอปพลิเคชันเป็นส่วนใหญ่

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

Redis Cluster ต้องใช้ไคลเอ็นต์ที่รับรู้คลัสเตอร์

การสมัครจะต้อง:

• จัดการการเปลี่ยนเส้นทาง

• เคารพขอบเขตของสล็อตแฮช

• หลีกเลี่ยงการดำเนินการแบบหลายคีย์ที่ไม่รองรับ

การใช้คลัสเตอร์ส่งผลกระทบอย่างมากต่อการออกแบบหลักและการสร้างแบบจำลองข้อมูล

การดำเนินการและธุรกรรมแบบหลายคีย์

ด้วย Redis Sentinel:

• คีย์ทั้งหมดอยู่บนมาสเตอร์ตัวเดียว

• การทำงานแบบมัลติคีย์ทำงานได้ตามปกติ

• ธุรกรรมและสคริปต์ Lua ทำงานตามที่คาดไว้

ด้วยคลัสเตอร์ Redis:

• คีย์อาจอยู่บนโหนดที่แตกต่างกัน

• การดำเนินการแบบหลายคีย์จะทำงานภายในช่องแฮชเดียวกันเท่านั้น

• การดำเนินการข้ามช่องล้มเหลว

ความแตกต่างเพียงอย่างเดียวนี้มักจะสร้างความตกใจครั้งใหญ่ให้กับทีมที่ย้ายไปยัง Redis Cluster

ความซับซ้อนในการดำเนินงาน

Redis Sentinel นำเสนอความซับซ้อนในการดำเนินงานระดับปานกลาง

คุณจัดการ:

• ต้นแบบและแบบจำลอง

• องค์ประชุมยาม

• ลักษณะการทำงานเมื่อเกิดข้อผิดพลาด

Redis Cluster นำเสนอความซับซ้อนที่มากขึ้นอย่างมาก

คุณจัดการ:

• ต้นแบบและแบบจำลองหลายรายการ

• การจัดสรรสล็อตและการปรับสมดุล

• การดำเนินการแบ่งกลุ่มใหม่

• ความเข้ากันได้ของไคลเอ็นต์

คลัสเตอร์ต้องการวินัยในการปฏิบัติงานที่แข็งแกร่งยิ่งขึ้น

เมื่อ Redis Sentinel เป็นตัวเลือกที่เหมาะสม

Redis Sentinel เหมาะสมอย่างยิ่งเมื่อ:

• ชุดข้อมูลพอดีกับเครื่องเครื่องเดียว

• ปริมาณงานการเขียนพอดีภายในคอร์เดียว

• จำเป็นต้องมีความพร้อมใช้งานสูง

• ตรรกะของแอปพลิเคชันขึ้นอยู่กับการทำงานของหลายคีย์

หลายระบบทำงานได้อย่างประสบความสำเร็จเป็นเวลาหลายปีด้วย Sentinel เพียงอย่างเดียว

เมื่อ Redis Cluster เป็นตัวเลือกที่เหมาะสม

Redis Cluster เหมาะสมเมื่อ:

• ความต้องการหน่วยความจำเกินโหนดเดียว

• ความต้องการปริมาณงานเพิ่มขึ้นอย่างต่อเนื่อง

• จำเป็นต้องปรับขนาดแนวนอน

• แอปพลิเคชันสามารถออกแบบสำหรับการแบ่งส่วนได้

คลัสเตอร์เป็นกลยุทธ์การปรับขนาด ไม่ใช่เพียงกลไกการเฟลโอเวอร์

ข้อผิดพลาดทั่วไปในการย้ายข้อมูล

ทีมมักจะ:

• ใช้คลัสเตอร์ Redis เร็วเกินไป

• สมมติว่า Sentinel และ Cluster สามารถใช้แทนกันได้

• ละเว้นผลกระทบจากการออกแบบที่สำคัญ

• ค้นพบข้อจำกัดของหลายคีย์ที่สายเกินไป

ข้อผิดพลาดเหล่านี้มักส่งผลให้มีการปรับโครงสร้างใหม่อย่างเร่งด่วน

กฎการตัดสินใจง่ายๆ

ใช้ Redis Sentinel เมื่อ:

• คุณต้องการความพร้อมใช้งานสูงโดยไม่ต้องเปลี่ยนโมเดลข้อมูลของคุณ

ใช้คลัสเตอร์ Redis เมื่อ:

• คุณต้องปรับขนาด Redis ให้เกินหนึ่งเครื่อง

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

สรุป

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