เมื่อมาถึงผลิตภัณฑ์ที่ได้รับการพัฒนามานานกว่าทศวรรษ จึงไม่น่าแปลกใจเลยที่จะพบเทคโนโลยีที่ล้าสมัย แต่จะเกิดอะไรขึ้นถ้าภายในหกเดือนคุณต้องรักษาภาระให้สูงขึ้น 10 เท่าและค่าใช้จ่ายในการล้มจะเพิ่มขึ้นหลายร้อยเท่า? ในกรณีนี้ คุณต้องมี Highload Engineer ที่เจ๋งๆ แต่หากไม่มีสาวใช้ก็มอบหมายให้ฉันแก้ไขปัญหา ในส่วนแรกของบทความ ฉันจะบอกคุณว่าเราย้ายจาก Redis ไปยัง Redis-cluster ได้อย่างไร และในส่วนที่สอง ฉันจะให้คำแนะนำเกี่ยวกับวิธีการเริ่มใช้คลัสเตอร์ และสิ่งที่ต้องคำนึงถึงเมื่อใช้งาน

การเลือกใช้เทคโนโลยี

มันแย่ขนาดนั้นเลยเหรอ? เรดิสแยกจากกัน ( Redis แบบสแตนด์อโลน) ในการกำหนดค่าของ 1 master และ N Slaves? ทำไมฉันถึงเรียกมันว่าเทคโนโลยีล้าสมัย?

ไม่ เรดิสไม่ได้แย่ขนาดนั้น... อย่างไรก็ตาม มีข้อบกพร่องบางประการที่ไม่สามารถละเลยได้

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

• ประการที่สอง การมีปรมาจารย์เพียงคนเดียวนำไปสู่ปัญหาการแบ่งส่วน เราต้องสร้างคลัสเตอร์อิสระหลายคลัสเตอร์ “หลัก 1 ตัวและทาส N” จากนั้นจึงกระจายฐานข้อมูลไปยังเครื่องเหล่านี้ด้วยตนเอง และหวังว่าพรุ่งนี้ฐานข้อมูลใดฐานข้อมูลหนึ่งจะไม่ขยายตัวมากจนต้องย้ายไปยังอินสแตนซ์อื่น

มีตัวเลือกอะไรบ้าง?

• โซลูชันที่แพงและสมบูรณ์ที่สุดคือ Redis-Enterprise นี่คือโซลูชันแบบบรรจุกล่องพร้อมการสนับสนุนด้านเทคนิคเต็มรูปแบบ แม้ว่าจะดูดีในมุมมองทางเทคนิค แต่ก็ไม่เหมาะกับเราด้วยเหตุผลทางอุดมการณ์
• Redis-คลัสเตอร์ มีการสนับสนุนสำหรับการเปลี่ยนระบบหลักและการแบ่งส่วนเมื่อแกะกล่อง อินเทอร์เฟซแทบไม่ต่างจากเวอร์ชันปกติ ดูมีความหวัง เราจะพูดถึงข้อผิดพลาดในภายหลัง
• Tarantool, Memcache, Aerospike และอื่นๆ เครื่องมือทั้งหมดนี้ทำสิ่งเดียวกันค่อนข้างมาก แต่แต่ละคนก็มีข้อบกพร่องของตัวเอง เราตัดสินใจว่าจะไม่ใส่ไข่ทั้งหมดไว้ในตะกร้าใบเดียว เราใช้ Memcache และ Tarantool สำหรับงานอื่นๆ และเมื่อมองไปข้างหน้า ฉันจะบอกว่าในทางปฏิบัติของเรามีปัญหามากกว่านั้น

ลักษณะการใช้งาน

มาดูกันว่าปัญหาใดบ้างที่เราได้แก้ไขในอดีตด้วย Redis และฟังก์ชันใดบ้างที่เราใช้:

• แคชก่อนการร้องขอบริการระยะไกลเช่น 2GIS | โกลัง
  

  รับชุด MGET MSET "เลือกฐานข้อมูล"

• แคชก่อน MYSQL | PHP
  

  รับการตั้งค่า MGET MSET SCAN "คีย์ตามรูปแบบ" "เลือกฐานข้อมูล"

• ที่เก็บข้อมูลหลักสำหรับบริการการทำงานกับเซสชันและพิกัดไดรเวอร์ | โกลัง
  

  รับการตั้งค่า MGET MSET "เลือกฐานข้อมูล" "เพิ่มคีย์ GEO" "รับคีย์ GEO" สแกน

อย่างที่คุณเห็นไม่มีคณิตศาสตร์ที่สูงกว่า แล้วความยากลำบากคืออะไร? ลองดูแต่ละวิธีแยกกัน

วิธี
ลักษณะ
คุณสมบัติของคลัสเตอร์ Redis
การตัดสิน

รับชุด
เขียน/อ่านคีย์

เอ็มเก็ท เอ็มเก็ท
เขียน/อ่านหลายคีย์
คีย์จะอยู่บนโหนดที่แตกต่างกัน ไลบรารีสำเร็จรูปสามารถดำเนินการหลายอย่างได้ภายในโหนดเดียวเท่านั้น
แทนที่ MGET ด้วยไปป์ไลน์ของการดำเนินการ N GET

เลือกฐานข้อมูล
เลือกฐานที่เราจะใช้งาน
ไม่รองรับหลายฐานข้อมูล
รวมทุกอย่างไว้ในฐานข้อมูลเดียว เพิ่มคำนำหน้าให้กับคีย์

SCAN
ผ่านคีย์ทั้งหมดในฐานข้อมูล
เนื่องจากเรามีฐานข้อมูลเดียว การผ่านคีย์ทั้งหมดในคลัสเตอร์จึงมีราคาแพงเกินไป
รักษาค่าคงที่ภายในคีย์เดียวและทำ HSCAN บนคีย์นี้ หรือปฏิเสธโดยสิ้นเชิง

GEO
การดำเนินการด้วย geokey
Geokey ไม่ได้ถูกแบ่งส่วน

คีย์ตามรูปแบบ
ค้นหากุญแจตามรูปแบบ
เนื่องจากเรามีฐานข้อมูลเดียว เราจะค้นหาคีย์ทั้งหมดในคลัสเตอร์ แพงเกินไป
ปฏิเสธหรือรักษาค่าคงที่ ดังในกรณีของ SCAN

Redis กับ Redis-คลัสเตอร์

เราสูญเสียอะไรและเราได้อะไรเมื่อเปลี่ยนมาใช้คลัสเตอร์?

• ข้อเสีย: เราสูญเสียการทำงานของฐานข้อมูลหลายแห่ง
  • หากเราต้องการจัดเก็บข้อมูลที่ไม่เกี่ยวข้องเชิงตรรกะไว้ในคลัสเตอร์เดียว เราจะต้องสร้างไม้ค้ำยันในรูปแบบของคำนำหน้า
  • เราสูญเสียการดำเนินการ "ฐาน" ทั้งหมด เช่น SCAN, DBSIZE, CLEAR DB เป็นต้น
  • การดำเนินการหลายรายการกลายเป็นเรื่องยากมากขึ้นในการดำเนินการเนื่องจากอาจต้องเข้าถึงหลายโหนด
• ข้อดี:
  • การยอมรับข้อผิดพลาดในรูปแบบของการเฟลโอเวอร์หลัก
  • การแบ่งส่วนทางฝั่ง Redis
  • ถ่ายโอนข้อมูลระหว่างโหนดแบบอะตอมมิกและไม่มีการหยุดทำงาน
  • เพิ่มและกระจายความจุและโหลดโดยไม่ต้องหยุดทำงาน

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

เตรียมย้าย

เริ่มจากข้อกำหนดในการขนย้าย:

• มันควรจะไร้รอยต่อ การหยุดให้บริการโดยสมบูรณ์เป็นเวลา 5 นาทีไม่เหมาะกับเรา
• ควรปลอดภัยและค่อยเป็นค่อยไปเท่าที่เป็นไปได้ ฉันต้องการที่จะควบคุมสถานการณ์บางอย่าง เราไม่ต้องการทิ้งทุกอย่างในคราวเดียวและอธิษฐานผ่านปุ่มย้อนกลับ
• สูญเสียข้อมูลน้อยที่สุดเมื่อเคลื่อนย้าย เราเข้าใจดีว่าการย้ายแบบอะตอมมิกจะเป็นเรื่องยากมาก ดังนั้นเราจึงอนุญาตให้มีการยกเลิกการซิงโครไนซ์ระหว่างข้อมูลใน Redis แบบปกติและแบบคลัสเตอร์

