วิธีที่พบเป็นOzz กล่าวแล้วเป็นคิวข้อความ จากมุมมองของการออกแบบคิวข้อความคือคิว FIFOซึ่งเป็นประเภทข้อมูลพื้นฐาน:
สิ่งที่ทำให้คิวข้อความพิเศษคือในขณะที่แอปพลิเคชันของคุณรับผิดชอบในการเข้าคิวกระบวนการที่แตกต่างกันจะรับผิดชอบการยกเลิกคิว ในการจัดคิวศัพท์แอปพลิเคชันของคุณเป็นผู้ส่งข้อความและกระบวนการยกเลิกการจัดคิวเป็นผู้รับ ข้อได้เปรียบที่เห็นได้ชัดคือกระบวนการทั้งหมดเป็นแบบอะซิงโครนัสผู้รับจะทำงานโดยอิสระจากผู้ส่งตราบใดที่มีข้อความที่ต้องดำเนินการ ข้อเสียที่เห็นได้ชัดคือคุณต้องมีองค์ประกอบเพิ่มเติมผู้ส่งสำหรับการทำงานทั้งหมด
เนื่องจากสถาปัตยกรรมของคุณตอนนี้ต้องอาศัยสององค์ประกอบในการแลกเปลี่ยนข้อความคุณสามารถใช้การสื่อสารระหว่างกระบวนการแฟนซีคำสำหรับมัน
การแนะนำคิวมีผลต่อการออกแบบแอปพลิเคชันของคุณอย่างไร
การกระทำบางอย่างในแอปพลิเคชันของคุณสร้างอีเมล แนะนำคิวข้อความจะหมายความว่าการกระทำเหล่านั้นควรจะผลักข้อความไปยังคิวแทน (และไม่มีอะไรเพิ่มเติม) ข้อความเหล่านั้นควรมีจำนวนข้อมูลขั้นต่ำที่แน่นอนที่จำเป็นในการสร้างอีเมลเมื่อผู้รับของคุณได้รับการประมวลผล
รูปแบบและเนื้อหาของข้อความ
รูปแบบและเนื้อหาของข้อความนั้นขึ้นอยู่กับคุณ แต่คุณควรจำไว้ว่ายิ่งมีขนาดเล็ก คิวของคุณควรจะเขียนและดำเนินการให้เร็วที่สุดโดยการทิ้งข้อมูลจำนวนมากที่อาจทำให้เกิดปัญหาคอขวด
นอกจากนี้บริการจัดคิวตามคลาวด์หลายแห่งยังมีข้อ จำกัด เกี่ยวกับขนาดข้อความและอาจแบ่งข้อความที่ใหญ่กว่า คุณจะไม่สังเกตุเห็นข้อความแยกจะทำหน้าที่เป็นข้อความเดียวเมื่อคุณขอ แต่จะมีการคิดค่าบริการหลายข้อความ (โดยแน่นอนว่าคุณกำลังใช้บริการที่ต้องเสียค่าธรรมเนียม)
การออกแบบของผู้รับ
เนื่องจากเรากำลังพูดถึงเว็บแอปพลิเคชันวิธีการทั่วไปสำหรับผู้รับของคุณจะเป็นสคริปต์ cron อย่างง่าย มันจะทำงานทุก ๆxนาที (หรือวินาที) และมันจะ:
nจำนวนป๊อปอัพข้อความจากคิว- ประมวลผลข้อความ (เช่นส่งอีเมล)
โปรดสังเกตว่าฉันกำลังบอกว่าป๊อปแทนที่จะได้รับหรือดึงนั่นเป็นเพราะผู้รับของคุณไม่ได้แค่รับไอเท็มจากคิว แต่มันยังเคลียร์พวกมันด้วย (เช่นลบออกจากคิวหรือทำเครื่องหมายว่าถูกประมวลผลแล้ว) สิ่งที่จะเกิดขึ้นนั้นขึ้นอยู่กับการใช้คิวข้อความและความต้องการเฉพาะของแอปพลิเคชันของคุณ
แน่นอนสิ่งที่ฉันอธิบายคือการดำเนินการแบทช์เป็นวิธีที่ง่ายที่สุดในการประมวลผลคิว ขึ้นอยู่กับความต้องการของคุณคุณอาจต้องการประมวลผลข้อความในลักษณะที่ซับซ้อนมากขึ้น (ซึ่งอาจเรียกคิวที่ซับซ้อนมากขึ้น)
การจราจร
ผู้รับของคุณอาจพิจารณาปริมาณการใช้ข้อมูลและปรับจำนวนข้อความที่ประมวลผลตามปริมาณการใช้งานในเวลาที่เรียกใช้ วิธีการง่ายๆคือการคาดการณ์ชั่วโมงการจราจรสูงของคุณจากข้อมูลการจราจรในอดีตและสมมติว่าคุณใช้สคริปต์ cron ที่ทำงานทุกxนาทีคุณสามารถทำสิ่งนี้:
if(
now() > 2pm && now() < 7pm
) {
process(10);
} else {
process(100);
}
function process(count) {
for(i=0; i<=count; i++) {
message = dequeue();
mail(message)
}
}
วิธีการที่ไร้เดียงสาและสกปรกมาก แต่ใช้งานได้ หากไม่เป็นเช่นนั้นอีกวิธีหนึ่งก็คือการค้นหาปริมาณการใช้งานปัจจุบันของเซิร์ฟเวอร์ของคุณในการทำซ้ำแต่ละครั้งและปรับจำนวนรายการกระบวนการตาม โปรดอย่าปรับขนาดเล็กถ้าไม่จำเป็นอย่างยิ่งแม้ว่าคุณจะเสียเวลา
ที่เก็บข้อมูลคิว
หากแอปพลิเคชันของคุณใช้ฐานข้อมูลอยู่แล้วตารางเดียวในนั้นจะเป็นทางออกที่ง่ายที่สุด:
CREATE TABLE message_queue (
id int(11) NOT NULL AUTO_INCREMENT,
timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
processed enum('0','1') NOT NULL DEFAULT '0',
message varchar(255) NOT NULL,
PRIMARY KEY (id),
KEY timestamp (timestamp),
KEY processed (processed)
)
มันไม่ซับซ้อนกว่านั้นจริงๆ แน่นอนคุณสามารถทำให้มันซับซ้อนเท่าที่คุณต้องการตัวอย่างเช่นคุณสามารถเพิ่มเขตข้อมูลลำดับความสำคัญ (ซึ่งหมายความว่านี่ไม่ใช่คิว FIFO อีกต่อไป แต่ถ้าคุณต้องการจริงๆใครจะสนใจ?) คุณสามารถทำให้มันง่ายขึ้นโดยการข้ามเขตข้อมูลที่ดำเนินการแล้ว (แต่คุณต้องลบแถวหลังจากที่คุณประมวลผลแล้ว)
ตารางฐานข้อมูลจะเหมาะสำหรับข้อความ 2,000 ข้อความต่อวัน แต่มันอาจจะไม่ปรับขนาดสำหรับข้อความนับล้านต่อวัน มีหลายล้านปัจจัยที่ต้องพิจารณาทุกอย่างในโครงสร้างพื้นฐานของคุณมีบทบาทในการปรับขนาดโดยรวมของแอปพลิเคชันของคุณ
ไม่ว่าในกรณีใดสมมติว่าคุณระบุคิวฐานข้อมูลเป็นคอขวดแล้วขั้นตอนต่อไปคือการดูบริการบนคลาวด์ Amazon SQSเป็นบริการเดียวที่ฉันใช้และทำตามที่สัญญาไว้ ฉันแน่ใจว่ามีบริการที่คล้ายกันค่อนข้างน้อยที่นั่น
คิวที่ใช้หน่วยความจำเป็นสิ่งที่ต้องพิจารณาเช่นกันโดยเฉพาะสำหรับคิวที่มีอายุสั้น memcachedเป็นเลิศในการจัดเก็บคิวข้อความ
ไม่ว่าพื้นที่เก็บข้อมูลใดที่คุณตัดสินใจจะสร้างคิวของคุณก็ต้องฉลาดและเป็นนามธรรม ทั้งผู้ส่งและผู้รับของคุณไม่ควรเชื่อมโยงกับที่เก็บข้อมูลเฉพาะมิฉะนั้นการสลับไปยังที่เก็บข้อมูลอื่นในภายหลังจะเป็น PITA ที่สมบูรณ์
วิธีการในชีวิตจริง
ฉันสร้างคิวข้อความสำหรับอีเมลที่คล้ายกับสิ่งที่คุณทำ มันเป็นโครงการ PHP และฉันสร้างมันรอบ ๆZend Queueซึ่งเป็นส่วนประกอบของ Zend Framework ที่มีอะแดปเตอร์หลายตัวสำหรับการจัดเก็บที่แตกต่างกัน ห้องเก็บของของฉันอยู่ที่ไหน:
- PHP อาร์เรย์สำหรับการทดสอบหน่วย
- Amazon SQS เกี่ยวกับการผลิต
- MySQL บนสภาพแวดล้อม dev และการทดสอบ
ข้อความของฉันเรียบง่ายที่สุดเท่าที่จะเป็นไปได้แอปพลิเคชันของฉันสร้างอาร์เรย์ขนาดเล็กพร้อมข้อมูลที่จำเป็น ( [user_id, reason]) ที่เก็บข้อความเป็นรุ่นต่อเนื่องของอาเรย์นั้น (อย่างแรกคือรูปแบบการทำให้เป็นอนุกรมภายในของ PHP จากนั้น JSON ฉันจำไม่ได้ว่าทำไมฉันถึงเปลี่ยน) นี่reasonคือค่าคงที่และแน่นอนว่าฉันมีตารางขนาดใหญ่อยู่ที่ไหนสักแห่งที่แมปreasonไปยังคำอธิบายแบบเต็ม (ฉันจัดการเพื่อส่งอีเมลประมาณ 500 ถึงลูกค้าด้วยรหัสลับreasonแทนที่จะเป็นข้อความแบบเต็มครั้งเดียว)
อ่านเพิ่มเติม
มาตรฐาน:
เครื่องมือ
อ่านที่น่าสนใจ: