การเรียนรู้ Solid Queue:โซลูชันงานเบื้องหลังที่ได้รับการพิสูจน์แล้วสำหรับ Ruby on Rails

บทความก่อนหน้าของเราในชุดนี้กำหนดว่า Solid Queue เป็นตัวเลือกที่ยอดเยี่ยมหากคุณต้องการระบบสำหรับการประมวลผลงานเบื้องหลัง มันลดการพึ่งพาภายนอกให้เหลือน้อยที่สุด — ไม่จำเป็นต้องใช้ Redis! — โดยการจัดเก็บงานทั้งหมดไว้ในฐานข้อมูลของคุณ แม้จะมีประสิทธิภาพที่น่าทึ่งก็ตาม

แต่ประสิทธิภาพไม่เพียงพอสำหรับระบบงานเบื้องหลังที่พร้อมสำหรับการผลิต นักพัฒนา Rails คาดหวังไว้มากมายตลอดหลายปีที่ผ่านมา เราไม่เพียงแค่ต้องการจัดคิวงานให้ทำงานในเบื้องหลังเท่านั้น เราต้องการจัดกำหนดการงาน รันงานตามกำหนดเวลาที่เกิดซ้ำ และเราอาจต้องการจำกัดจำนวนงานที่สามารถรันพร้อมกันได้ เราต้องการคุณสมบัติเพิ่มเติม!

น่าประหลาดใจที่ Solid Queue นำเสนอคุณสมบัติเหล่านั้นทั้งหมดทันที มาเจาะลึกลงไปใน Solid Queue และเรียนรู้ว่ามันเป็นไปได้อย่างไร!

การจัดตารางเวลางานด้วย Solid Queue สำหรับ Ruby on Rails

ก่อนอื่น ถึงเวลาสรุปสั้นๆ Solid Queue ใช้ฐานข้อมูลของคุณ — และเฉพาะฐานข้อมูลของคุณ — เพื่อจัดเก็บข้อมูลงาน ทุกอย่างที่ทำได้รับการสนับสนุนโดยตารางฐานข้อมูลหนึ่งหรืออีกตารางหนึ่ง การจัดกำหนดการงาน — นั่นคือการกำหนดงานให้ดำเนินการ ณ จุดใดจุดหนึ่งในอนาคต — ก็ไม่แตกต่างกัน งานที่กำหนดเวลาไว้จะถูกจัดเก็บไว้ใน 06 .

ตารางนี้แทบจะเหมือนกับ 14 ตาราง ข้อแตกต่างเพียงอย่างเดียวคือการเพิ่ม 25 ซึ่งบอกเราว่างานตามกำหนดการควรจะดำเนินการเมื่อใด มายืนยันกันโดยดูว่าจะเกิดอะไรขึ้นเมื่อเรากำหนดเวลางาน

ไม่มีความประหลาดใจที่นั่น Solid Queue เพิ่มแถวใหม่ให้กับ 30 ตารางซึ่งประกอบด้วยข้อมูลที่เราคาดหวัง แต่เราจะเปลี่ยนจากบันทึกที่มีอยู่ไปสู่การทำงานจริงในเวลาที่เหมาะสมได้อย่างไร

เราต้องการกระบวนการที่จะสำรวจ 47 อย่างต่อเนื่อง ตาราง กระบวนการดังกล่าวเรียกว่า Dispatcher และมีหน้าที่รับผิดชอบในการดำเนินงานตามกำหนดเวลาตามกำหนดเวลา เริ่มต้นเมื่อ Solid Queue เริ่มต้น — ไม่จำเป็นต้องกำหนดค่าเพิ่มเติม อย่างไรก็ตาม หากจำเป็น คุณสามารถเริ่มเฉพาะกระบวนการของผู้มอบหมายงานได้โดยการรัน Solid Queue ด้วยการกำหนดค่าเฉพาะ