การบำรุงรักษาคลัสเตอร์

ก่อนที่จะย้าย เราควรพิจารณาว่าจะสามารถรองรับคลัสเตอร์ได้หรือไม่:

• ชาร์ต. เราใช้ Prometheus และ Grafana เพื่อสร้างกราฟโหลด CPU, การใช้หน่วยความจำ, จำนวนไคลเอนต์, จำนวน GET, SET, การดำเนินการ AUTH ฯลฯ
• ความเชี่ยวชาญ. ลองนึกภาพว่าพรุ่งนี้คุณจะมีคลัสเตอร์ขนาดใหญ่ภายใต้ความรับผิดชอบของคุณ ถ้ามันพังไม่มีใครนอกจากคุณสามารถแก้ไขได้ หากเขาเริ่มชะลอตัว ทุกคนจะวิ่งเข้าหาคุณ หากคุณต้องการเพิ่มทรัพยากรหรือกระจายโหลดอีกครั้ง โปรดกลับมาหาคุณ เพื่อไม่ให้เป็นสีเทาเมื่ออายุ 25 ปี ขอแนะนำให้จัดเตรียมกรณีเหล่านี้และตรวจสอบล่วงหน้าว่าเทคโนโลยีจะทำงานอย่างไรภายใต้การดำเนินการบางอย่าง เรามาพูดถึงรายละเอียดเพิ่มเติมในส่วน "ความเชี่ยวชาญ"
• การตรวจสอบและการแจ้งเตือน เมื่อคลัสเตอร์พัง คุณคงอยากจะเป็นคนแรกที่รู้เกี่ยวกับคลัสเตอร์นั้น ที่นี่เราจำกัดตัวเองไว้ที่การแจ้งเตือนว่าโหนดทั้งหมดส่งคืนข้อมูลเดียวกันเกี่ยวกับสถานะของคลัสเตอร์ (ใช่ มันเกิดขึ้นแตกต่างออกไป) และปัญหาอื่นๆ จะสังเกตเห็นได้รวดเร็วยิ่งขึ้นด้วยการแจ้งเตือนจากฝ่ายบริการลูกค้าของ Redis

ที่ข้าม

เราจะเคลื่อนไหวอย่างไร:

• ก่อนอื่น คุณต้องเตรียมไลบรารีเพื่อทำงานกับคลัสเตอร์ เราใช้ go-redis เป็นพื้นฐานสำหรับเวอร์ชัน Go และเปลี่ยนแปลงเล็กน้อยเพื่อให้เหมาะกับตัวเราเอง เราใช้ Multi-methods ผ่านไปป์ไลน์ และยังแก้ไขกฎสำหรับคำขอซ้ำเล็กน้อยอีกด้วย เวอร์ชัน PHP มีปัญหามากขึ้น แต่ในที่สุดเราก็ตัดสินใจใช้ php-redis ได้ พวกเขาเพิ่งเปิดตัวการสนับสนุนคลัสเตอร์และดูดีในความคิดของเรา
• ถัดไปคุณจะต้องปรับใช้คลัสเตอร์เอง ซึ่งทำได้โดยใช้สองคำสั่งตามไฟล์กำหนดค่า เราจะหารือเกี่ยวกับการตั้งค่าโดยละเอียดด้านล่าง
• สำหรับการเคลื่อนย้ายทีละน้อย เราใช้โหมดแห้ง เนื่องจากเรามีไลบรารีสองเวอร์ชันที่มีอินเทอร์เฟซเดียวกัน (เวอร์ชันหนึ่งสำหรับเวอร์ชันปกติ และอีกเวอร์ชันสำหรับคลัสเตอร์) จึงไม่มีค่าใช้จ่ายใด ๆ ในการสร้าง wrapper ที่จะทำงานกับเวอร์ชันที่แยกจากกันและทำซ้ำคำขอทั้งหมดไปยังคลัสเตอร์แบบขนาน เปรียบเทียบคำตอบและเขียนความคลาดเคลื่อนในบันทึก (ในกรณีของเราใน NewRelic) ดังนั้น แม้ว่าเวอร์ชันคลัสเตอร์จะใช้งานไม่ได้ระหว่างการเปิดตัว การผลิตของเราจะไม่ได้รับผลกระทบ
• เมื่อเปิดตัวคลัสเตอร์ในโหมดแห้ง เราก็สามารถดูกราฟความคลาดเคลื่อนของการตอบสนองได้อย่างใจเย็น หากอัตราความผิดพลาดค่อยๆ เคลื่อนไปสู่ค่าคงที่เล็กน้อย แสดงว่าทุกอย่างเรียบร้อยดี เหตุใดจึงยังมีข้อขัดแย้งอยู่? เนื่องจากการบันทึกในเวอร์ชันแยกต่างหากจะเกิดขึ้นเร็วกว่าในคลัสเตอร์เล็กน้อย และเนื่องจากไมโครแล็ก ข้อมูลจึงอาจแตกต่างออกไป สิ่งที่เหลืออยู่คือการดูบันทึกความคลาดเคลื่อน และหากบันทึกทั้งหมดได้รับการอธิบายโดยความไม่เป็นอะตอมมิกของบันทึก เราก็สามารถเดินหน้าต่อไปได้
• ตอนนี้คุณสามารถสลับโหมดแห้งไปในทิศทางตรงกันข้ามได้ เราจะเขียนและอ่านจากคลัสเตอร์ และทำซ้ำเป็นเวอร์ชันแยกต่างหาก เพื่ออะไร? ในสัปดาห์หน้าผมอยากจะติดตามผลงานของคลัสเตอร์ หากปรากฎว่ามีปัญหาที่โหลดสูงสุดหรือเราไม่ได้คำนึงถึงสิ่งใด เราจะมีการย้อนกลับฉุกเฉินไปยังโค้ดเก่าและข้อมูลปัจจุบันเสมอด้วยโหมดแห้ง
• สิ่งที่เหลืออยู่คือการปิดการใช้งานโหมดแห้งและแยกเวอร์ชันแยกต่างหากออก

