เลือกโซลูชันคิวข้อความ
คิวที่เก็บข้อมูลและคิว Service Bus มีชุดคุณลักษณะที่แตกต่างกันเล็กน้อย คุณสามารถเลือกอย่างใดอย่างหนึ่งหรือทั้งสองอย่าง ขึ้นอยู่กับความต้องการของโซลูชันเฉพาะของคุณ
เมื่อพิจารณาว่าเทคโนโลยีการจัดคิวใดเหมาะกับวัตถุประสงค์ของโซลูชันที่กําหนด สถาปนิกโซลูชันและนักพัฒนาควรพิจารณาคําแนะนําเหล่านี้
พิจารณาใช้คิว Service Bus
ในฐานะสถาปนิก/นักพัฒนาโซลูชัน คุณควรพิจารณาใช้คิว Service Bus เมื่อ:
- โซลูชันของคุณต้องได้รับข้อความโดยไม่ต้องสํารวจคิว ด้วย Service Bus คุณสามารถดําเนินการได้โดยใช้การดําเนินการสํารวจแบบยาวโดยใช้โพรโทคอลที่ใช้ TCP ที่ Service Bus สนับสนุน
- โซลูชันของคุณจําเป็นต้องมีคิวเพื่อให้มีการจัดส่งที่สั่งซื้อก่อนเข้าก่อนออกก่อน (FIFO)
- โซลูชันของคุณต้องรองรับการตรวจหารายการซ้ําอัตโนมัติ
- คุณต้องการให้แอปพลิเคชันของคุณประมวลผลข้อความเป็นสตรีมที่ใช้เวลานาน (ข้อความเกี่ยวข้องกับสตรีมโดยใช้ ID เซสชัน คุณสมบัติบนข้อความ) ในแบบจําลองนี้ แต่ละโหนดในแอปพลิเคชันที่ใช้แข่งขันกับสตรีมซึ่งตรงกันข้ามกับข้อความ เมื่อมีการกําหนดสตรีมให้กับโหนดที่ใช้งาน โหนดสามารถตรวจสอบสถานะของสถานะสตรีมแอปพลิเคชันโดยใช้การทําธุรกรรม
- โซลูชันของคุณจําเป็นต้องใช้ลักษณะการทํางานของทรานแซคชันและปรมาณูเมื่อส่งหรือรับข้อความหลายข้อความจากคิว
- แอปพลิเคชันของคุณจัดการข้อความที่อาจเกิน 64 KB แต่ไม่น่าจะถึงขีดจํากัด 256 KB หรือ 1 MB ทั้งนี้ขึ้นอยู่กับระดับบริการที่เลือก (แม้ว่าคิว Service Bus จะสามารถจัดการข้อความได้สูงสุด 100 MB)
- คุณจัดการกับข้อกําหนดในการให้แบบจําลองการเข้าถึงตามบทบาทไปยังคิว และสิทธิ/สิทธิ์ที่แตกต่างกันสําหรับผู้ส่งและผู้รับ
พิจารณาใช้คิวที่เก็บข้อมูล
ในฐานะสถาปนิกโซลูชัน/นักพัฒนา คุณควรพิจารณาใช้คิวที่เก็บข้อมูล เมื่อ:
- แอปพลิเคชันของคุณต้องจัดเก็บข้อความในคิวมากกว่า 80 กิกะไบต์
- แอปพลิเคชันของคุณต้องการติดตามความคืบหน้าสําหรับการประมวลผลข้อความในคิว จะมีประโยชน์ถ้าคนงานประมวลผลข้อความขัดข้อง ผู้ปฏิบัติงานอื่นสามารถใช้ข้อมูลดังกล่าวเพื่อดําเนินการต่อจากตําแหน่งที่ผู้ปฏิบัติงานก่อนหน้าที่เหลืออยู่
- คุณจําเป็นต้องมีรายการบันทึกฝั่งเซิร์ฟเวอร์ของทรานส์ทั้งหมดที่ดําเนินการกับคิวของคุณ