Background jobs — งานที่ผู้ใช้ไม่ควรรอ และทำไม "ทำพอดีครั้งเดียว" ไม่มีจริง

เปิดบล็อก E — งานเบื้องหลัง และประโยคข้อ ② ของวัน

บล็อก D (บท 136–141) ทำให้บทความมีเนื้อหาจริง · บล็อก E มีเป้าหมายเดียว: ตั้งเวลาเผยแพร่บทความ แล้วให้ระบบเผยแพร่เองพร้อมส่งอีเมลหาผู้ติดตาม · ก่อนจะทำแบบนั้นได้ ต้องรู้จัก "งานที่ทำทีหลัง โดยไม่มีใครยืนรอ" ก่อน — นั่นคือบทนี้

ประโยคข้อ ② ของวัน (สไลด์หน้า 32): "exactly-once ไม่มีอยู่จริง ออกแบบให้ทำซ้ำได้แทน" · ภาษาคน: ไม่มีระบบไหนรับประกันได้ว่างานจะถูกทำ พอดีหนึ่งครั้ง · ครึ่งหลังของบทนี้จะพิสูจน์ว่าทำไม

ลองทำให้หน้าค้างเอง — งาน 9 วินาทีใน request เดียว

สไลด์หน้า 16 ยกตัวอย่าง action create ที่บันทึกบทความแล้วทำต่ออีกสามอย่าง: ส่งอีเมลแจ้งผู้ติดตาม (3 วิ) · ส่งเข้าระบบค้นหา (2 วิ) · ย่อรูปปก (4 วิ) · แอปเรายังไม่มีทั้งสามอย่าง เลยจำลองด้วย sleep (สั่งให้โปรแกรมหยุดรอ N วินาที) — ความช้าเท่ากัน แค่ไม่ได้ทำงานจริง

ขั้น 1 · เปิด app/controllers/posts_controller.rb หา action create แล้วเติมสามบรรทัด sleep ใต้ if @post.save:

  def create
    @post = Post.new(post_params)

    respond_to do |format|
      if @post.save
        sleep 3 # จำลอง: ส่งอีเมลแจ้งผู้ติดตาม
        sleep 2 # จำลอง: ส่งเข้าระบบค้นหา
        sleep 4 # จำลอง: ย่อรูปปก
        format.html { redirect_to @post, notice: "สร้างบทความแล้ว" }
        # … บรรทัดที่เหลือเหมือนเดิม

• บรรทัด sleep 3 — หยุดรอ 3 วินาที แทน "ส่งอีเมล" · อีกสองบรรทัดเหมือนกัน รวม 9 วินาที
• ทั้งสามบรรทัดอยู่หลัง @post.save — บทความถูกบันทึกลงตู้เรียบร้อยก่อนจะเริ่มรอ
• และอยู่ก่อน redirect_to — ผู้ใช้จะยังไม่ได้หน้าถัดไปจนกว่าจะรอครบ

ขั้น 2 · บันทึกไฟล์ (bin/dev โหลดโค้ดใหม่ให้เอง) · เปิด localhost:3000/posts/new กรอกหัวข้อ ทดลองงานช้า พิมพ์เนื้อหาอะไรก็ได้ เลือกหมวด (ไม่ต้องใส่รูป) แล้วกด บันทึก

หน้าจอจะนิ่งไปนานจนน่าสงสัยว่าเว็บพัง · ในเครื่องที่ตรวจ Chrome ใช้เวลา 9,181 ms นับจากกดปุ่มถึงเห็นหน้าบทความ · log ในหน้าต่าง bin/dev (10:20:50 web.1 | หน้าบรรทัด = เวลา + มาจากตัวเว็บ):