การตรวจสอบ

ขั้นแรก สั้น ๆ เกี่ยวกับการออกแบบคลัสเตอร์

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

ถัดไป จะต้องมี N โหนดหลักในคลัสเตอร์ แต่ละโหนดถือได้ว่าเป็นอินสแตนซ์ Redis ที่แยกจากกัน ซึ่งรู้ทุกอย่างเกี่ยวกับโหนดอื่นๆ ภายในคลัสเตอร์ แต่ละโหนดหลักมีจำนวนช่อง แต่ละช่องเป็นของโหนดหลักเพียงโหนดเดียวเท่านั้น ช่องทั้งหมดจะต้องมีการกระจายระหว่างโหนด หากไม่ได้จัดสรรช่องบางช่อง คีย์ที่จัดเก็บไว้ในช่องนั้นจะไม่สามารถเข้าถึงได้ เป็นการเหมาะสมที่จะรันแต่ละโหนดหลักบนเครื่องลอจิคัลหรือฟิสิคัลที่แยกจากกัน นอกจากนี้ โปรดจำไว้ว่าแต่ละโหนดทำงานบนคอร์เดียวเท่านั้น และหากคุณต้องการเรียกใช้อินสแตนซ์ Redis หลายอินสแตนซ์บนเครื่องลอจิคัลเดียวกัน ตรวจสอบให้แน่ใจว่าโหนดเหล่านั้นทำงานบนคอร์ที่แตกต่างกัน (เราไม่ได้ลองสิ่งนี้ แต่ตามทฤษฎีแล้ว มันควรจะได้ผล) . โดยพื้นฐานแล้ว โหนดหลักจะมีการแบ่งส่วนข้อมูลเป็นประจำ และโหนดหลักจำนวนมากขึ้นจะอนุญาตให้คำขอเขียนและอ่านขยายขนาดได้

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

ทีนี้เรามาพูดถึงปฏิบัติการที่สามารถทำได้ดีกว่ากัน

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

