การเขียนระบบการเข้าคิวขั้นพื้นฐานนั้นค่อนข้างง่าย แต่เมื่อคุณจดบันทึกข้างต้นกับความท้าทายทั้งหมดการทำในสิ่งที่ถูกต้องเป็นอีกเรื่องหนึ่ง ฉันใช้ระบบที่ปลูกในบ้านซึ่งฉันได้เขียนซอร์สโค้ดระบบบุคคลที่สามและผู้ให้บริการ JMS ต่างๆ JMS (Java Messaging Service) โดยไกลเป็นโซลูชั่นที่สมบูรณ์ที่สุดที่ฉันเคยพบมา สิ่งที่คุณถามส่วนใหญ่มีอยู่ใน JMS ผู้ให้บริการ JMS ที่ฉันชอบคือ ActiveMQ ฟรีนักแสดงติดตั้งง่ายและที่สำคัญคือง่ายต่อการฝังในแอพของฉันด้วย Spring ผู้ให้บริการ JMS ไม่ได้ให้ทุกสิ่งที่คุณต้องการ แต่พวกเขาก็มีชุดเครื่องมือที่จะจัดการกับสิ่งที่คุณถามเกี่ยวกับแอพพลิเคชั่นของคุณ ฉันไม่พบแอปพลิเคชั่นมากมายที่ต้องการทุกสิ่งที่คุณระบุไว้ การสั่งซื้ออาจไม่สำคัญ (เป็นการดีที่สุดหากไม่มี)
http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html
มันมีความแข็งแรงหรือสูญเสียการสั่งซื้อ? ใช่. มันมีทั้งขึ้นอยู่กับความต้องการของโปรแกรมของคุณ นี่คือรายละเอียด: http://activemq.apache.org/total-ordering.html
มันใส่ idempotent หรือไม่? ไม่ แต่นี่เป็นเรื่องเล็กน้อยที่จะนำไปใช้ในเลเยอร์แอปพลิเคชันของคุณหากคุณต้องการ
เราสามารถมีคิวมากกว่าสิ่งที่สามารถใส่ลงในเครื่องเดียวได้หรือไม่? ใช่. คุณสามารถมีเซิร์ฟเวอร์ที่ทำคลัสเตอร์และหากคุณต้องการตั้งค่าหลายเครื่องด้วยคิวที่แตกต่างกันคุณสามารถทำได้และดึงจากทั้งสองเครื่อง
เราสามารถมีข้อมูลเพิ่มเติมในคิวได้มากกว่าที่สามารถบรรจุลงในเครื่องเดียวได้หรือไม่? ใช่ผู้ให้บริการ JMS ส่วนใหญ่ต้องใช้การจัดเก็บฐานข้อมูล / ถาวรบางประเภทเพื่อให้แน่ใจว่าข้อความจะไม่หลุดหรือสูญหายหากผู้ให้บริการ JMS หยุดทำงาน
มีกี่เครื่องที่สามารถพังก่อนที่เราจะสูญเสียข้อมูลได้? นี่เป็นคำตอบที่ยากขึ้นเล็กน้อยเพราะมันเกี่ยวกับเวลา อย่างไรก็ตามคุณสามารถชนผู้ให้บริการ JMS และให้ดิสก์ไม่เสียหายมันจะกลับมาและเริ่มต้นที่จะได้รับการยอมรับครั้งล่าสุด ซึ่งหมายความว่าสามารถส่งข้อความได้สองครั้ง แต่หากคุณกำหนดรหัสแอปของคุณให้จัดการสิ่งนี้ก็ไม่เป็นปัญหา ตราบใดที่คุณมีอย่างน้อยหนึ่งประเภท (เซิร์ฟเวอร์ผู้ผลิตผู้บริโภคหรือเซิร์ฟเวอร์ JMS) จะเสร็จสมบูรณ์ นอกจากนี้คุณยังสามารถโหลด / สมดุล / ความล้มเหลวสำหรับความซ้ำซ้อนหากดิสก์ออกไปข้างนอกคุณ
สามารถแยกส่วนแบ่งสุทธิได้หรือไม่ ฉันคิดว่าฉันเข้าใจสิ่งที่คุณหมายถึงโดย "แยกสุทธิ" แต่ฉันไม่แน่ใจทั้งหมด ฉันเดาว่าคุณหมายถึงว่าเซิร์ฟเวอร์ JMS มีการทำคลัสเตอร์และเราหลวมการเชื่อมต่อกับเซิร์ฟเวอร์ตัวใดตัวหนึ่งมันจะข้ามไปยังเซิร์ฟเวอร์อื่นและไปรับที่ที่ค้างไว้ ใช่ แต่สถานการณ์ประเภทนี้อีกครั้งอาจนำไปสู่ข้อความที่ซ้ำกันโดยขึ้นอยู่กับจุดที่ลูกค้าขาดการเชื่อมต่อ
มันสามารถกระทบยอดข้อมูลโดยอัตโนมัติเมื่อมีการแก้ไขการแบ่งสุทธิหรือไม่? หากคุณใช้เซสชันที่ทำธุรกรรมมันจะส่งข้อความที่มีการส่งข้อความไปยังลูกค้าที่มีอยู่เดิมเท่านั้น
มันสามารถรับประกันการส่งมอบเมื่อลูกค้าสามารถผิดพลาด? ใช่นี่เป็นหนึ่งในเป้าหมายหลักของ JMS รับประกันการส่งมอบหมายความว่าหากข้อความถูกจัดคิวก็รับประกันว่าจะจัดการโดยลูกค้า
สามารถรับประกันได้หรือไม่ว่าข้อความเดียวกันไม่ได้ส่งมากกว่าหนึ่งครั้ง? ใช่ถ้ามีการใช้เซสชันธุรกรรม นั่นหมายความว่าลูกค้าได้ยอมรับข้อความและเรียกว่า commit / rollback เมื่อการกระทำที่เรียกว่ามันจะไม่ส่งข้อความ
โหนดเกิดความผิดพลาดได้ทุกจุดกลับมาและไม่ส่งขยะหรือไม่ ในกรณีที่คุณมีคิวคลัสเตอร์ที่ทนทาน ใช่มันจะไม่คาย "ขยะ" หากโหนดอื่นในคลัสเตอร์ส่งข้อความแล้ว มันยังสามารถส่งซ้ำสิ่งที่ไม่ได้รับการยอมรับ
คุณสามารถเพิ่มโหนดไปยังหรือลบโหนดออกจากคลัสเตอร์ที่รันอยู่โดยไม่ต้องหยุดทำงานได้หรือไม่? ใช่.
คุณสามารถอัพเกรดโหนดในคลัสเตอร์ที่รันอยู่โดยไม่ต้องหยุดทำงานได้หรือไม่? นี่เป็นเคล็ดลับเล็กน้อยสำหรับฉันที่จะตอบ แต่ฉันเชื่อว่าใช่คุณสามารถทำได้
มันสามารถทำงานได้โดยไม่มีปัญหากับเซิร์ฟเวอร์ต่างกันหรือไม่? สิ่งนี้หมายความว่าอะไรกันแน่? ฉันพบว่าผู้ให้บริการ JMS ส่วนใหญ่นั้นใช้งานง่ายในสภาพแวดล้อมที่ใช้ฮาร์ดแวร์ระบบปฏิบัติการ ฯลฯ แม้ว่าคุณจะหมายถึงประสิทธิภาพก็ตาม แต่นั่นก็เป็นอีกเรื่องหนึ่ง ระบบประมวลผลแบบกระจายใด ๆ อาจได้รับผลกระทบในทางลบโดยโหนดช้า ฉันมีเซิร์ฟเวอร์ Intel 8 2 คอร์ที่ใช้งานคิวและผู้บริโภค นั่นคือ 16 คอร์ด้วยกันและฉันได้ประสิทธิภาพที่ดีขึ้นจากการใช้เพียงสองกล่องเท่านั้นกว่าเมื่อฉันเพิ่มเครื่องแกนเดียวในฐานะผู้บริโภค เครื่องแกนเดี่ยวนั้นช้าลงมากมันทำให้ทั้งกริดช้าลงเป็นสองเท่า สิ่งนี้ไม่เกี่ยวข้องกับ JMS ต่อ se
คุณสามารถ“ แปะ” คิวกับกลุ่มของเซิร์ฟเวอร์ได้หรือไม่? คำตอบสั้น ๆ ใช่ ฉันคิดวิธีที่คุณสามารถเรียกใช้คลัสเตอร์ที่อยู่ในศูนย์ข้อมูลยุโรปเท่านั้นและกำหนดค่าคิวที่นั่น จากนั้นในการกำหนดค่าสปริงของคุณให้ผู้บริโภคใช้คิวนั้นรวมถึงคิวอื่น ๆ ในคลัสเตอร์อื่น ๆ คุณอาจต้องการศึกษาเอกสาร:
http://activemq.apache.org/clustering.html
มันสามารถตรวจสอบให้แน่ใจว่าได้วางแบบจำลองข้อมูลในศูนย์ข้อมูลอย่างน้อยสองแห่งหรือไม่ถ้ามี ฉันเชื่อเช่นนั้นอีกครั้ง แต่ควรปรึกษาเอกสารการจัดกลุ่ม
JMS มีตัวเลือกมากมายที่คุณสามารถปรับแต่งได้ตามที่คุณต้องการ การใช้เซสชันธุรกรรมและคิวที่คงทนนั้นมาพร้อมกับค่าใช้จ่ายด้านประสิทธิภาพ ฉันเคยเห็นการเปิดระฆังและนกหวีดส่งผลกระทบต่อประสิทธิภาพมากถึง 10 เท่า เมื่อฉันใช้ JBossMQ ถ้าเราปิดฟีเจอร์เหล่านี้เราสามารถรับข้อความได้ประมาณ 10,000 ข้อความ / s แต่การเปิดใช้มันทำให้เราได้รับข้อความถึง 1,000 ข้อความ หยดใหญ่