10:20:50 web.1  | Started POST "/posts" for ::1 at 2026-11-10 10:20:50 +0700
10:20:50 web.1  | Processing by PostsController#create as TURBO_STREAM
10:20:50 web.1  |   Parameters: {"authenticity_token" => "[FILTERED]", "post" => {"title" => "ทดลองงานช้า", "body" => "<div>ทดลองงานหลังร้าน</div>", "category_id" => "1"}, "commit" => "บันทึก"}
10:20:50 web.1  |   TRANSACTION (1.7ms)  BEGIN
10:20:50 web.1  |   …
10:20:50 web.1  |   Post Create (1.6ms)  INSERT INTO "posts" ("title", "description", "category_id", "created_at", "updated_at", "plain_text") VALUES ('ทดลองงานช้า', …) RETURNING "id"
10:20:50 web.1  |   …
10:20:50 web.1  |   TRANSACTION (0.9ms)  COMMIT
10:20:59 web.1  | Redirected to http://localhost:3000/posts/31
10:20:59 web.1  | ↳ app/controllers/posts_controller.rb:35:in 'block (2 levels) in PostsController#create'
10:20:59 web.1  | Completed 302 Found in 9049ms (ActiveRecord: 9.4ms (5 queries, 0 cached) | GC: 0.0ms)

• for ::1 = ใบสั่งมาจากเครื่องตัวเอง (::1 คือ localhost) · Parameters = ของที่กรอกในฟอร์ม · ทั้งคู่เห็นมาตั้งแต่ Day 2–3
• COMMIT เกิดตอน 10:20:50 — ตู้ยืนยันแล้วว่าบทความเลข 31 อยู่ในตู้ งานของผู้ใช้เสร็จตั้งแต่วินาทีแรก
• Redirected เกิดตอน 10:20:59 — 9 วินาทีหลังจากนั้น ผู้ใช้เพิ่งได้หน้าถัดไป · บรรทัด ↳ …posts_controller.rb:35 ใต้มัน = คำสั่ง redirect มาจากบรรทัด 35 ของ controller
• Completed 302 Found in 9049ms คือเวลาที่ลูกค้ายืนรอทั้งหมด · ActiveRecord: 9.4ms คือเวลาที่ใช้กับตู้จริง ๆ — ไม่ถึง 0.2% ของเวลารอ

นี่คือประโยคใต้โค้ดของสไลด์หน้า 16: ผู้ใช้หน้าค้าง 9 วินาที ทั้งที่งานของเขาเสร็จไปตั้งแต่วินาทีแรก · และถ้าระบบอีเมลล่มตอนนั้น ผู้ใช้จะได้หน้า error ทั้งที่บทความบันทึกไปแล้ว — คิดว่าไม่สำเร็จ แล้วกดบันทึกซ้ำ ได้บทความสองชิ้น

เส้นแบ่ง — "ถ้างานนี้ยังไม่เสร็จ ผู้ใช้เห็นหน้าถัดไปได้ไหม"

สไลด์หน้า 16 ให้คำถามข้อเดียวไว้ตัดสินทุกงานที่อยู่ใน action:

• ได้ → ไม่ต้องให้ผู้ใช้รอ · ส่งไปทำเบื้องหลัง
• ไม่ได้ → ต้องทำให้เสร็จใน request (ในใบสั่งนี้) ก่อนตอบ

ทวนบท 112: ตอนเรียน callback เราได้กฎว่า "callback ควรดูแลแค่แฟ้มของตัวเอง" · และบอกว่าอีเมลแจ้งผู้ติดตาม "ฝากให้ job ส่งทีหลัง" แต่ยังไม่ได้เล่าว่า job คืออะไร (บท 112 เขียนว่า "เรื่องของ Day 3" — ของจริงมาถึงตอนนี้) · job คือปลายทางของคำว่า "ฝาก" นั่นเอง

สไลด์ให้เหตุผลข้อที่สองด้วย: งานที่อยู่ใน job พังแล้วลองใหม่ได้ · งานที่อยู่ใน request พังแล้วหายไปเลย · ประโยคนี้จริงเมื่อคิวเก็บงานไว้ถาวรและตั้งให้ลองใหม่ — สองอย่างที่บท 143–144 จะตั้ง · ในบทนี้คุณจะเห็นว่ายังไม่จริง

background job คืออะไร — ใบงานหลังร้าน

background job คือ "งานที่จดไว้ให้ทำทีหลัง" · controller ไม่ทำเอง แค่เขียนใบงานแขวนไว้ แล้วตอบผู้ใช้ทันที · จะมีโปรแกรมอีกตัวมาหยิบใบงานไปทำตอนว่าง โดยไม่มีผู้ใช้คนไหนยืนรอ

