ฉันกำลังทำงานเกี่ยวกับการออกแบบแอปพลิเคชันที่ประกอบด้วยสามส่วน:
- เธรดเดียวที่เฝ้าดูเหตุการณ์บางอย่างที่เกิดขึ้น (การสร้างไฟล์คำขอภายนอก ฯลฯ )
- เธรดผู้ปฏิบัติงาน N ที่ตอบสนองต่อเหตุการณ์เหล่านี้โดยการประมวลผล (ผู้ปฏิบัติงานแต่ละกระบวนการและใช้เหตุการณ์เดียวและการประมวลผลอาจใช้เวลาแปรผัน)
- คอนโทรลเลอร์ที่จัดการเธรดเหล่านั้นและจัดการข้อผิดพลาด (การรีสตาร์ทเธรดการบันทึกผลลัพธ์)
แม้ว่านี่จะค่อนข้างพื้นฐานและไม่ยากที่จะนำมาใช้ แต่ฉันก็สงสัยว่ามันจะเป็นวิธีที่ "ถูกต้อง" (ในกรณีที่เป็นรูปธรรมนี้ใน Java แต่คำตอบที่เป็นนามธรรมก็สูงขึ้นเช่นกัน) กลยุทธ์ทั้งสองมาถึงใจ:
ผู้สังเกตการณ์ / สังเกตได้:ผู้สังเกตการณ์จะเฝ้าสังเกตด้ายดู ในกรณีที่มีเหตุการณ์เกิดขึ้นคอนโทรลเลอร์จะได้รับแจ้งและสามารถมอบหมายงานใหม่ให้กับเธรดอิสระจากกลุ่มเธรดแคชที่ใช้ซ้ำได้ (หรือรอและแคชงานในคิว FIFO หากเธรดทั้งหมดไม่ว่างในขณะนี้) เธรดผู้ปฏิบัติงานใช้ Callable และส่งคืนผลลัพธ์ที่สำเร็จพร้อมกับผลลัพธ์ (หรือค่าบูลีน) หรือส่งคืนพร้อมข้อผิดพลาดในกรณีนี้ผู้ควบคุมอาจตัดสินใจว่าจะทำอย่างไร (ขึ้นอยู่กับลักษณะของข้อผิดพลาดที่เกิดขึ้น)
ผู้ผลิต / ผู้บริโภค : เธรดการเฝ้าดูที่ใช้ร่วมกัน BlockingQueue กับตัวควบคุม (เหตุการณ์คิว) และตัวควบคุมที่ใช้ร่วมกันสองกับคนงานทั้งหมด (งานคิวและผลคิว) ในกรณีที่เกิดเหตุการณ์ด้ายเฝ้าดูทำให้วัตถุงานในคิวเหตุการณ์ คอนโทรลเลอร์ใช้งานใหม่จาก event-queue ตรวจสอบและวางไว้ใน task-queue ผู้ปฏิบัติงานแต่ละคนรองานใหม่และรับ / ใช้งานจากคิวงาน (มาก่อนได้รับก่อนจัดการโดยคิวเอง) วางผลลัพธ์หรือข้อผิดพลาดกลับเข้าไปในคิวผลลัพธ์ ในที่สุดตัวควบคุมสามารถดึงผลลัพธ์จากคิวผลลัพธ์และทำตามขั้นตอนในกรณีที่เกิดข้อผิดพลาด
ผลลัพธ์สุดท้ายของวิธีการทั้งสองมีความคล้ายคลึงกัน แต่แต่ละวิธีมีความแตกต่างกันเล็กน้อย:
ด้วย Observers การควบคุมเธรดโดยตรงและแต่ละงานมีสาเหตุมาจากผู้ทำงานใหม่ที่วางไข่โดยเฉพาะ ค่าโสหุ้ยสำหรับการสร้างเธรดอาจสูงขึ้น แต่ไม่มากต้องขอบคุณพูลเธรดที่แคช ในทางกลับกันรูปแบบของ Observer จะลดลงเป็น Observer เดียวแทนที่จะเป็นหลาย ๆ แบบซึ่งไม่ใช่สิ่งที่ถูกออกแบบมาอย่างแท้จริง
กลยุทธ์คิวดูเหมือนจะขยายได้ง่ายขึ้นตัวอย่างเช่นการเพิ่มผู้ผลิตหลายรายแทนที่จะเป็นผู้ผลิตที่ตรงไปตรงมาและไม่ต้องการการเปลี่ยนแปลงใด ๆ ข้อเสียคือเธรดทั้งหมดจะทำงานอย่างไม่มีกำหนดแม้ว่าจะไม่ได้ทำงานเลยก็ตามและการจัดการข้อผิดพลาด / ผลลัพธ์ไม่ได้ดูสวยงามเท่าโซลูชั่นแรก
อะไรคือแนวทางที่เหมาะสมที่สุดในสถานการณ์นี้และทำไม ฉันพบว่ามันยากที่จะหาคำตอบของคำถามนี้ทางออนไลน์เพราะตัวอย่างส่วนใหญ่จะจัดการกับกรณีที่ชัดเจนเช่นการปรับปรุงหลายหน้าต่างด้วยค่าใหม่ในกรณีผู้สังเกตการณ์หรือการประมวลผลกับผู้บริโภคและผู้ผลิตหลายราย ข้อมูลใด ๆ ที่ชื่นชมอย่างมาก