• สิ่งแรกและสำคัญที่สุดที่เราต้องการคือการทำงานของโหนดคลัสเตอร์ มันจะส่งคืนสถานะของคลัสเตอร์ แสดงรายการโหนด บทบาท การกระจายสล็อต ฯลฯ สามารถรับข้อมูลเพิ่มเติมได้โดยใช้ข้อมูลคลัสเตอร์และสล็อตคลัสเตอร์
• คงจะดีถ้าสามารถเพิ่มและลบโหนดได้ เพื่อจุดประสงค์นี้ มีการดำเนินการตอบสนองคลัสเตอร์และการลืมคลัสเตอร์ โปรดทราบว่าการลืมคลัสเตอร์จะต้องนำไปใช้กับทุกๆ โหนด ทั้งต้นแบบและแบบจำลอง และการตอบสนองของคลัสเตอร์จะต้องถูกเรียกบนโหนดเดียวเท่านั้น ความแตกต่างนี้อาจทำให้สับสนได้ ดังนั้นจึงควรเรียนรู้ก่อนใช้งานจริงกับคลัสเตอร์ของคุณ การเพิ่มโหนดทำได้อย่างปลอดภัยในการรบ และไม่ส่งผลต่อการทำงานของคลัสเตอร์ แต่อย่างใด (ซึ่งเป็นตรรกะ) หากคุณกำลังจะลบโหนดออกจากคลัสเตอร์ คุณควรตรวจสอบให้แน่ใจว่าไม่มีช่องว่างเหลืออยู่ (ไม่เช่นนั้นคุณอาจเสี่ยงต่อการสูญเสียการเข้าถึงคีย์ทั้งหมดบนโหนดนี้) นอกจากนี้ อย่าลบมาสเตอร์ที่มีทาส มิฉะนั้นจะมีการโหวตโดยไม่จำเป็นสำหรับมาสเตอร์คนใหม่ หากโหนดไม่มีสล็อตอีกต่อไป นี่เป็นปัญหาเล็กๆ แต่ทำไมเราจึงต้องมีตัวเลือกเพิ่มเติมหากเราสามารถลบทาสได้ก่อน
• หากคุณต้องการสลับตำแหน่งหลักและตำแหน่งทาสอย่างจริงจัง คำสั่งเฟลโอเวอร์ของคลัสเตอร์จะดำเนินการ เมื่อเรียกมันในการต่อสู้ คุณต้องเข้าใจว่าเจ้านายจะไม่ว่างระหว่างปฏิบัติการ โดยทั่วไปแล้วสวิตช์จะเกิดขึ้นในเวลาไม่ถึงหนึ่งวินาที แต่ไม่ใช่แบบอะตอมมิก คุณสามารถคาดหวังได้ว่าคำขอบางส่วนที่ส่งไปยังต้นแบบจะล้มเหลวในช่วงเวลานี้
• ก่อนที่จะลบโหนดออกจากคลัสเตอร์ ไม่ควรมีช่องว่างเหลืออยู่ เป็นการดีกว่าที่จะแจกจ่ายใหม่โดยใช้คำสั่งคลัสเตอร์ reshard ช่องจะถูกโอนจากต้นแบบหนึ่งไปยังอีกต้นแบบหนึ่ง การดำเนินการทั้งหมดอาจใช้เวลาหลายนาที ขึ้นอยู่กับปริมาณข้อมูลที่กำลังถ่ายโอน แต่กระบวนการถ่ายโอนมีความปลอดภัยและไม่ส่งผลกระทบต่อการทำงานของคลัสเตอร์แต่อย่างใด ดังนั้นข้อมูลทั้งหมดจึงสามารถถ่ายโอนจากโหนดหนึ่งไปยังอีกโหนดหนึ่งได้โดยตรงภายใต้ภาระงาน และไม่ต้องกังวลกับความพร้อมใช้งาน อย่างไรก็ตามยังมีรายละเอียดปลีกย่อยอีกด้วย ประการแรก การถ่ายโอนข้อมูลเชื่อมโยงกับภาระบางอย่างบนโหนดผู้รับและผู้ส่ง หากโหนดผู้รับโหลดบนโปรเซสเซอร์เป็นจำนวนมากแล้ว คุณไม่ควรโหลดโหนดนั้นโดยรับข้อมูลใหม่ ประการที่สอง ทันทีที่ไม่มีช่องเหลือบนต้นแบบที่ส่ง ทาสทั้งหมดจะไปยังต้นแบบที่ช่องเหล่านี้ถูกถ่ายโอนทันที และปัญหาก็คือทาสเหล่านี้ต้องการซิงโครไนซ์ข้อมูลพร้อมกัน และคุณจะโชคดีหากเป็นการซิงโครไนซ์บางส่วนแทนที่จะเป็นการซิงโครไนซ์โดยสมบูรณ์ คำนึงถึงสิ่งนี้และรวมการดำเนินการของการถ่ายโอนสล็อตและการปิดใช้งาน/การถ่ายโอนสเลฟ หรือหวังว่าคุณจะมีระยะประกันความปลอดภัยเพียงพอ
• คุณควรทำอย่างไรหากในระหว่างการถ่ายโอน คุณพบว่าช่องของคุณหายไปที่ไหนสักแห่ง? ฉันหวังว่าปัญหานี้จะไม่ส่งผลกระทบต่อคุณ แต่ถ้าเป็นเช่นนั้น แสดงว่ามีการดำเนินการแก้ไขคลัสเตอร์ อย่างน้อยที่สุด เธอจะกระจายช่องต่างๆ ไปตามโหนดต่างๆ แบบสุ่ม ฉันแนะนำให้ตรวจสอบการทำงานของมันโดยลบโหนดที่มีสล็อตแบบกระจายออกจากคลัสเตอร์ก่อน เนื่องจากข้อมูลในช่องที่ไม่ได้จัดสรรไม่พร้อมใช้งาน จึงสายเกินไปที่จะกังวลเกี่ยวกับปัญหาเกี่ยวกับความพร้อมใช้งานของช่องเหล่านี้ ในทางกลับกัน การดำเนินการจะไม่ส่งผลกระทบต่อสล็อตแบบกระจาย
• การดำเนินการที่มีประโยชน์อีกอย่างหนึ่งคือการตรวจสอบ ช่วยให้คุณเห็นรายการคำขอทั้งหมดที่ส่งไปยังโหนดแบบเรียลไทม์ ยิ่งกว่านั้น คุณยังสามารถ grep และดูว่ามีการจราจรที่จำเป็นหรือไม่

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