ที่แขวนใบงานเรียกว่า คิว (queue = แถวรอ ใครมาก่อนได้ทำก่อน) · โปรแกรมที่มาหยิบใบงานไปทำเรียกว่า worker (คนงาน)

เทียบกับ Go (บท 26 worker pool): channel jobs ที่กองงานไว้ = คิว · goroutine ที่วนรับงานจาก jobs = worker · ความต่างคือ worker pool ของ Go อยู่ในโปรแกรมเดียวกับคนส่งงาน · คิวของจริงที่ใช้ใน production (บท 143) อยู่นอกโปรแกรมเว็บ — ต่างกันตรงนี้แหละที่ทำให้งานไม่หาย

job ตัวแรก — ย้าย 9 วินาทีออกไปหลังร้าน

ขั้น 1 · สร้างไฟล์ job ด้วยตัวสร้างไฟล์ของ Rails (รันในโฟลเดอร์โปรเจกต์):

$ bin/rails generate job slow_work
      invoke  test_unit
      create    test/jobs/slow_work_job_test.rb
      create  app/jobs/slow_work_job.rb

ได้สองไฟล์ · ไฟล์ test ปล่อยไว้ก่อน (เรื่อง test อยู่ใน Part 2 ของสไลด์) · ชื่อ slow_work กลายเป็นคลาส SlowWorkJob (Rails เติมคำว่า Job ท้ายชื่อให้เอง)

ขั้น 2 · เขียนงาน — เปิด app/jobs/slow_work_job.rb แก้ทั้งไฟล์เป็น:

class SlowWorkJob < ApplicationJob
  queue_as :default

  def perform(post_id)
    post = Post.find(post_id)
    sleep 3 # จำลอง: ส่งอีเมลแจ้งผู้ติดตาม
    sleep 2 # จำลอง: ส่งเข้าระบบค้นหา
    sleep 4 # จำลอง: ย่อรูปปก
    Rails.logger.info "งานหลังร้านของบทความ #{post.id} เสร็จแล้ว"
  end
end

• < ApplicationJob — สืบทอดจากแม่แบบของ job ทุกตัวในแอป (เหมือน model สืบจาก ApplicationRecord) · แม่แบบนี้มาจาก Active Job = ชุดเครื่องมือทำ job ที่มากับ Rails (บท 143 เล่าต่อ)
• queue_as :default — แขวนใบงานไว้บนกระดานชื่อ default · แอปเล็ก ๆ ใช้กระดานเดียวพอ
• def perform(post_id) — สิ่งที่ worker ทำเมื่อหยิบใบงานนี้ไป · ชื่อ perform บังคับ
• Post.find(post_id) — ใบงานจดแค่เลข id ของบทความ worker ต้องไปหยิบแฟ้มจากตู้เอง (ทำไมจดแค่เลข — บท 143)
• sleep สามบรรทัด — ย้ายมาจาก controller ตรง ๆ
• Rails.logger.info "…" — เขียนหนึ่งบรรทัดลง log ตอนทำครบ · เราจะใช้บรรทัดนี้เป็นหลักฐานว่างานเสร็จจริง

ขั้น 3 · ให้ controller แขวนใบงานแทนทำเอง — กลับไปที่ create ลบ sleep สามบรรทัด ใส่บรรทัดเดียวแทน:

      if @post.save
        sleep 3 # จำลอง: ส่งอีเมล…
        sleep 2 # จำลอง: ส่งเข้า…
        sleep 4 # จำลอง: ย่อรูปปก
        format.html { … }

      if @post.save
        SlowWorkJob.perform_later(@post.id)
        format.html { … }

• perform_later — "ทำทีหลัง" · เขียนใบงาน (ชื่อ job + เลข id) แขวนเข้าคิว แล้วกลับมาทันที ไม่รอให้ perform ทำ
• (@post.id) — ของที่ส่งไปจะกลายเป็น post_id ใน perform
• บรรทัดนี้อยู่หลัง save สำเร็จเท่านั้น — บันทึกไม่ผ่านก็ไม่มีใบงาน (ไม่มีอีเมลเรื่องบทความที่ไม่มีอยู่จริง)

