บทความนี้พูดถึงหลักการของ Zookeeper บรรณาธิการคิดว่ามันค่อนข้างดี ฉันจะแบ่งปันกับคุณสำหรับการอ้างอิงของคุณ รายละเอียดมีดังนี้:
คำนำ
Zookeeper เป็นบริการประสานงานแบบกระจายโอเพ่นซอร์สที่สร้างโดย Yahoo และเป็นการใช้งานโอเพนซอร์สของ Google Chubby แอปพลิเคชันแบบกระจายสามารถใช้ฟังก์ชั่นเช่นการเผยแพร่ข้อมูล/การสมัครสมาชิก, การปรับสมดุลโหลด, บริการการตั้งชื่อ, การประสานงาน/การแจ้งเตือนแบบกระจาย, การจัดการคลัสเตอร์, การเลือกตั้งหลัก, การล็อคแบบกระจายและคิวแบบกระจายตาม Zookeeper
1. บทนำ
Zookeeper เป็นบริการประสานงานแบบกระจายโอเพ่นซอร์สที่สร้างโดย Yahoo และเป็นการใช้งานโอเพนซอร์สของ Google Chubby แอปพลิเคชันแบบกระจายสามารถใช้ฟังก์ชั่นเช่นการเผยแพร่ข้อมูล/การสมัครสมาชิก, การปรับสมดุลโหลด, บริการการตั้งชื่อ, การประสานงาน/การแจ้งเตือนแบบกระจาย, การจัดการคลัสเตอร์, การเลือกตั้งหลัก, การล็อคแบบกระจายและคิวแบบกระจายตาม Zookeeper
2. แนวคิดพื้นฐาน
ส่วนนี้จะแนะนำแนวคิดหลักหลายประการของ Zookeeper แนวคิดเหล่านี้มีการอธิบายอย่างลึกซึ้งยิ่งขึ้นในภายหลังเกี่ยวกับ Zookeeper ดังนั้นจึงจำเป็นต้องเข้าใจแนวคิดเหล่านี้ล่วงหน้า
2.1 บทบาทของคลัสเตอร์
ใน Zookeeper มีตัวละครสามตัว:
ผู้นำ
ผู้ติดตาม
ผู้สังเกตการณ์
คลัสเตอร์ Zookeeper จะมีผู้นำเพียงคนเดียวในเวลาเดียวกันและคนอื่น ๆ จะเป็นผู้ติดตามหรือผู้สังเกตการณ์
การกำหนดค่าของ Zookeeper นั้นง่ายมาก ไฟล์การกำหนดค่า (zoo.cfg) ของแต่ละโหนดเหมือนกันและเฉพาะไฟล์ MYID เท่านั้นที่แตกต่างกัน ค่าของ MYID จะต้องเป็นส่วน {numeric} ของเซิร์ฟเวอร์ {numeric} ใน zoo.cfg
ตัวอย่างเนื้อหาไฟล์ zoo.cfg:
zookeeper
ดำเนินการสถานะ Zookeeper-Server บนเทอร์มินัลของเครื่องด้วย Zookeeper คุณสามารถดูว่าผู้ดูแลสัตว์ของโหนดปัจจุบันมีบทบาทอย่างไร (ผู้นำหรือผู้ติดตาม)
zookeeper
ดังที่ได้กล่าวมาแล้ว Node-20-104 เป็นผู้นำและ Node-20-103 เป็นผู้ติดตาม
Zookeeper มีเพียงสองบทบาท: ผู้นำและผู้ติดตามโดยค่าเริ่มต้นและไม่มีบทบาทผู้สังเกตการณ์ หากต้องการใช้โหมดผู้สังเกตการณ์เพิ่ม: peerType = observer ไปยังไฟล์กำหนดค่าของโหนดใด ๆ ที่ต้องการเป็นผู้สังเกตการณ์และเพิ่ม: ผู้สังเกตการณ์ไปยังสายการกำหนดค่าของเซิร์ฟเวอร์ที่กำหนดค่าในโหมดผู้สังเกตการณ์ในไฟล์การกำหนดค่าของเซิร์ฟเวอร์ทั้งหมด
server.1:localhost:2888:3888:observer
เครื่องจักรทั้งหมดในคลัสเตอร์ Zookeeper เลือกเครื่องที่เรียกว่า "ผู้นำ" ผ่านกระบวนการเลือกตั้งผู้นำ เซิร์ฟเวอร์ผู้นำให้บริการอ่านและเขียนไปยังไคลเอนต์
ทั้งผู้ติดตามและผู้สังเกตการณ์สามารถให้บริการการอ่านได้ แต่ไม่ใช่การเขียนบริการ ความแตกต่างเพียงอย่างเดียวระหว่างทั้งสองคือเครื่อง Observer ไม่ได้มีส่วนร่วมในกระบวนการเลือกตั้งผู้นำและไม่ได้มีส่วนร่วมในกลยุทธ์ "มากกว่าครึ่งหนึ่งของการเขียนที่ประสบความสำเร็จ" ในการดำเนินการเขียนดังนั้นผู้สังเกตการณ์สามารถปรับปรุงประสิทธิภาพการอ่านของคลัสเตอร์โดยไม่ส่งผลกระทบต่อประสิทธิภาพการเขียน
2.2 เซสชัน
เซสชันหมายถึงเซสชันลูกค้า ก่อนที่จะอธิบายเซสชันไคลเอนต์ให้เข้าใจการเชื่อมต่อไคลเอนต์ก่อน ใน Zookeeper การเชื่อมต่อไคลเอนต์หมายถึงการเชื่อมต่อ TCP ที่ยาวนานระหว่างไคลเอนต์และเซิร์ฟเวอร์ Zookeeper
พอร์ตบริการเริ่มต้นของ Zookeeper คือ 2181 เมื่อไคลเอนต์เริ่มต้นการเชื่อมต่อ TCP จะถูกสร้างขึ้นด้วยเซิร์ฟเวอร์ เริ่มต้นจากการสร้างการเชื่อมต่อครั้งแรกวงจรชีวิตของเซสชันลูกค้าก็เริ่มขึ้นเช่นกัน ผ่านการเชื่อมต่อนี้ไคลเอนต์สามารถรักษาเซสชันที่ถูกต้องด้วยเซิร์ฟเวอร์ผ่านการตรวจจับการเต้นของหัวใจและยังสามารถส่งคำขอไปยังเซิร์ฟเวอร์ Zookeeper และยอมรับการตอบกลับ ในขณะเดียวกันก็สามารถรับการแจ้งเตือนเหตุการณ์นาฬิกาจากเซิร์ฟเวอร์ผ่านการเชื่อมต่อนี้
ค่า SessionTimeOut ของเซสชันใช้เพื่อตั้งค่าเวลาหมดเวลาของเซสชันไคลเอนต์ เมื่อการเชื่อมต่อไคลเอ็นต์ถูกตัดการเชื่อมต่อเนื่องจากความดันเซิร์ฟเวอร์ที่มากเกินไปความล้มเหลวของเครือข่ายหรือการขาดการเชื่อมต่อที่ใช้งานของไคลเอนต์ตราบใดที่เซิร์ฟเวอร์บนคลัสเตอร์สามารถเชื่อมต่อได้ภายในเวลาที่ระบุโดยเซสชันทุรกันดารเซสชันที่สร้างขึ้นก่อนหน้านี้ยังคงถูกต้อง
2.3 Data Node (Znode)
เมื่อพูดถึงการกระจายโดยทั่วไป "โหนด" อ้างถึงแต่ละเครื่องที่สร้างคลัสเตอร์ โหนดข้อมูลใน Zookeeper หมายถึงหน่วยข้อมูลในรูปแบบข้อมูลที่เรียกว่า Znode Zookeeper จัดเก็บข้อมูลทั้งหมดในหน่วยความจำ แบบจำลองข้อมูลคือต้นไม้ (ต้นไม้ znode) เส้นทางหารด้วย Slashes (/) เป็น Znode เช่น/HBase/Master โดยที่ HBase และ Master เป็นทั้ง Znodes Znode แต่ละตัวจะบันทึกเนื้อหาข้อมูลของตัวเองและข้อมูลแอตทริบิวต์จะถูกบันทึกไว้
บันทึก:
Znode ที่นี่สามารถเข้าใจได้ว่าเป็นทั้งไฟล์ใน Unix และ Directory ใน UNIX เนื่องจาก Znode แต่ละตัวไม่เพียง แต่เขียนข้อมูลเอง (เทียบเท่ากับไฟล์ใน Unix) แต่ยังมีไฟล์หรือไดเรกทอรีระดับถัดไป (เทียบเท่ากับไดเรกทอรีใน Unix)
ใน Zookeeper Znode สามารถแบ่งออกเป็นสองประเภท: โหนดถาวรและโหนดชั่วคราว
โหนดถาวร
โหนดที่เรียกว่าแบบถาวรที่เรียกว่าเมื่อ znode นี้ถูกสร้างขึ้น znode จะถูกบันทึกไว้ใน Zookeeper เว้นแต่ znode จะถูกลบออกอย่างต่อเนื่อง
โหนดชั่วคราว
วงจรชีวิตของโหนดชั่วคราวถูกผูกไว้กับเซสชันไคลเอนต์ เมื่อเซสชันไคลเอนต์ล้มเหลวโหนดชั่วคราวทั้งหมดที่สร้างโดยไคลเอนต์นี้จะถูกลบออก
นอกจากนี้ Zookeeper ยังช่วยให้ผู้ใช้สามารถเพิ่มแอตทริบิวต์พิเศษ: ลำดับของแต่ละโหนด เมื่อโหนดถูกทำเครื่องหมายด้วยแอตทริบิวต์นี้เมื่อโหนดนี้ถูกสร้างขึ้น Zookeeper จะเพิ่มหมายเลขจำนวนเต็มโดยอัตโนมัติหลังจากโหนดซึ่งเป็นหมายเลขอัตโนมัติที่เก็บรักษาไว้โดยโหนดพาเรนต์
เวอร์ชัน 2.4
ข้อมูลจะถูกเก็บไว้ในแต่ละ Znode ของ Zookeeper สอดคล้องกับ Znode แต่ละตัว Zookeeper จะรักษาโครงสร้างข้อมูลที่เรียกว่า Stat สำหรับมัน STAT บันทึกข้อมูลสามเวอร์ชันของ ZNODE นี้คือเวอร์ชัน (รุ่น ZNODE ปัจจุบัน), cversion (รุ่นโหนดลูก znode ปัจจุบัน) และ aversion (รุ่น Znode ACL ปัจจุบัน)
2.5 ข้อมูลสถานะ
นอกเหนือจากการจัดเก็บเนื้อหาข้อมูลแล้ว Znode แต่ละตัวยังเก็บข้อมูลสถานะบางอย่างของ Znode เอง ใช้คำสั่ง GET เพื่อรับเนื้อหาและข้อมูลสถานะของ Znode บางอย่างในเวลาเดียวกัน ดังนี้:
zookeeper
ใน Zookeeper แอตทริบิวต์เวอร์ชันจะใช้ในการใช้ "การตรวจสอบการเขียน" ในกลไกการล็อคในแง่ดี (เพื่อให้แน่ใจว่าการทำงานของอะตอมของข้อมูลแบบกระจาย)
2.6 การดำเนินการธุรกรรม
ใน Zookeeper การดำเนินการที่สามารถเปลี่ยนสถานะของเซิร์ฟเวอร์ Zookeeper เรียกว่าการดำเนินการธุรกรรม โดยทั่วไปจะมีการดำเนินการเช่นการสร้างโหนดข้อมูลและการลบการอัปเดตเนื้อหาข้อมูลการสร้างเซสชันไคลเอนต์และความล้มเหลว สำหรับการร้องขอการทำธุรกรรมแต่ละครั้ง Zookeeper จะกำหนดรหัสธุรกรรมที่ไม่ซ้ำกันทั่วโลกซึ่งแสดงโดย ZXID ซึ่งมักจะเป็นหมายเลข 64 บิต ZXID แต่ละตัวสอดคล้องกับการดำเนินการอัปเดตซึ่ง Zookeeper สามารถระบุคำสั่งทั่วโลกได้ทางอ้อมซึ่งการดำเนินการตามคำขอการทำธุรกรรมเหล่านี้จะถูกประมวลผล
2.7 Watcher
Watcher (Event Listener) เป็นคุณสมบัติที่สำคัญมากใน Zookeeper ZooKeeper อนุญาตให้ผู้ใช้ลงทะเบียนผู้เฝ้าดูบางคนในโหนดที่ระบุและเมื่อมีการเรียกใช้เหตุการณ์เฉพาะบางเหตุการณ์เซิร์ฟเวอร์ Zookeeper จะแจ้งเหตุการณ์ไปยังไคลเอนต์ที่สนใจ กลไกนี้เป็นคุณสมบัติที่สำคัญของ Zookeeper ในการใช้บริการประสานงานแบบกระจาย
2.8 ACL
Zookeeper ใช้นโยบาย ACL (รายการควบคุมการเข้าถึง) เพื่อควบคุมสิทธิ์ Zookeeper กำหนด 5 สิทธิ์ต่อไปนี้
สร้าง: อนุญาตให้สร้างโหนดลูก
อ่าน: รับสิทธิ์ในรายการข้อมูลโหนดและรายการโหนดเด็ก
เขียน: อนุญาตให้อัปเดตข้อมูลโหนด
ลบ: ลบการอนุญาตของโหนดเด็ก
ผู้ดูแลระบบ: ตั้งค่าสิทธิ์สำหรับโหนด ACL
หมายเหตุ: สร้างและลบเป็นทั้งการควบคุมการอนุญาตสำหรับโหนดเด็ก
3. สถานการณ์แอปพลิเคชันทั่วไปของ Zookeeper
ZooKeeper เป็นกรอบการจัดการข้อมูลแบบกระจายและการประสานงานที่มีอยู่อย่างสูง จากการใช้งานอัลกอริทึม ZAB กรอบนี้สามารถมั่นใจได้ว่าข้อมูลความสอดคล้องในสภาพแวดล้อมแบบกระจาย นอกจากนี้ยังขึ้นอยู่กับคุณสมบัตินี้ที่ทำให้ Zookeeper เป็นเครื่องมือที่ทรงพลังในการแก้ปัญหาความสอดคล้องแบบกระจาย
3.1 การเผยแพร่ข้อมูลและการสมัครสมาชิก (ศูนย์การกำหนดค่า)
การเผยแพร่ข้อมูลและการสมัครสมาชิกศูนย์การกำหนดค่าที่เรียกว่าตามชื่อแนะนำคือผู้เผยแพร่เผยแพร่ข้อมูลไปยังโหนด Zookeeper สำหรับสมาชิกกับข้อมูลดังนั้นจึงบรรลุวัตถุประสงค์ของการรับข้อมูลแบบไดนามิกและตระหนักถึงการจัดการส่วนกลางและการอัปเดตข้อมูลการกำหนดค่าแบบไดนามิก
ในการพัฒนาระบบแอปพลิเคชันปกติของเราเรามักจะพบข้อกำหนดนี้: ข้อมูลการกำหนดค่าทั่วไปบางอย่างจำเป็นในระบบเช่นข้อมูลรายการเครื่องข้อมูลการกำหนดค่าฐานข้อมูล ฯลฯ ข้อมูลการกำหนดค่าทั่วโลกเหล่านี้มักจะมีคุณสมบัติสามประการต่อไปนี้
ปริมาณข้อมูลมักจะค่อนข้างเล็ก
เนื้อหาข้อมูลจะเปลี่ยนแปลงแบบไดนามิกที่รันไทม์
เครื่องจักรทั้งหมดในคลัสเตอร์มีการแชร์และการกำหนดค่าสอดคล้องกัน
ข้อมูลการกำหนดค่าทั่วโลกดังกล่าวสามารถเผยแพร่บน Zookeeper ช่วยให้ไคลเอนต์ (Cluster Machine) สมัครรับข้อความ
โดยทั่วไปมีสองโหมดการออกแบบสำหรับระบบการเผยแพร่/สมัครสมาชิกคือการผลักและดึง
Push: เซิร์ฟเวอร์ส่งการอัปเดตข้อมูลไปยังไคลเอนต์ที่สมัครรับข้อมูลทั้งหมดอย่างแข็งขัน
PULL: ลูกค้าเริ่มต้นคำขอเพื่อรับข้อมูลล่าสุด โดยปกติลูกค้าจะใช้วิธีการสำรวจและการดึงที่กำหนดเวลา
Zookeeper ใช้การผสมผสานระหว่างการผลักและการดึง ดังนี้:
ไคลเอนต์ต้องการให้เซิร์ฟเวอร์ลงทะเบียนโหนดที่ต้องการให้ความสนใจ เมื่อข้อมูลของโหนดเปลี่ยนแปลงเซิร์ฟเวอร์จะส่งการแจ้งเตือนเหตุการณ์ Watcher ไปยังไคลเอนต์ที่เกี่ยวข้อง หลังจากที่ลูกค้าได้รับการแจ้งเตือนข้อความนี้จะต้องไปที่เซิร์ฟเวอร์อย่างแข็งขันเพื่อรับข้อมูลล่าสุด (รวมกันด้วยการกดและดึง)
3.2 บริการการตั้งชื่อ
บริการการตั้งชื่อยังเป็นสถานการณ์ทั่วไปในระบบกระจาย ในระบบกระจายโดยใช้บริการการตั้งชื่อแอปพลิเคชันไคลเอนต์สามารถรับข้อมูลเช่นที่อยู่ของทรัพยากรหรือบริการผู้ให้บริการ ฯลฯ ตามชื่อที่ระบุ เอนทิตีที่มีชื่อมักจะเป็นเครื่องจักรในคลัสเตอร์บริการที่ให้บริการวัตถุระยะไกล ฯลฯ - เราสามารถเรียกชื่อพวกเขา (ชื่อ) โดยรวม
ในหมู่พวกเขาที่พบมากที่สุดคือรายการที่อยู่บริการในกรอบการบริการแบบกระจาย (เช่น RPC, RMI) ด้วยการสร้างโหนดต่อเนื่องใน ZookeePR มันเป็นเรื่องง่ายที่จะสร้างเส้นทางที่ไม่ซ้ำกันทั่วโลกซึ่งสามารถใช้เป็นชื่อได้
บริการการตั้งชื่อของ Zookeeper สร้าง ID ที่ไม่ซ้ำกันทั่วโลก
3.3 การประสานงาน/การแจ้งเตือนแบบกระจาย
Zookeeper มีการลงทะเบียนผู้เฝ้าดูที่ไม่เหมือนใครและกลไกการแจ้งเตือนแบบอะซิงโครนัสซึ่งสามารถตระหนักถึงการแจ้งเตือนและการประสานงานระหว่างเครื่องจักรที่แตกต่างกันและแม้แต่ระบบที่แตกต่างกันในสภาพแวดล้อมแบบกระจายจึงตระหนักถึงการประมวลผลการเปลี่ยนแปลงข้อมูลแบบเรียลไทม์ วิธีการใช้งานมักจะเป็นลูกค้าที่แตกต่างกันลงทะเบียน Znode เดียวกันบน ZK เพื่อฟังการเปลี่ยนแปลงใน Znode (รวมถึงเนื้อหาของ Znode และโหนดลูก) หาก Znode เปลี่ยนแปลงลูกค้าที่สมัครรับข้อมูลทั้งหมดสามารถรับการแจ้งเตือนผู้เฝ้าดูที่เกี่ยวข้องและทำการประมวลผลที่สอดคล้องกัน
การประสานงาน/การแจ้งเตือนแบบกระจายของ ZK เป็นวิธีการสื่อสารทั่วไประหว่างระบบกระจายและเครื่องจักร
3.3.1 การตรวจจับการเต้นของหัวใจ
กลไกการตรวจจับการเต้นของหัวใจระหว่างเครื่องจักรหมายความว่าในสภาพแวดล้อมแบบกระจายเครื่องจักรที่แตกต่างกัน (หรือกระบวนการ) จำเป็นต้องตรวจพบว่ากันและกันทำงานตามปกติหรือไม่ ตัวอย่างเช่นเครื่อง A จำเป็นต้องรู้ว่าเครื่อง B ทำงานตามปกติหรือไม่ ในการพัฒนาแบบดั้งเดิมเรามักจะตัดสินว่าโฮสต์สามารถ ping กันโดยตรงหรือไม่ หากมีความซับซ้อนมากขึ้นเราจะสร้างการเชื่อมต่อที่ยาวนานระหว่างเครื่องจักรและตระหนักถึงการตรวจจับการเต้นของหัวใจของเครื่องจักรระดับบนผ่านกลไกการตรวจจับการเต้นของหัวใจโดยธรรมชาติของการเชื่อมต่อ TCP นี่เป็นวิธีการตรวจจับการเต้นของหัวใจที่พบบ่อยมาก
ลองมาดูวิธีการใช้ ZK เพื่อใช้การตรวจจับการเต้นของหัวใจระหว่างเครื่องกระจาย (กระบวนการ)
ขึ้นอยู่กับลักษณะของโหนดชั่วคราวของ ZK กระบวนการที่แตกต่างกันสามารถสร้างโหนดเด็กชั่วคราวภายใต้โหนดที่ระบุใน ZK กระบวนการที่แตกต่างกันสามารถตัดสินได้โดยตรงว่ากระบวนการที่สอดคล้องกันนั้นมีชีวิตอยู่บนโหนดเด็กชั่วคราวนี้หรือไม่ ด้วยวิธีนี้การตรวจจับและระบบที่ตรวจพบไม่จำเป็นต้องเกี่ยวข้องโดยตรง แต่เกี่ยวข้องกับโหนดบางอย่างบน ZK ซึ่งลดการมีเพศสัมพันธ์ของระบบอย่างมาก
3.3.2 รายงานความคืบหน้าการทำงาน
ในระบบการกระจายงานทั่วไปโดยปกติหลังจากงานแจกจ่ายไปยังเครื่องจักรที่แตกต่างกันเพื่อดำเนินการมีความจำเป็นที่จะต้องรายงานความคืบหน้าของการดำเนินงานไปยังระบบการแจกจ่ายแบบเรียลไทม์ เวลานี้สามารถทำได้ผ่าน ZK เลือกโหนดบน ZK และไคลเอนต์งานแต่ละตัวจะสร้างโหนดเด็กชั่วคราวภายใต้โหนดนี้เพื่อให้สามารถทำได้ทั้งสองฟังก์ชั่น:
ตรวจสอบว่าเครื่องทำงานมีชีวิตอยู่ได้หรือไม่โดยการตัดสินว่ามีโหนดชั่วคราวอยู่หรือไม่
เครื่องแต่ละคนจะเขียนความคืบหน้าการดำเนินงานของงานไปยังโหนดชั่วคราวนี้แบบเรียลไทม์เพื่อให้ระบบกลางสามารถรับความคืบหน้าในการปฏิบัติงานแบบเรียลไทม์
3.4 การเลือกตั้งต้นแบบ
การเลือกตั้งระดับปริญญาโทอาจกล่าวได้ว่าเป็นสถานการณ์แอปพลิเคชันทั่วไปของ Zookeeper ตัวอย่างเช่นการเลือกตั้ง namenode ที่ใช้งานอยู่ใน HDFS การเลือกตั้งของ ResourceManager ที่ใช้งานอยู่ในเส้นด้ายและการเลือกตั้ง HMASTER ที่ใช้งานอยู่ใน HBASE
ในการตอบสนองต่อความต้องการของการเลือกตั้งหลักเรามักจะเลือกคุณสมบัติคีย์หลักในฐานข้อมูลเชิงสัมพันธ์ทั่วไปที่จะนำไปใช้: หากเครื่องจักรที่กลายเป็นอาจารย์แทรกบันทึกรหัสคีย์หลักเดียวกันลงในฐานข้อมูลฐานข้อมูลจะช่วยให้เราทำการตรวจสอบความขัดแย้งหลัก
การอาศัยคุณลักษณะหลักหลักของฐานข้อมูลเชิงสัมพันธ์สามารถตรวจสอบให้แน่ใจว่าอาจารย์เพียงคนเดียวได้รับการเลือกตั้งในคลัสเตอร์
แต่ฉันควรทำอย่างไรถ้าอาจารย์ที่ได้รับการเลือกตั้งในปัจจุบันตายไป? ใครจะบอกฉันว่าอาจารย์ตาย? เห็นได้ชัดว่าฐานข้อมูลเชิงสัมพันธ์ไม่สามารถแจ้งให้เราทราบถึงเหตุการณ์นี้ได้ แต่ Zookeeper ทำได้!
การใช้ความสอดคล้องที่แข็งแกร่งของ Zookeepr สามารถมั่นใจได้ว่าการสร้างโหนดสามารถมั่นใจได้ว่าเป็นเอกลักษณ์ของโลกในการแพร่กระจายที่สูงในระดับสูงนั่นคือ Zookeeper จะทำให้มั่นใจได้ว่าลูกค้าไม่สามารถสร้าง Znode ที่มีอยู่ได้
กล่าวคือหากลูกค้าหลายรายร้องขอให้สร้างโหนดชั่วคราวเดียวกันในเวลาเดียวกันคุณสามารถสร้างคำขอลูกค้าได้สำเร็จในที่สุด การใช้คุณสมบัตินี้การเลือกตั้งหลักสามารถทำได้อย่างง่ายดายในสภาพแวดล้อมแบบกระจาย
เครื่องที่ไคลเอนต์ที่สร้างโหนดนั้นประสบความสำเร็จจะกลายเป็นหลัก ในเวลาเดียวกันลูกค้ารายอื่นที่ไม่ประสบความสำเร็จในการสร้างโหนดจะลงทะเบียนผู้เฝ้าดูการเปลี่ยนแปลงโหนดเด็กบนโหนดเพื่อตรวจสอบว่าเครื่องต้นแบบปัจจุบันยังมีชีวิตอยู่หรือไม่ เมื่อพบว่าอาจารย์ปัจจุบันตายแล้วลูกค้ารายอื่นจะทำการเลือกตั้งอีกครั้ง
สิ่งนี้ช่วยให้การเลือกตั้งอาจารย์แบบไดนามิก
3.5 ล็อคแบบกระจาย
ล็อคแบบกระจายเป็นวิธีการควบคุมการเข้าถึงทรัพยากรที่ใช้ร่วมกันระหว่างระบบกระจาย
ล็อคแบบกระจายจะแบ่งออกเป็นล็อคพิเศษและล็อคที่ใช้ร่วมกัน
3.5.1 ล็อคพิเศษ
ล็อคพิเศษ (ล็อค X สำหรับระยะสั้น) หรือที่เรียกว่าล็อคเขียนหรือล็อคพิเศษ
หากธุรกรรม T1 เพิ่มล็อคแบบพิเศษให้กับวัตถุข้อมูล O1 จากนั้นในช่วงระยะเวลาการล็อคทั้งหมดธุรกรรม T1 เท่านั้นที่ได้รับอนุญาตให้อ่านและอัปเดต O1 และไม่มีธุรกรรมอื่น ๆ ที่สามารถดำเนินการใด ๆ ในวัตถุข้อมูลนี้ (วัตถุไม่สามารถล็อคได้) จนกว่า T1 จะปล่อยล็อคพิเศษ
จะเห็นได้ว่าแกนกลางของล็อคพิเศษคือวิธีการตรวจสอบให้แน่ใจว่ามีเพียงหนึ่งธุรกรรมเพียงหนึ่งรายการที่ได้รับล็อคและหลังจากการล็อคถูกปล่อยออกมาการทำธุรกรรมทั้งหมดที่รอการรับล็อคสามารถแจ้งเตือนได้
วิธีใช้ Zookeeper เพื่อให้ได้ล็อคพิเศษ?
กำหนดล็อค
Znode บน Zookeeper สามารถเป็นตัวแทนของการล็อค ตัวอย่างเช่นโหนด /exclusive_lock /ล็อคสามารถกำหนดเป็นล็อคได้
รับล็อค
ดังที่ได้กล่าวไว้ข้างต้นพิจารณา Znode บน Zookeeper เป็นล็อคและการได้รับล็อคทำได้โดยการสร้าง Znode ลูกค้าทั้งหมดไปที่ /exclusive_lock /ล็อคเพื่อสร้างโหนดเด็กชั่วคราว /exclusive_lock /ล็อคภายใต้ /exclusive_lock โหนด Zookeeper จะทำให้มั่นใจได้ว่าในหมู่ลูกค้าทั้งหมดสามารถสร้างลูกค้าได้อย่างประสบความสำเร็จและจากนั้นก็สามารถพิจารณาได้ว่าลูกค้าได้รับการล็อค ในเวลาเดียวกันลูกค้าทั้งหมดที่ไม่ได้รับการล็อคจำเป็นต้องลงทะเบียนผู้เฝ้าดูการเปลี่ยนแปลงโหนดเด็กบนโหนด /Exclusive_lock เพื่อฟังการเปลี่ยนแปลงโหนดล็อคแบบเรียลไทม์
ปล่อยล็อค
เนื่องจาก /exclusive_lock /ล็อคเป็นโหนดชั่วคราวจึงเป็นไปได้ที่จะปล่อยล็อคในทั้งสองกรณี
หากเครื่องไคลเอนต์ที่ได้รับการล็อคล้มเหลวหรือรีสตาร์ทในปัจจุบันโหนดชั่วคราวจะถูกลบและการล็อคจะถูกปล่อยออกมา
หลังจากดำเนินการตามตรรกะทางธุรกิจตามปกติลูกค้าจะลบโหนดชั่วคราวที่สร้างและปล่อยล็อค
ไม่ว่าจะลบโหนดล็อคไปภายใต้สถานการณ์ใดก็ตาม Zookeeper แจ้งลูกค้าทั้งหมดที่ลงทะเบียนโหนดเปลี่ยนผู้เฝ้าดูการฟังบนโหนด /exclusive_lock หลังจากได้รับการแจ้งเตือนลูกค้าเหล่านี้จะเริ่มต้นการเข้าซื้อกิจการล็อคแบบกระจายอีกครั้งนั่นคือการทำซ้ำ "การได้มาซึ่งล็อค"
3.5.2 ล็อคที่ใช้ร่วมกัน
ล็อคที่ใช้ร่วมกัน (ล็อค s เรียกว่าล็อค) หรือที่รู้จักกันในชื่อการอ่านล็อค หากธุรกรรม T1 เพิ่มล็อคที่ใช้ร่วมกันไปยังวัตถุข้อมูล O1 ดังนั้น T1 สามารถอ่าน O1 ได้เท่านั้นและธุรกรรมอื่น ๆ สามารถเพิ่มล็อคที่ใช้ร่วมกันไปยัง O1 ในเวลาเดียวกัน (ไม่ใช่ล็อคแบบพิเศษ) สามารถเพิ่ม O1 ลงในล็อคพิเศษเท่านั้นจนกว่าจะมีการเปิดตัวล็อคที่ใช้ร่วมกันทั้งหมดใน O1
สรุป: ธุรกรรมหลายรายการสามารถรับล็อคที่ใช้ร่วมกันสำหรับวัตถุในเวลาเดียวกัน (อ่านในเวลาเดียวกัน) หากมีการล็อคที่ใช้ร่วมกันคุณไม่สามารถเพิ่มล็อคพิเศษ (เนื่องจากล็อคพิเศษคือล็อคการเขียน)
4. การประยุกต์ใช้ Zookeeper ในระบบกระจายขนาดใหญ่
สถานการณ์แอปพลิเคชันทั่วไปของ Zookeeper ได้รับการแนะนำก่อนหน้านี้ ส่วนนี้จะแนะนำแอปพลิเคชันของ Zookeeper ในผลิตภัณฑ์ Big Data ทั่วไป Hadoop และ HBase เป็นตัวอย่างเพื่อช่วยให้ทุกคนเข้าใจสถานการณ์แอปพลิเคชันแบบกระจายของ Zookeeper
4.1 แอปพลิเคชันของ Zookeeper ใน Hadoop
ใน Hadoop, Zookeeper ส่วนใหญ่ใช้ในการใช้ HA (Hive Availability) รวมถึง Namanode ของ HDFS และ HA ของ ResourceManager ของเส้นด้าย ในเวลาเดียวกันในเส้นด้าย ZookeePR ยังใช้เพื่อจัดเก็บสถานะการทำงานของแอปพลิเคชัน
หลักการของการใช้ ZookeePR เพื่อใช้ HA นั้นเหมือนกันใน Namanode ของ HDFS และ ResourceManager ของเส้นด้ายดังนั้นส่วนนี้จึงแนะนำด้วยเส้นด้ายเป็นตัวอย่าง
zookeeper
ดังที่เห็นได้จากรูปด้านบนเส้นด้ายส่วนใหญ่ประกอบด้วยสี่ส่วน: ResourceManager (RM), NodeManager (NM), ApplicationMaster (AM) และคอนเทนเนอร์ แกนกลางที่สุดของพวกเขาคือ ResourceManager
ResourceManager รับผิดชอบการจัดการแบบครบวงจรและการจัดสรรทรัพยากรทั้งหมดในคลัสเตอร์ นอกจากนี้ยังได้รับข้อมูลการรายงานทรัพยากรจากแต่ละโหนด (NODEMANAGER) และจัดสรรข้อมูลนี้ให้กับแต่ละแอปพลิเคชัน (Application Manager) ตามนโยบายบางอย่าง มันเก็บรักษาข้อมูล ApplicationMaster ข้อมูล NodeManager และข้อมูลการใช้ทรัพยากรของแต่ละแอปพลิเคชัน
เพื่อที่จะใช้ HA ผู้จัดหาทรัพยากรหลายคนจะต้องอยู่ร่วมกัน (โดยปกติสอง) และมีเพียงหนึ่ง ResourceManager ที่อยู่ในสถานะที่ใช้งานอยู่ในขณะที่คนอื่น ๆ อยู่ในสถานะสแตนด์บาย เมื่อโหนดที่ใช้งานไม่สามารถทำงานได้อย่างถูกต้อง (เช่นการหยุดทำงานของเครื่องหรือรีสตาร์ท) สแตนด์บายจะแข่งขันเพื่อสร้างโหนดที่ใช้งานใหม่
4.2 สวิตช์หลักและสำรองข้อมูล
ลองมาดูกันว่าเส้นด้ายใช้การสลับมาสเตอร์มาสเตอร์ระหว่างผู้จัดหาทรัพยากรหลายคนอย่างไร
1. สร้างโหนดล็อค ใน Zookeeper จะมีโหนดล็อคล็อค-การเลือกตั้ง-ผู้นำด้วยเส้นด้าย /AppCluster-yarn เมื่อ ResourceManagers ทั้งหมดเริ่มต้นขึ้นพวกเขาจะแข่งขันเพื่อเขียนโหนดลูกล็อค:/เส้นด้าย-การเลือกตั้ง/AppCluster-yarn/ActiveBreadCrumb โหนดนี้เป็นโหนดชั่วคราว
ZOOKEEPR สามารถมั่นใจได้ว่ามีการสร้างทรัพยากรบุคคลเพียงหนึ่งเดียวเท่านั้นที่สามารถสร้างได้สำเร็จในที่สุด ResourceManager ที่สร้างขึ้นสำเร็จจะถูกเปลี่ยนเป็นสถานะที่ใช้งานอยู่ในขณะที่ผู้ที่ไม่ประสบความสำเร็จจะถูกเปลี่ยนเป็นสถานะสแตนด์บาย
zookeeper
คุณจะเห็นว่า ResourceManager2 ในคลัสเตอร์เปิดใช้งานในเวลานี้
ลงทะเบียนจอภาพผู้เฝ้าดู
ResourceManagers ทั้งหมดในรัฐสแตนด์บายจะลงทะเบียนผู้เฝ้าดูการเปลี่ยนแปลงโหนดไปยังโหนด/เส้นด้าย-Leader-Election/AppCluster-Yarn/ActiveBreadCrumb การใช้คุณสมบัติของโหนดชั่วคราวคุณสามารถสัมผัสได้อย่างรวดเร็วการทำงานของ ResourceManagers ในสถานะที่ใช้งานอยู่
สวิตช์หลักและสำรองข้อมูล
เมื่อ ResourceManager ที่ใช้งานอยู่จะได้รับข้อยกเว้นเช่นการหยุดทำงานหรือการรีสตาร์ทเซสชันไคลเอนต์ที่เชื่อมต่อกับ Zookeeper จะไม่ถูกต้องดังนั้นโหนด/Appluse-Leader-leader-leader-leader/AppCluster-Yarn/ActiveBreadCrumb จะถูกลบ ในเวลานี้ ResourceManagers อื่น ๆ ในสถานะสแตนด์บายจะได้รับการแจ้งเตือนเหตุการณ์ Watcher จากเซิร์ฟเวอร์ Zookeeper จากนั้นทำซ้ำขั้นตอนที่ 1
ข้างต้นเป็นกระบวนการของการใช้ Zookeeper เพื่อตระหนักถึงการสลับหลักและการสำรองข้อมูลของ ResourceManager ซึ่งตระหนักถึง HA ของ ResourceManager
หลักการดำเนินการของ Namenode HA ใน HDFS นั้นเหมือนกับหลักการดำเนินการของ ResourceManager HA ในเส้นด้าย โหนดล็อคของมันคือ/hadoop-ha/mycluster/activebreadcrumb
4.3 การจัดเก็บสถานะ ResourceManager
ใน ResourceManager Rmstatestore สามารถจัดเก็บข้อมูลสถานะภายในของ RM รวมถึงแอปพลิเคชันและข้อมูลความพยายามของพวกเขาโทเค็นการมอบหมายข้อมูลเวอร์ชัน ฯลฯ ควรสังเกตว่าข้อมูลสถานะส่วนใหญ่ใน Rmstatestore ไม่จำเป็นต้องมีการจัดเก็บข้อมูล ในรูปแบบการออกแบบการจัดเก็บข้อมูลมีการใช้งานสามอย่างที่เป็นไปได้ตามลำดับดังนี้
จากการใช้งานหน่วยความจำโดยทั่วไปจะใช้สำหรับการพัฒนาและการทดสอบประจำวัน
การใช้งานที่ใช้ระบบไฟล์เช่น HDFS
ขึ้นอยู่กับการใช้งาน Zookeeper
เนื่องจากจำนวนข้อมูลของข้อมูลสถานะเหล่านี้ไม่ใหญ่มาก Hadoop แนะนำอย่างเป็นทางการว่ามันตระหนักถึงการจัดเก็บข้อมูลของรัฐตามการดูแลของ Zoo ใน ZookeePR ข้อมูลสถานะของ ResourceManager จะถูกเก็บไว้ภายใต้โหนดรูทของ /rmstore
zookeeper
โหนด RMAppRoot เก็บข้อมูลที่เกี่ยวข้องกับแต่ละแอปพลิเคชันและ RMDTSECRETMANAGERROOT จัดเก็บข้อมูลที่เกี่ยวข้องกับความปลอดภัยและข้อมูลอื่น ๆ ResourceManager ของแต่ละรัฐที่ใช้งานจะอ่านข้อมูลสถานะเหล่านี้จาก Zookeeper ในระหว่างขั้นตอนการเริ่มต้นและยังคงดำเนินการตามข้อมูลสถานะเหล่านี้
4.4 สรุป:
แอปพลิเคชั่นหลักของ Zookeepr ใน Hadoop คือ:
Ha of Namenode ใน HDFS และ HA ของ ResourceManager ในเส้นด้าย
จัดเก็บข้อมูลสถานะ rmstatestore
5. แอปพลิเคชันของ Zookeeper ใน HBASE
HBASE ส่วนใหญ่ใช้ Zookeeper เพื่อตระหนักถึงการเลือกตั้ง HMASTER และการสลับการสลิปหลัก, การยอมรับความผิดพลาดของระบบ, การจัดการรูทเรียล, การจัดการสถานะภูมิภาคและการแจกจ่าย
การจัดการงาน Splitwal ฯลฯ
5.1 การเลือกตั้ง Hmaster และสวิตช์สำรองหลัก
หลักการของการเลือกตั้ง Hmaster และการสลับการสนับสนุนหลักนั้นเหมือนกับหลักการ HA ของ namenode ใน HDFs และ ResourceManager ในเส้นด้าย
5.2 การทนต่อข้อผิดพลาดของระบบ
เมื่อ HBASE เริ่มต้นขึ้นแต่ละภูมิภาคจะสร้างโหนดข้อมูลภายใต้โหนด/HBASE/RS ของ Zookeeper (ต่อไปนี้เราเรียกโหนดนี้ว่า "RS State Node") เช่น/HBASE/RS/[ชื่อโฮสต์] ในเวลาเดียวกัน Hmaster จะลงทะเบียนและฟังโหนดนี้ เมื่อ remionerver ล้มเหลว Zookeeper จะลบโหนดสถานะ RS ที่สอดคล้องกับเซิร์ฟเวอร์ภูมิภาคเพราะไม่สามารถยอมรับการเต้นของหัวใจในช่วงเวลาหนึ่ง (เช่นเซสชันไม่ถูกต้อง)
ในเวลาเดียวกัน HMASTER จะได้รับการแจ้งเตือน NODEDELETE จาก ZooKeeper ดังนั้นการตรวจจับโหนดจะถูกตัดการเชื่อมต่อและเริ่มงานที่ทนต่อความผิดพลาดได้ทันที
เหตุใด HBASE จึงไม่ให้ Hmaster รับผิดชอบการตรวจสอบภูมิภาคโดยตรง หาก HMASTER จัดการสถานะของภูมิภาคผ่านกลไกการเต้นของหัวใจโดยตรงเมื่อคลัสเตอร์มีขนาดใหญ่ขึ้นเรื่อย ๆ ภาระการจัดการของ HMASTER จะหนักขึ้นและอาจล้มเหลวดังนั้นข้อมูลจะต้องคงอยู่ ในกรณีนี้ Zookeeper กลายเป็นตัวเลือกที่เหมาะ
5.3 การจัดการรูทเรทเจียน
สำหรับกลุ่ม HBase ข้อมูลตำแหน่งของการจัดเก็บข้อมูลจะถูกบันทึกไว้ในภูมิภาคเมตาดาต้านั่นคือรูทรีเกียน ทุกครั้งที่ลูกค้าเริ่มคำขอใหม่และจำเป็นต้องทราบตำแหน่งของข้อมูลมันจะสืบค้นรูทรีเกียนและตำแหน่งของรูทรีเกียนจะถูกบันทึกไว้ใน Zookeeper (โดยค่าเริ่มต้นจะถูกบันทึกไว้ในโหนดของ Zookeeper /HBase /Meta-Region-Server)
เมื่อการเปลี่ยนแปลงของรูทเรทเจียนเช่นการเคลื่อนไหวด้วยตนเองของภูมิภาคการโหลดการปรับสมดุลใหม่หรือความล้มเหลวของเซิร์ฟเวอร์รูทรีเกียนมันสามารถรับรู้ถึงการเปลี่ยนแปลงนี้ผ่าน Zookeeper และใช้ชุดของมาตรการกู้คืนภัยพิบัติที่สอดคล้องกันเพื่อให้แน่ใจว่าไคลเอนต์สามารถรับข้อมูลรูตที่ถูกต้องได้เสมอ
5.4 การจัดการภูมิภาค
ภูมิภาคใน HBase มักจะเปลี่ยนไป เหตุผลของการเปลี่ยนแปลงเหล่านี้คือความล้มเหลวของระบบการปรับสมดุลการโหลดการปรับเปลี่ยนการกำหนดค่าการแยกภูมิภาคและการรวมกัน ฯลฯ เมื่อภูมิภาคเคลื่อนที่ผ่านกระบวนการของออฟไลน์และออนไลน์
ข้อมูลไม่สามารถเข้าถึงได้ในระหว่างออฟไลน์และการเปลี่ยนแปลงสถานะนี้ในภูมิภาคจะต้องทราบในระดับโลกมิฉะนั้นอาจมีข้อยกเว้นการทำธุรกรรม
สำหรับกลุ่ม HBase ขนาดใหญ่จำนวนภูมิภาคอาจสูงถึง 100,000 หรือมากกว่านั้น นอกจากนี้ยังเป็นทางเลือกที่ดีในการออกจากการจัดการสถานะภูมิภาคในระดับนี้ไปยัง Zookeeper
5.5 การจัดการงาน Splitwal แบบกระจาย
เมื่อเซิร์ฟเวอร์ภูมิภาคเซิร์ฟเวอร์วางสายเนื่องจากมีส่วนหนึ่งของข้อมูลที่เขียนใหม่ที่ไม่ได้รับการยืนยันใน HFILE เมื่ออพยพบริการภูมิภาคงานงานสำคัญคือการกู้คืนส่วนนี้ของข้อมูลที่ยังคงอยู่ในหน่วยความจำจาก WAL ขั้นตอนที่สำคัญที่สุดในส่วนนี้ของงานนี้คือ Splitwal นั่นคือ Hmaster จำเป็นต้องสำรวจ Wal ของเซิร์ฟเวอร์ภูมิภาคแบ่งเป็นชิ้นเล็ก ๆ และย้ายไปยังที่อยู่ใหม่และเล่นซ้ำบันทึก
เนื่องจากปริมาณการบันทึกของภูมิภาคเดียวมีขนาดค่อนข้างใหญ่ (อาจมีหลายพันภูมิภาคที่มีบันทึก GB) ผู้ใช้มักจะหวังว่าระบบจะสามารถทำงานการกู้คืนบันทึกให้เสร็จได้อย่างรวดเร็ว ดังนั้นวิธีแก้ปัญหาที่เป็นไปได้คือการจัดสรรงานนี้ที่จัดการกับ Wal ให้กับเซิร์ฟเวอร์หลายภูมิภาคสำหรับการประมวลผลร่วมซึ่งต้องใช้ส่วนประกอบถาวรเพื่อช่วย Hmaster ในการจัดสรรงานให้เสร็จสมบูรณ์
การปฏิบัติในปัจจุบันคือ Hmaster จะสร้างโหนด Splitwal บน Zookeeper (โดยค่าเริ่มต้นมันคือ /HBase /Splitwal Node) จัดเก็บข้อมูลเช่น "ซึ่งภูมิภาคใดที่จัดการกับภูมิภาค" บนโหนดในรายการและจากนั้นแต่ละเซิร์ฟเวอร์ Zookeeper มีบทบาทของการแจ้งเตือนซึ่งกันและกันและการคงอยู่ของข้อมูลในกลุ่มกระจายที่นี่
5.6 สรุป:
ข้างต้นเป็นสถานการณ์ทั่วไปบางอย่างใน HBASE ที่พึ่งพา Zookeeper เพื่อทำหน้าที่ประสานงานแบบกระจายให้เสร็จสมบูรณ์ แต่ในความเป็นจริง HBASE มีมากกว่าการพึ่งพา Zookeeper ตัวอย่างเช่น HMASTER ยังต้องพึ่งพา Zookeeper เพื่อให้การบันทึกสถานะการเปิดใช้งาน/ปิดการใช้งานของตารางและที่เก็บข้อมูลข้อมูลเมตาเกือบทั้งหมดใน HBASE ถูกวางไว้บน Zookeeper
เนื่องจากความสามารถในการประสานงานการกระจายที่ยอดเยี่ยมของ Zookeeper และกลไกการแจ้งเตือนที่ดี HBASE ได้เพิ่มสถานการณ์แอปพลิเคชัน Zookeeper มากขึ้นในวิวัฒนาการของแต่ละรุ่นและจากมุมมองแนวโน้มทั้งสองมีจุดตัดมากขึ้นเรื่อย ๆ การดำเนินการทั้งหมดของ Zookeeper ใน HBase นั้นถูกห่อหุ้มในแพ็คเกจ org.apache.hadoop.hbase.zookeeper นักเรียนที่สนใจสามารถศึกษาด้วยตนเอง
ด้านบนเป็นโมดูลสปริงบูตที่ตัวแก้ไขแนะนำให้คุณรู้จัก ฉันหวังว่ามันจะเป็นประโยชน์กับคุณ หากคุณมีคำถามใด ๆ โปรดฝากข้อความถึงฉันและบรรณาธิการจะตอบกลับคุณทันเวลา!