องค์ประกอบ

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

• หมดเวลา 0
  เวลาหลังจากที่การเชื่อมต่อที่ไม่ได้ใช้งานถูกปิด (เป็นวินาที) 0 - อย่าปิด
  ไม่ใช่ทุกห้องสมุดของเราที่สามารถปิดการเชื่อมต่อได้อย่างถูกต้อง เมื่อปิดใช้งานการตั้งค่านี้ เรามีความเสี่ยงที่จะถึงขีดจำกัดจำนวนลูกค้า ในทางกลับกัน หากเกิดปัญหาดังกล่าว การยกเลิกการเชื่อมต่อที่สูญเสียไปโดยอัตโนมัติจะปกปิดปัญหานั้น และเราอาจไม่ได้สังเกตเห็น นอกจากนี้ คุณไม่ควรเปิดใช้งานการตั้งค่านี้เมื่อใช้การเชื่อมต่อแบบคงอยู่
• บันทึก xy & ผนวกใช่เท่านั้น
  กำลังบันทึกสแนปชอต RDB
  เราจะหารือเกี่ยวกับปัญหา RDB/AOF โดยละเอียดด้านล่าง
• หยุดเขียนบน bgsave-error no & ทาสเสิร์ฟข้อมูลเก่าใช่
  หากเปิดใช้งาน หากสแนปช็อต RDB ใช้งานไม่ได้ ต้นแบบจะหยุดรับคำขอเปลี่ยนแปลง หากการเชื่อมต่อกับมาสเตอร์ขาดหาย สเลฟสามารถตอบสนองต่อคำขอต่อไปได้ (ใช่) หรือจะหยุดตอบสนอง (ไม่)
  เราไม่พอใจกับสถานการณ์ที่เรดิสกลายเป็นฟักทอง
• repl-ping-slave-ระยะเวลา 5
  หลังจากช่วงเวลานี้ เราจะเริ่มกังวลว่าต้นแบบเสียหาย และถึงเวลาที่จะดำเนินการขั้นตอนการเฟลโอเวอร์
  คุณจะต้องค้นหาจุดสมดุลระหว่างผลบวกลวงและการทริกเกอร์ความล้มเหลวด้วยตนเอง ในทางปฏิบัติของเราคือ 5 วินาที
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  เราสามารถจัดเก็บข้อมูลได้มากขนาดนี้ในบัฟเฟอร์สำหรับการจำลองที่ล้มเหลว หากบัฟเฟอร์หมด คุณจะต้องซิงโครไนซ์โดยสมบูรณ์
  การปฏิบัติแสดงให้เห็นว่าควรตั้งค่าให้สูงขึ้นจะดีกว่า มีสาเหตุหลายประการที่ทำให้แบบจำลองอาจเริ่มล่าช้า ถ้ามันล่าช้า เป็นไปได้มากว่าเจ้านายของคุณกำลังดิ้นรนเพื่อรับมือ และการซิงโครไนซ์แบบเต็มจะเป็นฟางเส้นสุดท้าย