10:21:06 web.1  | Started POST "/posts" for ::1 at 2026-11-10 10:21:06 +0700
10:21:06 web.1  | Processing by PostsController#create as TURBO_STREAM
10:21:06 web.1  |   …
10:21:06 web.1  |   TRANSACTION (1.2ms)  COMMIT
10:21:06 web.1  | [ActiveJob] Enqueued SlowWorkJob (Job ID: 16307e4e-…) to Async(default) with arguments: 32
10:21:06 web.1  | [ActiveJob] ↳ app/controllers/posts_controller.rb:32:in 'block in PostsController#create'
10:21:06 web.1  | Redirected to http://localhost:3000/posts/32
10:21:06 web.1  | Completed 302 Found in 28ms (ActiveRecord: 6.3ms (5 queries, 0 cached) | GC: 0.6ms)
10:21:06 web.1  | [ActiveJob] [SlowWorkJob] [16307e4e-…] Performing SlowWorkJob (Job ID: 16307e4e-…) from Async(default) enqueued at 2026-11-10T03:21:06.636126000Z with arguments: 32
10:21:06 web.1  | Started GET "/posts/32" for ::1 at 2026-11-10 10:21:06 +0700
10:21:06 web.1  |   …   (หน้าบทความ 32 วาดเสร็จ)
10:21:06 web.1  | Completed 200 OK in 28ms (Views: 15.2ms | ActiveRecord: 4.5ms (6 queries, 0 cached) | GC: 11.9ms)
10:21:06 web.1  |   …
10:21:15 web.1  | [ActiveJob] [SlowWorkJob] [16307e4e-…] งานหลังร้านของบทความ 32 เสร็จแล้ว
10:21:15 web.1  | [ActiveJob] [SlowWorkJob] [16307e4e-…] Performed SlowWorkJob (Job ID: 16307e4e-…) from Async(default) in 9031.67ms

ตอนนี้ใบงานแขวนอยู่ที่ไหน — Async คือคิวในหน่วยความจำ

เราไม่ได้ตั้งค่าคิวเลย แต่ job ก็ทำงาน · ถามแอปได้ว่าตอนนี้ใช้คิวแบบไหน (หน้าต่างที่สอง):

$ bin/rails runner 'p ActiveJob::Base.queue_adapter_name'
"async"

bin/rails runner '…' = รันโค้ด Ruby หนึ่งบรรทัดในแอปแล้วจบ (ไม่ต้องเปิด console) · p = พิมพ์ค่าออกมา · ActiveJob::Base = แม่แบบตัวบนสุดของ job ทุกตัว (:: อ่านว่า "ที่อยู่ใน") · ได้ "async" · adapter คือ "ตัวเสียบ" ที่บอกว่าใบงานไปเก็บที่ไหน · development ถ้าไม่ตั้งอะไร ได้ async · ส่วน config/environments/production.rb (ค่าตั้งของ production = เครื่องจริงที่ผู้ใช้ใช้) ของเรามีบรรทัดนี้อยู่แล้ว:

  # Replace the default in-process and non-durable queuing backend for Active Job.
  config.active_job.queue_adapter = :solid_queue

คอมเมนต์บรรทัดบนบอกนิสัยของ async ไว้สองคำ: in-process (อยู่ใน process เดียวกับเว็บ — ตัวโปรแกรมที่กำลังรันอยู่ตัวเดียวกัน) และ non-durable (ไม่ทนทาน — ไม่ได้เขียนเก็บลงที่ไหน) · เอกสาร Rails เขียนตรง ๆ ว่า ถ้า process ดับหรือเครื่องรีเซ็ต งานที่ค้างอยู่หายหมด (ดูลิงก์ท้ายบท)

เทียบกับ Go (บท 21): async ก็คือ go f() ดี ๆ นี่เอง · ถ้าใน handler ของ Gin เราเขียน (ตัดมาสองบรรทัด ไม่ใช่ไฟล์เต็ม):