ในกรณีที่คุณสงสัยว่ากระบวนการ Dispatcher ได้รับการดูแลอย่างไร นั่นเป็นความรับผิดชอบของ 57 ที่เหมาะเจาะ . ติดตามกระบวนการที่ทำงานอยู่ภายใน Solid Queue รวมถึงกระบวนการของผู้ปฏิบัติงานและผู้มอบหมายงาน

แล้ว Dispatcher ทำงานอย่างไรจริงๆ? มันกำหนด 66 วิธีการเรียกภายในลูปเพื่อตรวจสอบงานที่กำหนดเวลาไว้อย่างต่อเนื่อง รหัสการโพลกระจายไปในหลายคลาสและโมดูล แต่ในรูปแบบที่เรียบง่ายอย่างมาก ดูเหมือนว่า:

แบบสอบถามเพื่อดึงการดำเนินการตามกำหนดเวลา 'พร้อม' นั้นตรงไปตรงมา

ดังนั้น งานที่กำหนดเวลาไว้ด้วย 79 ที่ผ่านมามีพร้อมส่ง. ดังที่เราได้กล่าวถึงไปแล้วในส่วนหนึ่งของชุดนี้ เมื่อ Solid Queue จัดส่งงาน มันจะสร้าง 89 บันทึกและทำลาย 93 ที่เกี่ยวข้อง บันทึก 107 จากนั้นบันทึกจะถูกหยิบขึ้นมาโดยกระบวนการของผู้ปฏิบัติงานปกติ และงานที่เกี่ยวข้องจะรัน

 
 จนถึงตอนนี้ดีมาก งานตามกำหนดเวลาไม่ได้ซับซ้อนจริงๆ! มาดูสิ่งที่ซับซ้อนกว่านี้:งานที่เกิดซ้ำ
 งานที่เกิดซ้ำ
 
 งานที่เกิดซ้ำเป็นคุณลักษณะที่มีการร้องขอบ่อยครั้งสำหรับผู้ประมวลผลงานเบื้องหลัง พูดง่ายๆ ก็คืองานเหล่านี้เป็นงานเบื้องหลังที่ควรดำเนินการตามกำหนดเวลาที่เกิดซ้ำ งานเหล่านี้คล้ายกับงาน Cron ตรงที่คุณกำหนดตารางเวลา (เช่น ทุกห้านาที ทุกวันตอนเที่ยง เป็นต้น) ว่างานควรจะเกิดขึ้นเมื่อใด
 
 ใน Solid Queue คุณกำหนดค่างานที่เกิดซ้ำโดยใช้ 112 ไฟล์. ตัวอย่างเช่น หากเราต้องการเรียกใช้ 123 งานทุกวันตอนเที่ยงเราก็จะทำแบบนี้
 
 
 Solid Queue ใช้ Fugit เพื่อแยกวิเคราะห์นิพจน์กำหนดการ ซึ่งเป็นเหตุผลว่าทำไมจึงอนุญาตให้กำหนดเวลาที่มนุษย์สามารถอ่านได้ เช่น 'ทุกวันตอนเที่ยง' เมื่อใช้งานตามกำหนดเวลา คุณจะต้องกำหนดคลาสของงานที่จะรันและอาร์กิวเมนต์ของงานใดๆ งานที่เกิดซ้ำของ SolidQueue ที่ยอดเยี่ยม ReadMe ให้รายละเอียดเพิ่มเติม เรามาที่นี่เพื่อเรียนรู้วิธีการทำงาน ดังนั้นเรามาดูข้อมูลเบื้องต้นกันดีกว่า
 
 งานที่เกิดซ้ำจะแสดงด้วย 132 model ซึ่งได้รับการสนับสนุนโดย 144 ที่เกี่ยวข้อง ตาราง คอลัมน์ในนั้นสอดคล้องกับฟิลด์ที่มีอยู่ในไฟล์การกำหนดค่า
 
 
 เมื่อคุณเริ่ม SolidQueue บันทึกงานที่เกิดซ้ำจะถูกสร้างขึ้นตามไฟล์การกำหนดค่างานที่เกิดซ้ำของคุณ ในการสร้างงานในเวลาที่เหมาะสม เราจำเป็นต้องมีกระบวนการใหม่อีกครั้ง ซึ่งคราวนี้เรียกว่าเครื่องมือวางกำหนดการ Scheduler เป็นพี่น้องกับ Dispatcher ซึ่งเรารู้อยู่แล้ว มันทำงานในลักษณะเดียวกันเกือบทั้งหมด:กระบวนการใหม่จะถูกหมุนเมื่อ Solid Queue เริ่มทำงาน และกระบวนการนี้จะวนซ้ำไม่สิ้นสุด ความแตกต่างระหว่าง Scheduler และ Dispatcher คือสิ่งที่เกิดขึ้นภายในลูปนั้น โดยที่ Dispatcher สืบค้น 155 ตาราง ตัวกำหนดเวลาจะสอบถาม 168 — และจัดตารางเวลางานให้ตรงเวลา แล้วผู้วางกำหนดการรู้ได้อย่างไรว่าเวลาที่เหมาะสมคืออะไร และจะกำหนดเวลางานที่เหมาะสมเมื่อใด
 
 เพื่อตอบคำถามนี้ เราต้องตรวจสอบการดำเนินการอย่างใกล้ชิด คลาสตัวกำหนดเวลาสร้าง 172 ใหม่ วัตถุที่กำหนด 182 วิธีการ วิธีการนั้นจะถูกเรียกซ้ำๆ สำหรับแต่ละงานที่จัดกำหนดการไว้ นี่คือเวอร์ชันที่เรียบง่าย:
 
 
 มาแก้ให้หายยุ่งรหัสนี้ Solid Queue ใช้ 194 (จากไลบรารี concurrent-ruby) เพื่อสร้างเธรดใหม่ เธรดนั้นถูกกำหนดให้ทำงานตามเวลาที่ระบุโดยกำหนดการของงานที่เกิดซ้ำ เมื่อเธรดนั้นทำงาน เธรดนั้นจะสร้างเธรดอื่นแบบวนซ้ำก่อนเพื่อกำหนดเวลางานที่เกิดซ้ำครั้งถัดไป จากนั้นจะจัดคิวงานที่กำหนดเวลาไว้ 'ปัจจุบัน'
 
 มาดูตัวอย่างงานง่ายๆ ที่เกิดซ้ำเพื่อจัดการสิ่งต่างๆ กัน
 
 
 ถ้าเราเริ่ม Solid Queue เวลา 8:30 น. ตัวแปรภายในวิธีการกำหนดเวลาจะได้รับการกำหนดค่าต่อไปนี้ ไม่ใช่คำต่อคำ ใจคุณ เรากำลังทำให้ง่ายขึ้นมากที่นี่
 
 ดังนั้น เธรดพื้นหลังของเราถูกกำหนดให้ทำงานเป็นเวลาสามสิบนาทีนับจากนี้ ซึ่งก็คือ 9:00 น. เมื่อเวลาดังกล่าวหมุนไป เธรดพื้นหลังจะถูกดำเนินการ มันรัน 206 — เช่น 215 ถูกเข้าคิวเพื่อดำเนินการ นอกจากนี้ยังเรียกตัวเองซ้ำ ๆ ผ่านทาง 221 . เนื่องจากขณะนี้เป็นเวลา 9:00 น. ตัวแปรสำหรับการร้องขอนี้จึงมีการเปลี่ยนแปลง
 
 ดังนั้น เธรดพื้นหลังจึงถูกกำหนดให้ทำงานอีกครั้งในเวลา 10:00 น. และวงจรจะดำเนินต่อไป คุณอาจสงสัยว่าจะเกิดอะไรขึ้นหากเธรดการกำหนดเวลาถูกหยุดทำงาน เช่น ในระหว่างการปรับใช้ใหม่หรือระบบล่ม นั่นจะไม่ทำให้ตารางงานของคุณเสียใช่ไหม? โชคดีที่คำตอบคือไม่ กำหนดการของ Cron เป็นแบบคงที่ นิพจน์เช่น 'ทุกชั่วโมง' จะเปลี่ยนเป็น 10:00, 11:00, 12:00 น. เป็นต้นไปเสมอ โดยไม่คำนึงว่า Solid Queue จะเริ่มทำงานเมื่อใด การหยุดชะงักใดๆ ของเธรดการกำหนดเวลาจะไม่เปลี่ยนแปลงสิ่งนั้น
 
 ต่อไปนี้คือรายละเอียดการใช้งานอื่นๆ ที่ควรทราบ ประการแรก รูปแบบการจัดกำหนดการงานที่เกิดซ้ำครั้งถัดไปก่อนที่จะดำเนินการได้รับแรงบันดาลใจจาก GoodJob ประการที่สอง 234 ไม่สร้าง 247 ใหม่ และ 251 บันทึกอย่างที่คุณคาดหวัง แต่จะสร้างบันทึกอื่นขึ้นมาแทน นั่นคือ 265 .
 
 
 บันทึกนี้มีไว้เพื่อหลีกเลี่ยงการดำเนินงานที่เกิดซ้ำหลายครั้งเท่านั้น มีดัชนีอยู่ที่ 274 และ 282 โดยมีข้อจำกัดเฉพาะเพื่อให้บริการตามวัตถุประสงค์ดังกล่าว 298 อยู่ในคิวเฉพาะในกรณีที่ไม่มี 300 ก่อนหน้า ในเวลาเดียวกันและงานเดียวกัน
 
 
 ผู้อ่านที่สนใจจะสังเกตเห็นว่าข้อมูลโค้ดนี้ชี้ไปที่ข้อจำกัดใน Solid Queue นั่นคือ หากคุณไม่ได้ใช้ Solid Queue เป็นแบ็กเอนด์เพื่อรันงานสไตล์ cron ของคุณ ใช่ คุณสามารถทำได้ Solid Queue ไม่สามารถรับประกันได้ว่างานที่เกิดซ้ำจะถูกจัดคิวเพียงครั้งเดียว หากคุณพบว่าตัวเองตกอยู่ในสถานการณ์ดังกล่าว คุณควรตระหนักไว้
 
 คุณอาจสงสัยว่าจะเกิดอะไรขึ้นหากกระบวนการ Scheduler ตายหรือถูกหยุดทำงาน ตัวอย่างเช่น ระหว่างการใช้งาน เนื่องจากการเกิดขึ้นซ้ำได้รับการจัดการโดยเธรด จะไม่ฆ่ากำหนดเวลาการแบ่งเธรดใช่หรือไม่ โชคดีที่คำตอบคือไม่
 การควบคุมการทำงานพร้อมกัน
 
 มาดูคุณสมบัติสุดท้ายประการหนึ่งของ Solid Queue ซึ่งก็คือการควบคุมการทำงานพร้อมกัน บางครั้ง คุณต้องการจำกัดจำนวนงานบางประเภทที่สามารถทำงานได้พร้อมกัน คุณสามารถทำได้โดยใช้ Solid Queue ด้วย 310 .
 
 
 ที่นี่ เรากำลังบอกให้ SolidQueue รันอินสแตนซ์ 329 ได้สูงสุดหนึ่งอินสแตนซ์ สำหรับผู้ใช้แต่ละคน มาตรวจสอบการกำหนดค่าโดยละเอียดเพิ่มเติม
  330 :จำนวนงานสูงสุดที่คุณต้องการให้ทำงานพร้อมกัน

 347 :อาร์กิวเมนต์ที่จำเป็นเพื่อกำหนดว่างานใดควรถูกจำกัดไว้ด้วยกัน ในตัวอย่างของเรา งานที่มี User ID เดียวกันจะถูกจำกัดให้ดำเนินการพร้อมกันเพียงครั้งเดียว คุณสามารถใช้อาร์กิวเมนต์งานใดก็ได้เป็น 356 แต่อนุญาตให้ใช้ค่าคงที่ เช่น สตริงหรือสัญลักษณ์ได้

 367 :เวลาสูงสุดที่ Solid Queue สามารถรับประกันการทำงานพร้อมกันหลังจากงานเข้าคิวแล้ว หากงานของคุณดำเนินการนานกว่านั้น การควบคุมการทำงานพร้อมกันจะไม่มีผลและงานอาจทับซ้อนกัน เราจะเรียนรู้ว่าทำไมในภายหลัง!

 373 :คุณสามารถใช้ตัวเลือกนี้เพื่อจำกัดการทำงานพร้อมกันในประเภทงานที่แตกต่างกันได้

 

 
 หากคุณต้องการเรียนรู้เพิ่มเติม ฉันแนะนำให้คุณดูเอกสารการควบคุมการทำงานพร้อมกัน การควบคุมการทำงานพร้อมกันเป็นคุณสมบัติที่ซับซ้อนที่สุดของ Solid Queue ได้อย่างง่ายดาย หากงานที่กำหนดเวลาไว้ไม่ทำให้คุณปวดหัว การเรียนรู้ว่าฟีเจอร์นี้ทำงานอย่างไรจะช่วยได้อย่างแน่นอน
 
 เริ่มจากพื้นฐานกันก่อน เช่นเดียวกับคุณสมบัติ Solid Queue อื่นๆ การควบคุมการทำงานพร้อมกันได้รับการสนับสนุนโดยโมเดลต่างๆ และตารางฐานข้อมูลที่เกี่ยวข้อง สองสิ่งที่คุณต้องระวังเป็นพิเศษคือ 386 และ 396 .
 
 
 ลองดูที่ 409 ก่อน ตามชื่อที่แสดง นี่คือการนำรูปแบบสัญญาณการนับไปใช้ เมื่อใดก็ตามที่ Solid Queue เข้าคิวงานด้วย 419 ขั้นแรกจะพยายามรับการล็อกเซมาฟอร์ตามคีย์การทำงานพร้อมกัน คีย์การทำงานพร้อมกันนี้อิงตามอาร์กิวเมนต์ที่ส่งไปยัง 420 ได้แก่คลาสงาน คีย์ และชื่อกลุ่ม หากมีการระบุไว้ หากมีเซมาฟอร์ งานจะถูกจัดคิว หากไม่ใช่ ให้ระบุ 438 บันทึกถูกสร้างขึ้นแทน
 
 เซมาฟอร์มี 443 เพื่อรองรับงานหลายงานพร้อมกัน คุณสามารถคิดว่ามันเป็นความจุที่เหลืออยู่ของเซมาฟอร์ การได้รับเซมาฟอร์หมายถึงการลดค่านั้น และการปล่อยมันหมายถึงการเพิ่มค่านั้น เซมาฟอร์จะถือว่าไม่พร้อมใช้งานเมื่อค่าเป็นศูนย์ มาดูตัวอย่างการทำงานของกลไกการล็อคสำหรับงานง่ายๆ
 
 
 มาดูกันว่าจะเกิดอะไรขึ้นถ้าเราพยายามจัดคิวงานนี้หลายครั้งติดต่อกัน
  ตัวอย่างแรกของ 456 ถูกจัดอยู่ในคิว ยังไม่มีสัญญาณดังนั้นจึงมีการสร้างสัญญาณขึ้นมา ค่าเริ่มต้นคือ 465 . เนื่องจากขีดจำกัดของคุณคือสาม ค่าเริ่มต้นของเซมาฟอร์คือสอง
 ตัวอย่างที่สองของ 472 ถูกจัดอยู่ในคิว Solid Queue พยายามรับการล็อคสำหรับงานนั้น งานสามารถถูกจัดคิวได้เนื่องจากค่าเป็นสอง ซึ่งมากกว่าศูนย์ ค่าของเซมาฟอร์จะลดลงเหลือหนึ่ง
 ตัวอย่างที่สามของงานของเราอยู่ในคิวแล้ว เราทำซ้ำขั้นตอนเดิมเหมือนเมื่อก่อน ขณะนี้ค่าของเซมาฟอร์เป็นศูนย์
 อินสแตนซ์ที่สี่ของ 488 ถูกจัดอยู่ในคิว การรับเซมาฟอร์ล้มเหลวเนื่องจากค่าของมันคือศูนย์ 499 บันทึกถูกสร้างขึ้นสำหรับงาน

 ตัวอย่างแรกของงานของเราเสร็จสิ้น เมื่อเสร็จแล้ว จะปล่อยเซมาฟอร์ ดังนั้นค่าเซมาฟอร์จะเป็นหนึ่งอีกครั้ง
 เมื่อเสร็จสิ้น งานแรกจะเรียกใช้เมธอดเพื่อปล่อยงานที่ถูกบล็อก
 อินสแตนซ์ที่สี่ของ 503 ถูกปล่อยออกมาและพยายามที่จะรับล็อคอีกครั้ง ค่าเซมาฟอร์เป็นค่าเดียว ดังนั้นจึงสามารถรับการล็อคได้และงานที่ถูกบล็อกเข้าคิว ขณะนี้ค่าเซมาฟอร์เป็นศูนย์
 
 
 รหัสสำหรับปล่อยเซมาฟอร์เมื่องานเสร็จสิ้นนั้นตรงไปตรงมา
 
 
 มีรายละเอียดอีกอย่างหนึ่งที่เรายังไม่ได้สัมผัส เหตุใดเซมาฟอร์จึงมีวันหมดอายุ และเหตุใดเราจึงต้องกำหนดระยะเวลาเมื่อใช้ 518 ?
 
 ลองพิจารณาว่าจะเกิดอะไรขึ้นเมื่องานหยุดทำงานโดยไม่ปล่อยสัญญาณออกมา ตัวอย่างเช่น เมื่อผู้ปฏิบัติงานที่กำลังประมวลผลงานนั้นเสียชีวิต เว้นแต่ว่าเราเพิ่มกลไกบางอย่างเพื่อล้างเซมาฟอร์ การล็อคที่งานนั้นยึดไว้จะยังคงอยู่ตลอดไป ในกรณีที่เลวร้ายที่สุด การดำเนินการนี้จะบล็อกงานอื่นไม่ให้ประมวลผลตลอดไป
 
 เซมาฟอร์มีการหมดอายุที่สอดคล้องกับระยะเวลาที่กำหนดในคำจำกัดความของงานเพื่อหลีกเลี่ยงสถานการณ์ดังกล่าว หากสัญญาณหมดอายุ - ซึ่งจะเกิดขึ้นหากไม่มีงานเข้าคิว - สัญญาณจะถูกทำลาย เราทราบกระบวนการที่รับผิดชอบเรื่องนี้แล้ว — เพื่อนของเรา ผู้มอบหมายงาน . มันสร้างอินสแตนซ์ของ 529 คลาส ซึ่งทำสองสิ่ง:
  ขั้นแรก จะลบเซมาฟอร์ที่หมดอายุออก
 ประการที่สอง มันจะตรวจสอบว่ามีงานที่ถูกบล็อกหรือไม่และปล่อยงานเหล่านั้น
 
 
 งานจะถูกปล่อยออกมาทีละงาน ดังนั้นขีดจำกัดการทำงานพร้อมกันจะยังคงมีอยู่ อย่างไรก็ตาม ให้พิจารณาว่าจะเกิดอะไรขึ้นหากงานของคุณดำเนินไปนานกว่าระยะเวลาที่กำหนด ในกรณีนั้น เซมาฟอร์จะถูกล้างข้อมูล แม้ว่างานจะยังคงทำงานอยู่ก็ตาม หากมีงานอื่นเข้าคิว งานเหล่านั้นจะทับซ้อนกัน
 การตรวจสอบ Solid Queue สำหรับ Rails ด้วย AppSignal
 
 ตามที่เราได้กำหนดไว้ Solid Queue สามารถทำอะไรได้มากมาย อย่างไรก็ตาม ด้วยชิ้นส่วนที่เคลื่อนไหวเหล่านี้ การตรวจสอบจึงมีความสำคัญ โชคดีที่ AppSignal ให้การสนับสนุน Solid Queue ในตัว พร้อมด้วยแดชบอร์ดสำเร็จรูปสำหรับเวลาปฏิบัติงาน ปริมาณงาน และอัตราความล้มเหลว เพียงติดตั้ง AppSignal ในแอปพลิเคชัน Rails ของคุณ เพียงเท่านี้คุณก็พร้อมแล้ว
 
 AppSignal จะตรวจจับการใช้งาน Solid Queue ของคุณโดยอัตโนมัติ และสร้างแดชบอร์ดงานที่ใช้งานอยู่ซึ่งมีกราฟสำหรับตัวชี้วัดที่สำคัญ เช่น อัตราข้อผิดพลาดและปริมาณงาน
 
 
 
 หากคุณเคยเห็นงานที่ทำงานผิดปกติ — เนื่องจากงานทำงานช้าหรือมีข้อผิดพลาดมากเกินไป — มอบหมายสถานะให้พวกเขาและผู้ได้รับมอบหมายให้แก้ไขปัญหาอย่างมีประสิทธิภาพ
 
 
 
 แน่นอนว่าคุณไม่ควรต้องดูแดชบอร์ดทั้งวันเพื่อดูว่ามีปัญหาเกิดขึ้นหรือไม่ AppSignal Alerts ช่วยคุณได้ เพียงสร้างการแจ้งเตือนใหม่สำหรับตัวชี้วัดงาน เช่น อัตราความล้มเหลวและระยะเวลาของงาน เพียงเท่านี้คุณก็พร้อมแล้ว
 
 
 
 Solid Queue นั้นยอดเยี่ยมมากในการเพิ่มการประมวลผลงานอันทรงพลังให้กับแอปพลิเคชันของคุณโดยไม่ต้องยุ่งยาก AppSignal ทำเช่นเดียวกันเมื่อพูดถึงการตรวจสอบ!
 สรุป
 
 เราได้ครอบคลุมพื้นที่มากมายในการสำรวจคุณสมบัติขั้นสูงของ Solid Queue ตั้งแต่งานที่กำหนดเวลาไว้ไปจนถึงห่วงโซ่การพึ่งพาที่ซับซ้อน แต่ละฟีเจอร์สร้างขึ้นบนรากฐานที่มั่นคงที่เราได้พูดคุยไปแล้วในตอนที่หนึ่ง ดังที่เราได้เห็นแล้วว่าการสร้างแบ็กเอนด์การประมวลผลงานไม่ใช่เรื่องง่าย แต่ด้วยการเจาะลึกลงไปในซอร์สโค้ด Solid Queue และการทำงานของมัน เราได้รับความเข้าใจและซาบซึ้งสำหรับความท้าทายที่เกี่ยวข้อง
 
 ไม่ว่าในกรณีใด Solid Queue เป็นส่วนเสริมที่ยอดเยี่ยมของระบบนิเวศ Rails เนื่องจากการออกแบบฐานข้อมูลและการประสานงานกระบวนการที่ยอดเยี่ยม มีเครื่องมือที่คุณต้องการในขณะที่ยังคงรักษาคำมั่นสัญญาหลัก:ความเรียบง่ายและความน่าเชื่อถือ โดยไม่มีการพึ่งพาจากภายนอก
 
 ขอให้สนุกกับการเขียนโค้ด!