• ลูกค้าสูงสุด 10000
  จำนวนลูกค้าขาจรสูงสุด
  จากประสบการณ์ของเรา ตั้งค่าให้สูงขึ้นจะดีกว่า Redis จัดการการเชื่อมต่อได้ 10 ครั้ง เพียงตรวจสอบให้แน่ใจว่ามีซ็อกเก็ตเพียงพอในระบบ
• maxmemory-นโยบายระเหย-ttl
  กฎสำหรับการลบคีย์เมื่อถึงขีดจำกัดหน่วยความจำที่มีอยู่
  สิ่งสำคัญในที่นี้ไม่ใช่กฎเกณฑ์ แต่เป็นความเข้าใจว่าสิ่งนี้จะเกิดขึ้นได้อย่างไร Redis ได้รับการยกย่องถึงความสามารถในการทำงานตามปกติเมื่อถึงขีดจำกัดของหน่วยความจำ

ปัญหา RDB และ AOF

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

• RDB-snapshot - สแนปชอตที่สมบูรณ์ของข้อมูลทั้งหมด ตั้งค่าโดยใช้การกำหนดค่า SAVE XY และอ่านว่า “บันทึกสแนปชอตทั้งหมดของข้อมูลทั้งหมดทุกๆ X วินาที หากมีการเปลี่ยนแปลงคีย์ Y เป็นอย่างน้อย”
• ไฟล์ต่อท้ายเท่านั้น - รายการการดำเนินการตามลำดับที่ดำเนินการ เพิ่มการดำเนินการขาเข้าใหม่ให้กับไฟล์ทุกๆ X วินาทีหรือทุกการดำเนินการ Y
• RDB และ AOF เป็นการรวมกันของสองรายการก่อนหน้า

วิธีการทั้งหมดมีข้อดีและข้อเสีย ฉันจะไม่แสดงรายการทั้งหมด ฉันจะดึงความสนใจไปยังจุดที่ไม่ชัดเจนในความคิดของฉัน

ขั้นแรก การบันทึกสแนปช็อต RDB จำเป็นต้องเรียก FORK หากมีข้อมูลจำนวนมาก สิ่งนี้อาจทำให้ Redis ทั้งหมดค้างเป็นเวลาสองสามมิลลิวินาทีถึงหนึ่งวินาที นอกจากนี้ ระบบจำเป็นต้องจัดสรรหน่วยความจำสำหรับสแน็ปช็อตดังกล่าว ซึ่งนำไปสู่ความจำเป็นในการเก็บ RAM ไว้สองเท่าบนเครื่องลอจิคัล: หากจัดสรร 8 GB สำหรับ Redis ก็ควรมี 16 GB บนเครื่องเสมือนด้วย มัน.

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

สองประเด็นนี้ทำให้เราคิดแล้วว่าเราต้องการข้อมูลนี้บนดิสก์จริง ๆ หรือไม่หากทาสทำทุกอย่างซ้ำแล้ว ข้อมูลสามารถสูญหายได้ก็ต่อเมื่อทาสทั้งหมดล้มเหลว และนี่คือปัญหาระดับ “ไฟไหม้ใน DC” เพื่อเป็นการประนีประนอม คุณสามารถเสนอให้บันทึกข้อมูลเฉพาะบนสเลฟได้ แต่ในกรณีนี้ คุณต้องตรวจสอบให้แน่ใจว่าสเลฟเหล่านี้จะไม่กลายเป็นมาสเตอร์ในระหว่างการกู้คืนระบบ (สำหรับสิ่งนี้ จะมีการตั้งค่าลำดับความสำคัญของสเลฟในการกำหนดค่า) สำหรับตัวเราเองในแต่ละกรณีเราคิดว่าจำเป็นต้องบันทึกข้อมูลลงดิสก์หรือไม่ และบ่อยครั้งคำตอบคือ "ไม่"

ข้อสรุป

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

ที่มา: will.com