Đồng thờiConcurrency

Producer-Consumeraka Bounded Buffer, Work Queue

Bên sinh việc bỏ vào hàng đợi, bên xử lý lấy ra — hai bên chạy độc lập, khác tốc độ.Producers put work into a queue, consumers take it out — both run independently at their own pace.

Độ khóDifficulty: VừaMedium
Mức phổ biếnUsage: Mức phổ biếnUsage 5/5
Thời gian đọcReading time: ~9 phút đọc~9 min read

Thảo luậnDiscussion

Ví dụ đời thườngReal-life analogy

Quán trà sữa giờ cao điểm: thu ngân nhận order rồi ghim phiếu lên thanh treo, các bạn pha chế cứ rảnh tay là gỡ phiếu xuống làm. Thu ngân không cần đứng chờ ly trước pha xong. Nhưng thanh treo chỉ ghim được 20 phiếu — đầy thì thu ngân phải nói khách chờ chút.A bubble-tea shop at rush hour: the cashier takes orders and pins tickets on a rail, and baristas grab a ticket whenever their hands are free. The cashier never waits for a drink to be finished. But the rail only holds 20 tickets — when it's full, the cashier has to ask customers to wait.

Vấn đề và giải phápProblem and solution

Không có patternWithout the pattern

Sau khi đặt hàng thành công, API phải gửi email + tin Zalo xác nhận. Nếu gửi ngay trong request, khách phải chờ thêm 1–2 giây vì nhà cung cấp email chậm, và lúc flash sale 10.000 đơn/phút thì mọi thread HTTP đều kẹt chờ mạng. Phần nhận đơn và phần gửi thông báo bị trói chặt vào cùng một tốc độ.After an order is placed, the API must send an email + Zalo confirmation. Sending inline makes customers wait 1–2 extra seconds because the email provider is slow, and during a 10,000-orders-per-minute flash sale every HTTP thread is stuck on the network. Taking orders and sending notifications are chained to the same speed.

Với Producer-ConsumerWith Producer-Consumer

Chèn một hàng đợi có giới hạn (bounded) vào giữa. Producer (handler đặt hàng) chỉ việc đẩy sự kiện vào queue rồi trả lời khách ngay. Một nhóm consumer chạy nền lấy sự kiện ra gửi thông báo. Queue hấp thụ đỉnh tải; khi đầy, producer bị chặn hoặc từ chối — đó là backpressure tự nhiên.Put a bounded queue in between. The producer (order handler) just pushes an event into the queue and answers the customer right away. A group of background consumers takes events out and sends notifications. The queue absorbs bursts; when it's full, producers block or get rejected — natural backpressure.

Thành phần tham giaParticipants

Producer: Tạo ra công việc/sự kiện và đẩy vào queue.Creates work/events and pushes them into the queue.
Queue / Channel: Bộ đệm thread-safe có sức chứa giới hạn, nối hai bên.Thread-safe buffer with a bounded capacity connecting both sides.
Consumer: Lấy việc ra xử lý; có thể chạy nhiều consumer song song.Takes work out and processes it; many consumers can run in parallel.
Owner / Closer: Bên duy nhất được báo 'hết việc' (close channel, poison pill, interrupt).The single party allowed to signal 'no more work' (close channel, poison pill, interrupt).

Sơ đồ và luồng thực thiDiagram and execution flow

Dùng Tự chạy hoặc phím mũi tên để đi qua từng bước gọi giữa các object. Console hiển thị output tương ứng của chương trình.Use Autoplay or the arrow keys to step through each call between objects. The console shows the matching program output.

1Khách đặt đơn A1. Handler đẩy sự kiện vào channel rồi trả HTTP 201 ngay — không chờ gửi email.A customer places order A1. The handler pushes the event into the channel and returns HTTP 201 immediately — no waiting for email.

← →

console

1produce A1 (len=1/100)

implementsimplementsextendsextendsgọi / dùngcalls / usestạo racreatesgửi qua channelsends via channel1thứ tự chạy (bấm để nhảy bước)execution order (click to jump)

Code: Java Spring Boot ⇄ GoCode: Java Spring Boot ⇄ Go

Cùng một bài toán, hai ngôn ngữ. Rê chuột hoặc focus vào chú thích (số màu cam) để làm nổi bật dòng code tương ứng.Same problem, two languages. Hover or focus an annotation (orange number) to highlight its line.

JavaSpring Boot 3 · Java 21Spring Boot 3 · Java 21

package com.shop.order;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;

record OrderPlaced(String orderId, String email, long amount) {}1

@Configuration
class QueueConfig {
    // Bounded: when full, producers must wait -> natural backpressure
    @Bean
    BlockingQueue<OrderPlaced> orderQueue() {2
        return new ArrayBlockingQueue<>(1_000);3
    }
}

GoGo 1.23 · thư viện chuẩnGo 1.23 · standard library

