ใช้บริการ n-Producers / 1-Consumer แบบกระจายสำหรับระบบภารกิจที่สำคัญ
ฉันกำลังพยายามใช้ multi-Producer / 1-consumer เวอร์ชันแจกจ่ายสำหรับระบบภารกิจสำคัญ ฉันกำลังมองหาทางเลือกที่ดีสำหรับแนวทางปัจจุบันตาม RDBMS
ปัญหา
ระบบประกอบด้วยผู้ผลิตบริการ (50+) ซึ่งสร้างอินสแตนซ์หลายพันรายการต่อวินาทีอย่างต่อเนื่อง แต่ละอินสแตนซ์มีโครงสร้างที่กำหนดไว้อย่างดีประทับเวลา แต่ละอินสแตนซ์จะถูกจัดเก็บไว้ในคิวเดียวโดยผู้ผลิต
ในอีกด้านหนึ่งฉันมีผู้บริโภคที่ใช้อินสแตนซ์ในลักษณะ FIFO
ผู้ผลิตและผู้บริโภคทำงานบนเครื่องต่างๆที่เชื่อมต่อด้วยเครือข่ายส่วนตัว TCP / IP
เพื่อความสมบูรณ์มีข้อกำหนดที่แข็งแกร่งสองประการ
- ผู้บริโภคไม่สามารถใช้ทรัพยากรเดียวกันซ้ำสองครั้ง มันเป็นข้อผิดพลาด
- ทรัพยากรทุกอย่างจะต้องถูกบริโภคโดยผู้บริโภค หากพลาดทรัพยากรก็คือการสูญเสีย
นอกจากนี้โซลูชันต้องทำงานบนเซิร์ฟเวอร์ Linux และ Windows
แนวทางปัจจุบัน
ในเวอร์ชันปัจจุบันระบบจะใช้โซลูชันนี้โดยใช้ฐานข้อมูลเชิงสัมพันธ์เป็นบัสข้อมูล
มีเซิร์ฟเวอร์ฐานข้อมูลหนึ่งเครื่องที่รองรับผู้ผลิตและผู้บริโภคทั้งหมด ผู้ผลิตแทรกทรัพยากรลงในตารางที่กำหนดและผู้บริโภคใช้ทรัพยากรจากตารางนั้นตามที่แสดงในภาพด้านบน
เซิร์ฟเวอร์ฐานข้อมูล / โมเดลธุรกรรม JDBC อนุญาตให้ควบคุมการแทรก / การลบเพื่อหลีกเลี่ยงความเสียหายของคิว
แนวทางปัจจุบันนั้นใช้ได้ดี แต่:
- แนะนำค่าใช้จ่ายในการดูแลเซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์ทั้งหมดสำหรับงานที่ไม่จำเป็นต้องมีความสัมพันธ์ของข้อมูล
- เซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์ต้องสอดคล้องกับข้อกำหนดของภารกิจที่สำคัญซึ่งยากที่จะบรรลุในการตั้งค่าจริงบางอย่างเมื่อไม่ได้อุทิศอินสแตนซ์เซิร์ฟเวอร์ฐานข้อมูล
ทางเลือก
ที่นี่ฉันแสดงรายการทางเลือกอื่น ๆ สำหรับวิธีการบัสข้อมูลเซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์ในปัจจุบัน:
อุทิศเซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์น้ำหนักเบา
นี่เป็นวิธีที่ง่ายที่สุด: การใช้เซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์ที่มีน้ำหนักเบาโดยเฉพาะเช่น HSQLDB, Apache Derby หรือ H2
ข้อดี
พวกเขามีค่าใช้จ่ายในการดูแลรักษาน้อยกว่ามากหากเทียบกับ RDBMS เช่น MS SQL Server, Oracle DB Server หรือแม้แต่ MySQL นอกจากนี้จำเป็นต้องมีการเปลี่ยนแปลงโค้ดและการทดสอบน้อยลงเนื่องจากโดยพื้นฐานแล้วมันเป็นเอ็นจิ้น SQL เหมือนกับที่ใช้ในโซลูชันปัจจุบัน
จุดด้อย
เป็นเซิร์ฟเวอร์ฐานข้อมูลเชิงสัมพันธ์ดังนั้นจึงปรากฎว่ายังคงมีค่าใช้จ่ายบางระดับในการดำเนินงานที่ปราศจากความสัมพันธ์ อีกประเด็นหนึ่งคือประเด็นสำคัญ - ภารกิจ เราใช้ Derby DB เป็นการภายในเป็นเวลานานสำหรับการตรวจสอบระบบเรียลไทม์ทั้งในโหมดฝังตัวและโหมดเครือข่าย ใช้งานได้ดีไม่มีข้อผิดพลาดหรือข้อมูลเสียหาย อย่างไรก็ตามปริมาณธุรกรรม / วินาทีสำหรับการใช้งานใหม่นั้นสูงกว่า
เซิร์ฟเวอร์ Redis
เมื่อมองแวบแรก Redis ดูสมบูรณ์แบบสำหรับกรณีการใช้งานนี้ ในหน่วยความจำรวดเร็วไม่มีส่วนเกินสำหรับความสัมพันธ์ของข้อมูลตรงไปตรงมา ใช้กันอย่างแพร่หลายในฐานะฐานข้อมูลและรายงานว่าเชื่อถือได้ แต่ไม่ใช่สำหรับ Windows ตามที่กล่าวในเอกสารที่Redis บน Windows ไม่แนะนำ พอร์ต Microsoft Windows ไม่ได้รับการบำรุงรักษา , วันที่วางจำหน่ายล่าสุด 2016 เพื่อติด Redis ลักษณะระบบไม่ promissing
การดำเนินการแก้ปัญหาตั้งแต่เริ่มต้น
กล่าวได้ว่าเป็นปัญหาของผู้ผลิต - ผู้บริโภค การใช้บริการเครือข่ายโดยใช้ TCP หรือสิ่งที่หรูหรากว่าเช่น Camel และการใช้คิวพร้อมกันภายในบวกกับกลไกการคงอยู่ในท้องถิ่นบางตัวจะต้องเสียเวลาและมีค่าใช้จ่ายเพิ่มเติม
นี่คือทางเลือกอื่นที่เรากำลังพิจารณาอยู่ ขอขอบคุณหากมีใครสามารถให้ข้อมูลเชิงลึกหรือคำแนะนำได้
คำตอบ
ดูเหมือนว่าคุณกำลังมองหาคิวข้อความ มีการใช้งานคิวแบบกระจายที่คุณอาจสนใจเช่น ZeroMQ หรือ RabbitMQ ทั้งนี้ขึ้นอยู่กับกลุ่มเทคโนโลยีของคุณ
วิธีการบางอย่างเช่น ZeroMQ สามารถทำงานได้โดยไม่ต้องมีนายหน้าส่งข้อความซึ่งหมายความว่าผู้ผลิตและผู้บริโภคจะพูดคุยกันโดยตรงโดยไม่ต้องใช้บริการอื่นหรือฐานข้อมูลในการจัดคิว / นายหน้า การไม่มีนายหน้ามีข้อได้เปรียบในการจัดการการดำเนินงานที่ง่ายกว่าคิวข้อความที่เป็นนายหน้าและง่ายต่อการทำความเข้าใจและปรับขนาดและปรับแต่งได้ง่ายกว่า แต่ข้อเสียหลักคือการขาดบริการที่โบรกเกอร์มักจัดหาให้ดังนั้นหากผู้เข้าร่วมเป็น ออฟไลน์ข้อความอาจสูญหายได้ หากคุณต้องการให้ข้อความได้รับการประมวลผลอย่างน่าเชื่อถือคุณจะต้องออกแบบผู้ผลิตของคุณให้สามารถจัดการกับการลองส่งอีกครั้งหากผู้บริโภคไม่พร้อมใช้งานคุณจะต้องเพิ่มกลไกในการรับทราบการส่งมอบที่ประสบความสำเร็จและความต้องการของผู้บริโภค ได้รับการออกแบบให้มีความสำคัญ (สามารถตรวจจับข้อความที่ซ้ำกันและทิ้งได้) ข้อได้เปรียบหลักของการเป็นนายหน้าคือคุณมีอิสระที่จะปรับใช้พฤติกรรมนายหน้ามากหรือน้อยตามที่แอปพลิเคชันของคุณต้องการดังนั้นคุณจึงไม่ผูกติดกับพฤติกรรมนายหน้าเฉพาะ
คิวข้อความนายหน้าเช่น RabbitMQ ค่อนข้างง่ายกว่าในระหว่างการใช้งานเนื่องจากโบรกเกอร์เพิ่มชั้นความน่าเชื่อถือและความน่าเชื่อถือของการส่งข้อความให้กับโครงสร้างของระบบคิวแทนที่จะกำหนดให้ผู้ผลิตและผู้บริโภคนำไปใช้ แต่จะเพิ่มความซับซ้อนและค่าใช้จ่ายในการจัดการนายหน้า และโบรกเกอร์จะเพิ่มเวลาในการตอบสนองดังนั้นจึงอาจไม่เหมาะสำหรับสถานการณ์ที่มิลลิวินาทีมีความสำคัญหรือระดับความสามารถในการปรับขยายเป้าหมายของคุณสูงกว่าที่สามารถทำได้ในระบบนายหน้า
ยังคงมีค่าใช้จ่ายบางระดับในการดำเนินงานที่ปราศจากความสัมพันธ์
ฉันขอแนะนำให้คุณสร้างโปรไฟล์แอปพลิเคชันของคุณเพื่อดูว่าสิ่งนั้นสำคัญจริงหรือ มีโอกาสที่ฐานข้อมูล SQL ในกระบวนการไม่เพียงพอสำหรับแอปพลิเคชันที่ไม่ทำงานพร้อมกันเป็นไปได้มากว่าคุณกำลังใช้งานอย่างไม่มีประสิทธิภาพแทนที่จะเป็นเพราะปัญหาด้านประสิทธิภาพในการจัดการความสัมพันธ์เอง