คุณมีปัญหาใหญ่ ฉันคิดว่าวิธีที่คุณคิดเกี่ยวกับปัญหาเป็นปัญหาที่ใหญ่กว่า มาดูพื้นฐานบางอย่างกันดีกว่า
การจัดกลุ่มใช้เพื่อแก้ปัญหาใหญ่ๆ เช่นเดียวกับปัญหา "กินช้าง" คุณสามารถแก้ปัญหานี้ได้ด้วยการออกแบบนักล่าที่ใหญ่กว่าและมีปากที่ใหญ่โต แต่ประวัติศาสตร์และบรรพชีวินวิทยาแสดงให้เราเห็นว่าสัตว์นักล่าขนาดใหญ่นั้นไม่สามารถดำรงอยู่ได้โดยง่าย (พวกมันมีราคาแพงต่อสิ่งแวดล้อม)
ดังนั้น เพื่อแก้ไขปัญหาของคุณ คุณสามารถใช้เซิร์ฟเวอร์ที่ใหญ่กว่าได้
หรือคุณสามารถใช้การจัดกลุ่ม
การจัดกลุ่มแก้ปัญหา "กินช้าง" ด้วยวิธีที่แตกต่างออกไปมาก แทนที่จะส่งนักล่าตัวใหญ่ที่มีปากใหญ่มากินช้าง มันจะใช้แนวคิดของการแปรรูปแบบกระจายและแบ่งปันเพื่อกินช้างทีละคำ เมื่อทำอย่างถูกต้อง มดก็สามารถกินช้างได้ หากมีเพียงพอและสถานการณ์ถูกต้อง
แต่สังเกตจากตัวอย่างของฉัน มดมีขนาดเล็กมาก... มดตัวเดียวจะอุ้มช้างทั้งตัวไม่ได้ คุณสามารถอุ้มช้างทั้งตัวได้ถ้ามดทุกตัวทำงานร่วมกัน แต่คุณประสบปัญหาพร้อมกันและล็อคกันไม่ได้ (คุณต้องประสานงานกับมด)
มดได้แสดงให้เราเห็นวิธีที่ดีกว่ามากในการจัดการกับเรื่องนี้ พวกเขาจะหยิบช้างชิ้นหนึ่งมาจัดการกับปัญหาเป็นชิ้นเล็กๆ
ในระบบของคุณ คุณถามว่าคุณสามารถซิงค์ข้อมูลข้ามโหนดได้อย่างไร... คำถามของฉันคือเพราะเหตุใด หากคุณกำลังซิงค์ข้อมูล แสดงว่าคุณกำลังมิเรอร์และปัญหาของคุณก็จะใหญ่ขึ้น (คุณกำลังโคลนช้าง แต่กินได้เฉพาะช้างดั้งเดิมเท่านั้น)
วิธีแก้ไขปัญหาของคุณคือการคิดวิธีแก้ปัญหาใหม่ และดูว่าคุณสามารถแบ่งปัญหาออกเป็นส่วนย่อยๆ ได้หรือไม่
ในรูปแบบอักกะและในรูปแบบนักแสดง วิธีที่ดีที่สุดในการจัดการกับปัญหาคือการใช้ "กระบวนการ" ที่เล็กกว่า (มดตัวเดียว) แม้ว่ากระบวนการโดยตัวมันเองแทบจะไม่มีประโยชน์ แต่เมื่อนำไปใช้ในวงกว้าง กระบวนการเหล่านั้นอาจทรงพลังมากได้ เมื่อสถาปัตยกรรมเสร็จสิ้นอย่างถูกต้อง คุณจะสังเกตเห็นว่าการนำเครื่องพ่นไฟไปที่มดจะไม่เอาชนะพวกมันได้... มดจะมามากขึ้น พวกมันก็จะจัดการกับปัญหาต่อไป
การคัดลอกและการซิงค์ข้อมูลไม่ใช่วิธีแก้ปัญหาของคุณ แต่เป็นการรวมกลุ่มเข้าด้วยกัน คุณต้องนำข้อมูลของคุณมาแยกย่อยจนถึงจุดที่คุณสามารถมอบให้มดตัวเดียวได้ ถ้าทำได้ก็ใช้อัคคาได้ หากวิธีนี้ดูน่าหัวเราะ แสดงว่า Akka ไม่เหมาะกับคุณ
แต่ลองพิจารณาสิ่งนี้... เห็นได้ชัดว่าคุณมีความกังวลเกี่ยวกับแบ็กเอนด์ฐานข้อมูลของคุณ - คุณไม่ต้องการเพิ่ม IO และทำให้เกิดความล้มเหลวเพียงจุดเดียว ฉันจะต้องเห็นด้วยกับคุณ แต่คุณต้องคิดใหม่ คุณสามารถทำการมิเรอร์ฐานข้อมูลเพื่อลบจุดความล้มเหลวเพียงจุดเดียว แต่คุณถูกต้องว่าสิ่งนี้จะไม่ลบปัญหาคอขวด สมมติว่ากระจกลบจุดเดียวของความล้มเหลว... ทีนี้มาโจมตีส่วนที่เป็นคอขวดกันดีกว่า
หากคุณสามารถแบ่งข้อมูลของคุณออกเป็นส่วนเล็กๆ พอที่มดจะจัดการได้ ฉันขอแนะนำให้คุณบอกมดของคุณให้รายงานไปยังฐานข้อมูลเมื่อข้อมูลมีการเปลี่ยนแปลงเท่านั้น... คุณสามารถอ่านได้ครั้งเดียวในการเริ่มต้น (คุณต้องมีแบ็กเอนด์ เก็บ อย่าหลอกตัวเอง ไฟฟ้าอาจหายไปอย่างรวดเร็ว... ต้องเก็บไว้ที่ไหนสักแห่ง) แต่ถ้าคุณบอกมดให้คงอยู่เฉพาะข้อมูลที่เปลี่ยนแปลง คุณจะลบคำถามทั้งหมดออกจากสมการซึ่งจะเปลี่ยนตำแหน่งโหลดอย่างมาก กำลังมาจาก เมื่อคุณมีเพียงการอัปเดต ส่วนแทรก และการลบที่ต้องจัดการ... ภูมิทัศน์ทั้งหมดก็จะง่ายขึ้นมาก
การจัดกลุ่มควรเป็นวิธีแก้ปัญหาสำหรับคุณ แต่เฉพาะในกรณีที่คุณสามารถดึงแนวคิดเรื่องกระจกออกไปจากใจได้
โหนดคลัสเตอร์สามารถและจะพังได้... แต่โหนดเหล่านั้นสามารถเกิดใหม่ไปยังโหนดอื่นได้ เพื่อให้คุณมีระบบที่รวดเร็วอยู่เสมอ เฉพาะเมื่อคุณจัดการกับข้อขัดข้องหรือการสูญเสียโหนด/กระบวนการของผู้ปฏิบัติงาน/มด คุณจะต้องโหลดข้อมูลซ้ำ...
โชคดี... คุณได้สรุปปัญหาที่น่าเกรงขามซึ่งฉันได้เห็นคนที่จบปริญญาวิศวกรรมซอฟต์แวร์ล้มเหลวในการแก้ไข
person
Karell Ste-Marie
schedule
17.11.2016