package notify

import "context"

type OrderPlaced struct {
	OrderID string
	Email   string
	Amount  int64
}

// Produce owns the channel, so it is the ONLY one allowed to close it.
func Produce(ctx context.Context, orders []OrderPlaced) <-chan OrderPlaced {1
	out := make(chan OrderPlaced, 100) // the buffer IS the bounded queue2
	go func() {
		defer close(out)3
		for _, o := range orders {
			select {
			case out <- o: // blocks while the buffer is full
			case <-ctx.Done():4
				return
			}
		}
	}()
	return out
}

Khác biệt chính giữa Java và GoKey differences between Java and Go

01Java: queue là một object (BlockingQueue) với put/take/offer. Go: queue được tích hợp vào ngôn ngữ — buffered channel với <-.Java: the queue is an object (BlockingQueue) with put/take/offer. Go: the queue is built into the language — a buffered channel with <-.
02Báo 'hết việc': Go close(channel) và for range tự dừng. Java không có 'close' cho BlockingQueue — phải dùng poison pill hoặc interrupt thread.Signalling 'no more work': Go closes the channel and for range stops. Java's BlockingQueue has no 'close' — use a poison pill or interrupt the threads.
03Go có select để chờ nhiều channel cùng lúc (gửi HOẶC bị huỷ). Java dùng offer/poll với timeout để không chặn mãi.Go has select to wait on several channels at once (send OR cancel). Java uses offer/poll with a timeout to avoid blocking forever.
04Spring thường giấu pattern này sau @Async + ThreadPoolTaskExecutor (bên trong cũng là một queue + thread). Go thì bạn tự viết tường minh vài dòng.Spring often hides this pattern behind @Async + ThreadPoolTaskExecutor (internally also a queue + threads). In Go you write it explicitly in a few lines.

Ứng dụng thực tếReal-world usage

@Async và ThreadPoolTaskExecutor@Async and ThreadPoolTaskExecutor
Gọi method @Async là đẩy một task vào queue của executor; các thread trong pool là consumer. queueCapacity chính là sức chứa buffer.Calling an @Async method pushes a task into the executor's queue; pool threads are the consumers. queueCapacity is the buffer size.
Kafka / RabbitMQ / SQSKafka / RabbitMQ / SQS
Phiên bản phân tán và bền vững của cùng ý tưởng: service đặt hàng publish, service thông báo consume — sống sót cả khi restart.The distributed, durable version of the same idea: the order service publishes, the notification service consumes — survives restarts.
Logger bất đồng bộAsync loggers
Logback AsyncAppender, zap/zerolog buffered writer: thread nghiệp vụ bỏ log vào buffer, một goroutine/thread nền ghi ra đĩa.Logback AsyncAppender, zap/zerolog buffered writers: business threads drop logs into a buffer, one background thread/goroutine writes to disk.
Gửi thông báo sau đặt hàngPost-order notifications
Shop thương mại điện tử nhận đơn thật nhanh, còn email/SMS/Zalo được gửi dần phía sau với số consumer cố định.An e-commerce shop accepts orders fast, while email/SMS/Zalo messages are sent gradually in the background by a fixed number of consumers.

Khi nào dùng và khi nào khôngWhen to use it, and when not

Nên dùng khiUse it when

Bên sinh việc và bên xử lý có tốc độ khác nhau hoặc tải dao động theo đợt.Producers and consumers run at different speeds or the load comes in bursts.
Muốn trả lời người dùng nhanh và đẩy phần chậm (email, resize ảnh, ghi log) ra chạy nền.You want to answer users fast and push slow parts (email, image resize, logging) to the background.
Cần giới hạn số việc chạy đồng thời và có backpressure khi quá tải.You need to cap concurrent work and get backpressure under overload.

Không nên dùng khiAvoid it when

Người gọi cần kết quả ngay trong cùng request — dùng lời gọi đồng bộ hoặc Future.The caller needs the result in the same request — use a synchronous call or a Future.
Mất việc khi crash là không chấp nhận được — queue trong RAM sẽ mất sạch; dùng message broker hoặc Transactional Outbox.Losing work on a crash is unacceptable — an in-memory queue vanishes; use a message broker or a Transactional Outbox.

Ưu điểmPros

Tách rời producer và consumer: mỗi bên scale và thay đổi độc lập.Decouples producers and consumers: each side scales and changes independently.
Hấp thụ đỉnh tải; queue có giới hạn cho backpressure tự nhiên.Absorbs bursts; a bounded queue gives natural backpressure.
Request của người dùng nhanh hơn vì phần chậm chạy nền.User requests get faster because slow work runs in the background.

Nhược điểmCons