go sendEmail(post.ID) // แยกไปส่งอีเมล ไม่รอ
c.JSON(201, post)     // ตอบผู้ใช้ทันที

ผู้ใช้ได้คำตอบเร็วเหมือนกัน · แต่กฎของบท 21 ยังอยู่: โปรแกรมจบ = goroutine ที่ค้างตายเงียบ ๆ · และถ้า sendEmail พัง ไม่มีใครลองใหม่ให้ · go f() แก้ปัญหา "ผู้ใช้ต้องรอ" ได้ แต่ไม่ได้แก้ "งานหาย" — สิ่งที่คิวจริงต้องมีคือที่เก็บใบงานที่อยู่นอกโปรแกรม

ถึงตรงนี้คิดว่าแก้ได้แล้ว: แค่เปลี่ยนไปใช้คิวที่ durable งานก็ไม่หาย · ไม่หาย — แต่ได้ปัญหาใหม่มาแทน · ครึ่งหลังของบทว่าด้วยเรื่องนี้

exactly-once ไม่มีจริง — เลือกได้แค่ "อาจหาย" หรือ "อาจซ้ำ"

ใบงานหนึ่งใบต้องผ่านสองฝั่ง: คิว (ที่แขวนใบงาน) กับ worker (คนทำ) · สองฝั่งนี้คุยกันผ่านเครือข่ายหรือฐานข้อมูล ซึ่งขาดได้ และ worker ตายได้ทุกเมื่อ · คำถามคือ: คิวจะขีดฆ่าใบงาน (ถือว่าจบ) ตอนไหน — ก่อน worker ทำ หรือหลัง worker ทำ · มีแค่สองทาง (สไลด์หน้า 17):

แล้วที่คนชอบพูดว่า "ระบบเรา exactly-once" คืออะไร · สไลด์ตอบว่า at-least-once + งานที่ทำซ้ำแล้วผลเหมือนเดิม — คิวส่งซ้ำได้ แต่ทำซ้ำแล้วไม่มีอะไรเสีย ผลรวมเลยดูเหมือนทำครั้งเดียว

worker ตายตอนไหน งานถึงซ้ำ — ช่องว่างที่ปิดไม่ได้

ไล่ตามเวลาแบบสไลด์หน้า 18 · คิวแบบ at-least-once (ทำก่อน แล้วค่อยบอกคิว) · ใบงานคือ "ส่งอีเมลแจ้งผู้ติดตาม":

• ช่องว่างระหว่าง t2 กับ t3 ปิดไม่ได้ — "ส่งอีเมล" กับ "บอกคิว" เป็นสองการกระทำ ต่อให้เขียนโค้ดเร็วแค่ไหน ระหว่างกลางก็กว้างกว่าศูนย์เสมอ · worker ตายพอดีตรงนั้น = ซ้ำ
• t4 ไม่ใช่เรื่องไกลตัว — deploy ทุกครั้งคือการปิด worker เก่าแล้วเปิดตัวใหม่ · ระบบที่ deploy วันละหลายรอบเจอจังหวะนี้แน่นอนสักวัน

สลับลำดับก็ไม่ช่วย: ถ้าบอกคิวว่าเสร็จก่อน (t3 ขึ้นมาก่อน t2) แล้ว worker ตายตรงกลาง — คิวคิดว่าเสร็จ แต่อีเมลไม่เคยออก · เราแค่ย้ายจากปัญหา "ซ้ำ" ไปเป็นปัญหา "หาย" · เลือกได้แค่ว่าจะเจ็บทางไหน

คำถามที่ถูก — "ถ้าซ้ำแล้ว จะไม่เป็นไรได้ยังไง"

งานส่วนใหญ่หายไม่ได้ (อีเมลยืนยัน · เผยแพร่บทความตามเวลา) → เลือก at-least-once ซึ่งแปลว่าต้องยอมรับว่างานจะถูกทำซ้ำ · คำถามจึงเปลี่ยนจาก "จะกันไม่ให้ซ้ำยังไง" (ทำไม่ได้) เป็น "ถ้าซ้ำแล้วจะไม่เป็นไรได้ยังไง"