Queue trong bộ nhớ mất dữ liệu khi app crash hoặc deploy.An in-memory queue loses data when the app crashes or redeploys.
Dễ dính lỗi tắt máy: quên close channel → goroutine leak; close hai lần hoặc gửi vào channel đã close → panic; Java quên khôi phục interrupt → thread không dừng.Shutdown bugs are easy: forget to close → goroutine leak; double close or send on a closed channel → panic; in Java, forgetting to restore the interrupt → threads never stop.
Khó debug và trace hơn vì việc xử lý xảy ra ở thread/goroutine khác.Harder to debug and trace because processing happens on another thread/goroutine.

Anti-pattern: lỗi thường gặpAnti-pattern: common mistake

Consumer close channel (và close nhiều lần)Consumers closing the channel (more than once)

Consumer không biết producer đã gửi xong hay chưa. Nếu consumer close, producer gửi tiếp sẽ panic 'send on closed channel'; nhiều consumer cùng close thì panic 'close of closed channel'. Quy tắc: chỉ bên GỬI (và chỉ một bên) được close.Consumers can't know whether the producer is done. If a consumer closes, the producer's next send panics with 'send on closed channel'; several consumers closing panics with 'close of closed channel'. Rule: only the SENDER (exactly one) closes.

func consume(in chan OrderPlaced, wg *sync.WaitGroup) {
	defer wg.Done()
	for {
		o, ok := <-in
		if !ok {
			return
		}
		send(o)
		if len(in) == 0 {
			close(in) // ❌ consumer closes: producer panics on next send,
			// ❌ and two consumers here = "close of closed channel"
		}
	}
}

Dễ nhầm vớiEasily confused with

Producer-Consumer vs Publish-Subscribe

Producer-Consumer: mỗi message chỉ MỘT consumer nhận (chia việc). Pub-Sub: mỗi message được phát tới MỌI subscriber (phát sóng).Producer-Consumer: each message goes to ONE consumer (work sharing). Pub-Sub: each message is broadcast to EVERY subscriber.

Producer-Consumer vs Worker Pool

Producer-Consumer nhấn mạnh việc tách rời hai bên qua hàng đợi. Worker Pool nhấn mạnh việc giới hạn N worker cố định để xử lý một lô job và thường gom kết quả.Producer-Consumer emphasises decoupling two sides through a queue. Worker Pool emphasises a fixed N workers processing a batch of jobs, usually collecting results.

Bài tập áp dụngExercise

Thêm kênh gửi SMS: mỗi đơn hàng cần cả email lẫn SMS, nhưng nhà mạng SMS chỉ cho tối đa 2 request đồng thời. Thiết kế producer/consumer phù hợp.Add an SMS channel: every order needs both an email and an SMS, but the SMS gateway allows at most 2 concurrent requests. Design a suitable producer/consumer setup.

Kiểm tra kiến thứcKnowledge check

Câu 1 / 6Question 1 of 6

Lợi ích cốt lõi của Producer-Consumer là gì?What is the core benefit of Producer-Consumer?

Phím 1–4 để chọn đáp án, Enter để kiểm tra.Press 1–4 to choose an answer, Enter to check.

Thẻ ghi nhớFlashcards

Ôn tập ngắt quãng (spaced repetition): thẻ được lặp lại sau 1 → 3 → 7 → 14 → 30 ngày để củng cố trí nhớ dài hạn.Spaced repetition: cards are repeated after 1 → 3 → 7 → 14 → 30 days to build long-term memory.

Dùng trong bài toánUsed in problems

2 bài toán Backend dùng pattern này2 backend problems use this pattern

Pattern liên quanRelated patterns

Worker Pool Pipeline Publish-Subscribe Transactional Outbox

Thảo luậnDiscussion

Producer-Consumeraka Bounded Buffer, Work Queue

VừaMedium

Mức phổ biếnUsage 5/5

~9 phút đọc~9 min read

package com.shop.order; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.BlockingQueue; record OrderPlaced(String orderId, String email, long amount) {}1 @Configuration class QueueConfig { // Bounded: when full, producers must wait -> natural backpressure @Bean BlockingQueue<OrderPlaced> orderQueue() {2 return new ArrayBlockingQueue<>(1_000);3 } }

package notify import "context" type OrderPlaced struct { OrderID string Email string Amount int64 } // Produce owns the channel, so it is the ONLY one allowed to close it. func Produce(ctx context.Context, orders []OrderPlaced) <-chan OrderPlaced {1 out := make(chan OrderPlaced, 100) // the buffer IS the bounded queue2 go func() { defer close(out)3 for _, o := range orders { select { case out <- o: // blocks while the buffer is full case <-ctx.Done():4 return } } }() return out }

func consume(in chan OrderPlaced, wg *sync.WaitGroup) { defer wg.Done() for { o, ok := <-in if !ok { return } send(o) if len(in) == 0 { close(in) // ❌ consumer closes: producer panics on next send, // ❌ and two consumers here = "close of closed channel" } } }