ฝั่งขวาคือ idempotent — คำเดียวกับที่เจอใน Go บท 36 (PUT ยิงซ้ำได้ POST ยิงซ้ำแล้วได้ของเบิ้ล) และ find_or_create_by! ใน seeds · แต่ "ส่งอีเมล" ไม่มีทางทำให้เป็นแบบฝั่งขวาโดยธรรมชาติ — ส่งสองครั้งก็สองฉบับ · 3 ท่าที่ใช้จริงในการทำให้ job แบบนี้ซ้ำได้ คือเรื่องของบท 143

10:22:41 web.1  | [ActiveJob] Enqueued SlowWorkJob (Job ID: 7ffe7c1f-…) to Async(default) with arguments: 34
10:22:41 web.1  |   …
10:22:41 web.1  | Completed 302 Found in 34ms (ActiveRecord: 7.4ms (5 queries, 0 cached) | GC: 0.0ms)
10:22:41 web.1  | [ActiveJob] [SlowWorkJob] [7ffe7c1f-…] Performing SlowWorkJob (Job ID: 7ffe7c1f-…) from Async(default) enqueued at 2026-11-10T03:22:41.978400000Z with arguments: 34
10:22:41 web.1  |   …   (หน้าบทความ 34 วาดเสร็จ)
10:22:44 system | SIGINT received, starting shutdown
10:22:44 web.1  | - Gracefully stopping, waiting for requests to finish
10:22:44 web.1  | === puma shutdown: 2026-11-10 10:22:44 +0700 ===
10:22:44 web.1  | - Goodbye!
10:22:44 web.1  | Exiting
10:22:44 web.1  | [ActiveJob] [SlowWorkJob] [7ffe7c1f-…] Performed SlowWorkJob (Job ID: 7ffe7c1f-…) from Async(default) in 2158.22ms
10:22:44 system | sending SIGTERM to all processes
10:22:44 css.1  | exited with code 0
10:22:44 web.1  | exited with code 0

ทดสอบความเข้าใจ

ถามกลับได้เลย

ติดตรงไหนถามได้ทุกเรื่อง เช่น "ถ้า job ไปแก้บทความที่ผู้ใช้เพิ่งลบไปแล้วจะเกิดอะไร" · "แล้ว job ที่พังกลางทางไปไหน" (บท 144 ตอบเต็ม ๆ) · หรือวาง log ของคุณมาให้ดูด้วยกัน

ถ้าเปิดสไลด์ดูประกอบ

อ้างอิง

• Rails Guides — Active Job Basics § What is Active Job? — อ่านสองย่อหน้าแรก: เป้าหมายของ background job คือย้ายงานยาว ๆ ออกจากวงจร request–response ให้หน้าเว็บตอบไว · แล้วอ่านหัวข้อ "Creating Jobs" ต่อ (ตรงกับขั้น generate ของบทนี้)
• Rails Guides — Active Job Basics § Development Environment — ย่อหน้าเดียว: adapter ของ development เก็บงานในหน่วยความจำ · process ดับหรือเครื่องรีเซ็ต งานที่ค้างหายหมด — สิ่งที่ภารกิจพิสูจน์
• Rails API — ActiveJob::QueueAdapters::AsyncAdapter — อ่านแค่ย่อหน้าแรก: ทำ job ด้วยกลุ่มคนงานในโปรแกรมเดียวกัน · เหมาะกับ dev/test · ไม่เหมาะกับ production เพราะทิ้งงานค้างตอน restart
• The Twelve-Factor App — IX. Disposability — อ่านย่อหน้าที่ขึ้นต้นด้วย "For a worker process": ตอนปิดอย่างสุภาพ worker ต้องคืนงานเข้าคิว · ทุก job จึงต้องทนการทำซ้ำ (idempotent) · และย่อหน้าถัดไปเรื่อง "sudden death"
• rails/solid_queue (README) — ยังไม่ต้องอ่านตอนนี้ · เก็บไว้เปิดคู่กับบท 143 (คิวที่เก็บงานในฐานข้อมูล ปิดโปรแกรมแล้วงานไม่หาย)