Hiểu Rõ SQS Visibility Timeout: Tại Sao Message Bị Xử Lý Hai Lần?

Bạn đang chạy một hệ thống xử lý đơn hàng, consumer đọc message từ SQS, nhưng log lại cho thấy cùng một message được xử lý bởi hai worker khác nhau — đôi khi dẫn đến giao dịch trùng lặp. Đây là triệu chứng kinh điển của SQS Visibility Timeout bị cấu hình sai, và nó thường bị bỏ qua cho đến khi production bắt đầu có vấn đề.

TL;DR — SQS Visibility Timeout là gì và tại sao nó quan trọng

Vấn đềNguyên nhânGiải pháp
Message bị xử lý hai lầnVisibility Timeout ngắn hơn thời gian xử lý thực tếTăng timeout hoặc dùng ChangeMessageVisibility
Message không bao giờ bị xóaConsumer xử lý xong nhưng quên gọi DeleteMessageLuôn xóa message sau khi xử lý thành công
Message kẹt trong queue mãi mãiConsumer crash trước khi timeout hếtCấu hình Dead Letter Queue

Cơ Chế Hoạt Động Của SQS Visibility Timeout

SQS không phải là message broker theo mô hình push — consumer chủ động poll để nhận message. Khi một consumer gọi ReceiveMessage, SQS không xóa message ngay lập tức. Thay vào đó, message bị ẩn khỏi các consumer khác trong một khoảng thời gian gọi là Visibility Timeout. Trong khoảng thời gian này, consumer đang giữ message phải xử lý xong và gọi DeleteMessage. Nếu không làm vậy trước khi timeout hết, message sẽ tự động hiện trở lại trong queue và có thể bị consumer khác nhận.

Hãy tưởng tượng visibility timeout như một chiếc vé số tạm thời: bạn cầm vé, không ai khác có thể nhận cùng vé đó — nhưng nếu bạn không đổi thưởng trước khi vé hết hạn, nó quay lại hộp và người khác có thể rút ra.

Giá trị mặc định của Visibility Timeout là 30 giây. Giá trị tối thiểu là 0 giây, tối đa là 12 giờ. Đây là cấu hình ở cấp queue, nhưng có thể override ở cấp message thông qua API.

graph TD A["Message M1 trong Queue"] --> B["Consumer A gọi ReceiveMessage"] B --> C["M1 bị ẩn
Visibility Timeout bắt đầu"] C --> D{"Consumer A xử lý xong
trước khi timeout?"} D -- "Có" --> E["Consumer A gọi DeleteMessage"] E --> F["M1 bị xóa vĩnh viễn"] D -- "Không" --> G["Timeout hết
M1 hiện trở lại queue"] G --> H["Consumer B nhận M1"] H --> I["Xử lý trùng lặp!"] style I fill:#ff6b6b,color:#fff style F fill:#51cf66,color:#fff
  1. Consumer A gọi ReceiveMessage — message M1 bị ẩn khỏi queue trong suốt Visibility Timeout.
  2. Nếu Consumer A xử lý xong và gọi DeleteMessage trước khi timeout hết → M1 bị xóa vĩnh viễn.
  3. Nếu Consumer A xử lý chậm và timeout hết trước → M1 hiện trở lại, Consumer B có thể nhận và xử lý lại.
  4. Đây là nguồn gốc của việc message bị xử lý hai lần.

Tại Sao Visibility Timeout Sai Gây Ra Xử Lý Trùng Lặp

Vấn đề thực tế không phải lúc nào cũng rõ ràng. Consumer của bạn có thể xử lý message trong 25 giây ở môi trường staging, nhưng khi production tải cao, cùng logic đó mất 45 giây vì database query chậm hơn, hoặc một API bên thứ ba phản hồi chậm. Visibility Timeout mặc định 30 giây không đủ — message hiện lại, consumer thứ hai nhận và bắt đầu xử lý, trong khi consumer đầu tiên vẫn đang chạy.

Điều khiến tình huống này khó debug hơn: cả hai consumer đều không báo lỗi. Từ góc nhìn của từng consumer, chúng đang làm đúng việc của mình. Chỉ khi nhìn vào downstream effect — đơn hàng bị tạo hai lần, email xác nhận gửi hai lần — bạn mới phát hiện ra.

sequenceDiagram participant Q as SQS Queue participant A as Consumer A participant B as Consumer B Q->>A: ReceiveMessage (T=0s) Note over Q: M1 invisible, timeout=30s A->>A: Đang xử lý... Note over Q,A: T=30s: Timeout hết! Note over Q: M1 hiện trở lại Q->>B: ReceiveMessage (T=31s) B->>B: Đang xử lý song song! A->>Q: DeleteMessage (T=45s) B->>Q: DeleteMessage (T=50s) Note over Q,B: Cả hai đều xử lý M1 thành công
  1. Consumer A nhận M1 lúc T=0, visibility timeout = 30s.
  2. Lúc T=30s, Consumer A vẫn đang xử lý — timeout hết, M1 hiện trở lại.
  3. Consumer B nhận M1 lúc T=31s và bắt đầu xử lý song song với Consumer A.
  4. Cả hai consumer đều xử lý thành công và gọi DeleteMessage — nhưng thiệt hại đã xảy ra.

Cách Kiểm Tra Visibility Timeout Hiện Tại Của Queue

Trước khi thay đổi bất cứ thứ gì, hãy xác nhận cấu hình hiện tại. Lệnh dưới đây lấy thuộc tính của queue bao gồm VisibilityTimeout:

aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-order-queue \
  --attribute-names VisibilityTimeout

Kết quả trả về dạng:

{
    "Attributes": {
        "VisibilityTimeout": "30"
    }
}

Nếu con số này nhỏ hơn thời gian xử lý tối đa của consumer trong worst case, đây là nguyên nhân trực tiếp.

Giải Pháp 1: Tăng Visibility Timeout Ở Cấp Queue

Đây là giải pháp đơn giản nhất khi thời gian xử lý tương đối ổn định và có thể dự đoán được. AWS khuyến nghị đặt Visibility Timeout bằng ít nhất 6 lần thời gian xử lý trung bình của consumer — con số này tính đến retry và jitter. Trong thực tế, hãy đo thời gian xử lý p99 của bạn và nhân đôi nó.

aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-order-queue \
  --attributes VisibilityTimeout=300

Lệnh này đặt Visibility Timeout thành 300 giây (5 phút). Thay đổi này áp dụng cho tất cả message mới được nhận sau thời điểm thay đổi — không ảnh hưởng đến message đang trong flight.

Giải Pháp 2: Gia Hạn Visibility Timeout Động Trong Quá Trình Xử Lý

Khi thời gian xử lý không thể dự đoán — ví dụ phụ thuộc vào kích thước payload hoặc độ trễ của service bên ngoài — giải pháp tốt hơn là gia hạn timeout định kỳ trong khi consumer đang xử lý. API ChangeMessageVisibility cho phép làm điều này.

Cách tiếp cận thực tế: chạy một background thread hoặc coroutine song song với logic xử lý chính, định kỳ gọi ChangeMessageVisibility để gia hạn thêm thời gian trước khi timeout hiện tại hết.

aws sqs change-message-visibility \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-order-queue \
  --receipt-handle "AQEBwJnKyrHigUMZj6reyNurzbVSnXXXXXXXXXXXXXX..." \
  --visibility-timeout 60

--receipt-handle là giá trị trả về từ lần gọi ReceiveMessage ban đầu — không phải Message ID. Đây là lỗi phổ biến khi implement lần đầu.

graph LR A["Consumer nhận Message"] --> B["Bắt đầu xử lý"] A --> C["Khởi động Heartbeat Timer"] C --> D["ChangeMessageVisibility
mỗi N giây"] D --> D B --> E{"Xử lý xong?"} E -- "Thành công" --> F["DeleteMessage"] F --> G["Dừng Heartbeat"] E -- "Lỗi / Crash" --> H["Heartbeat dừng"] H --> I["Timeout hết tự nhiên"] I --> J["Message trở lại Queue"] style F fill:#51cf66,color:#fff style J fill:#ffd43b
  1. Consumer nhận message và bắt đầu xử lý, đồng thời khởi động heartbeat timer.
  2. Heartbeat định kỳ gọi ChangeMessageVisibility để gia hạn timeout.
  3. Khi xử lý hoàn thành, consumer gọi DeleteMessage và dừng heartbeat.
  4. Nếu consumer crash, heartbeat dừng, timeout hết tự nhiên và message trở lại queue.

Giải Pháp 3: Cấu Hình Dead Letter Queue Để Bắt Message Lỗi

Visibility Timeout giải quyết vấn đề xử lý trùng lặp, nhưng không giải quyết trường hợp message bị lỗi liên tục. Nếu consumer luôn crash khi xử lý một message cụ thể, message đó sẽ liên tục quay lại queue và tiêu tốn tài nguyên. Dead Letter Queue (DLQ) là cơ chế để bắt các message này sau một số lần retry nhất định (maxReceiveCount).

🔽 Xem cấu hình Redrive Policy cho DLQ 
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-order-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123456789012:my-order-dlq\",\"maxReceiveCount\":\"5\"}"
  }'

Với cấu hình này, sau 5 lần message được nhận mà không bị xóa, nó tự động chuyển sang DLQ. Đây là safety net quan trọng — không thay thế việc cấu hình Visibility Timeout đúng, nhưng ngăn poison message làm tắc nghẽn queue chính.

Kinh Nghiệm Thực Tế: Misdiagnosis Phổ Biến Nhất

Một tình huống hay gặp: team phát hiện message bị xử lý hai lần, ngay lập tức nghi ngờ consumer code có bug — có thể là race condition hoặc lỗi idempotency. Họ dành nhiều giờ review code, thêm lock, thêm log. Không tìm ra gì.

Sau đó nhìn vào CloudWatch metric ApproximateNumberOfMessagesNotVisible — số message đang trong trạng thái 'invisible' — và thấy nó dao động bất thường. Kiểm tra Visibility Timeout: 30 giây. Đo thời gian xử lý thực tế trong production: trung bình 28 giây, p99 là 47 giây.

Vấn đề không phải ở code. Visibility Timeout 30 giây đủ cho trường hợp trung bình nhưng không đủ cho p99. Trong giờ cao điểm, khi latency tăng, khoảng 1% message bị xử lý hai lần — đủ để gây ra sự cố nhưng không đủ để trigger alert rõ ràng.

Fix: tăng Visibility Timeout lên 120 giây. Vấn đề biến mất ngay lập tức.

Bài học: luôn đo p99 processing time trước khi đặt Visibility Timeout, không phải average.

Monitoring Visibility Timeout Với CloudWatch

Hai metric quan trọng nhất để theo dõi:

aws cloudwatch get-metric-statistics \
  --namespace AWS/SQS \
  --metric-name ApproximateNumberOfMessagesNotVisible \
  --dimensions Name=QueueName,Value=my-order-queue \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 60 \
  --statistics Average

ApproximateNumberOfMessagesNotVisible tăng đột biến và không giảm là dấu hiệu consumer đang giữ message quá lâu hoặc bị stuck. ApproximateAgeOfOldestMessage tăng liên tục cho thấy throughput không đủ hoặc message đang bị retry nhiều lần.

IAM Permissions Cần Thiết

Consumer cần các quyền sau để thực hiện đầy đủ vòng đời message:

🔽 Xem IAM Policy cho SQS Consumer 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SQSConsumerPermissions",
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:ChangeMessageVisibility",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:my-order-queue"
    }
  ]
}

Lưu ý: sqs:ChangeMessageVisibility thường bị bỏ sót khi cấp quyền ban đầu — nếu consumer cần gia hạn timeout động, thiếu quyền này sẽ gây lỗi runtime không rõ ràng.

Tổng Kết và Bước Tiếp Theo

SQS Visibility Timeout là cơ chế bảo vệ chống mất message, không phải cơ chế đảm bảo xử lý đúng một lần. SQS Standard Queue theo thiết kế cung cấp at-least-once delivery — consumer code phải được thiết kế idempotent. Visibility Timeout chỉ giảm thiểu xác suất xử lý trùng lặp khi được cấu hình đúng.

Nếu hệ thống của bạn yêu cầu exactly-once processing nghiêm ngặt, hãy xem xét SQS FIFO Queue với tính năng deduplication, hoặc implement idempotency key ở tầng application.

  • Đo p99 processing time của consumer trước khi đặt Visibility Timeout
  • Implement heartbeat để gia hạn timeout động cho workload không đồng đều
  • Luôn cấu hình Dead Letter Queue với maxReceiveCount phù hợp
  • Monitor ApproximateNumberOfMessagesNotVisible để phát hiện sớm vấn đề
  • Tham khảo: AWS SQS Visibility Timeout Documentation

Glossary — Thuật Ngữ Chính

Thuật ngữGiải thích
Visibility TimeoutKhoảng thời gian message bị ẩn khỏi queue sau khi được consumer nhận, tính bằng giây.
Receipt HandleToken định danh duy nhất cho một lần nhận message cụ thể, dùng để xóa hoặc gia hạn timeout.
Dead Letter Queue (DLQ)Queue phụ nhận message sau khi vượt quá số lần retry cho phép.
At-least-once DeliveryĐảm bảo message được giao ít nhất một lần, có thể nhiều hơn — đặc tính của SQS Standard.
In-flight MessageMessage đã được consumer nhận nhưng chưa bị xóa, đang trong trạng thái invisible.

Nhận xét

Đăng nhận xét

Bài đăng phổ biến từ blog này

EC2 Không Có Internet Trong Custom VPC: Cách Gắn Internet Gateway và Cập Nhật Route Table

Bạn tạo một custom VPC, launch EC2 instance vào public subnet, SSH vào được — nhưng ping google.com trả về timeout hoàn toàn. Đây là một trong những lỗi phổ biến nhất khi làm việc với EC2 không có internet trong custom VPC, và nguyên nhân gần như luôn nằm ở một trong ba lớp: thiếu Internet Gateway, route table chưa có default route, hoặc Security Group/NACL chặn traffic ra ngoài. TL;DR — EC2 Không Có Internet Trong Custom VPC Lớp kiểm tra Triệu chứng Fix Internet Gateway Không có IGW hoặc IGW chưa attach vào VPC Tạo IGW, attach vào VPC Route Table Không có route 0.0.0.0/0 → igw-xxx Thêm default route trỏ vào IGW Subnet Association Subnet dùng main route table không có IGW route Associate subnet với route table đúng Public IP EC2 không có public IP hoặc Elastic IP Enable auto-assign public IP hoặc gắn EIP Security Group Outbound rule bị xóa hoặc quá hạn chế Thêm outbound rule cho port 80/443 hoặc all...
Đọc thêm

Route 53 Alias vs CNAME: Khi Nào Dùng Alias Record Cho Zone Apex?

Bạn vừa tạo xong một Application Load Balancer và cần trỏ domain về đó — nhưng Route 53 hiện ra hai lựa chọn: CNAME và Alias. Nếu domain là example.com (zone apex), CNAME sẽ không hoạt động theo đúng nghĩa bạn mong đợi, và đây là lý do nhiều kỹ sư mất thời gian debug một vấn đề tưởng như đơn giản. TL;DR — Route 53 Alias vs CNAME Tiêu chí CNAME Alias Record Dùng được ở zone apex ( example.com ) ❌ Không ✅ Có Phí DNS query Tính phí Miễn phí (với AWS targets) Trả về IP hay hostname Hostname IP trực tiếp (resolved nội bộ) Tích hợp health check Route 53 Hạn chế Tích hợp native TTL do người dùng kiểm soát ✅ Có ❌ AWS quản lý Targets hỗ trợ Bất kỳ hostname nào Chỉ AWS resources được liệt kê Cơ Chế Hoạt Động: Route 53 Alias Record Là Gì? Alias record là một extension độc quyền của Route 53, không phải một loại DNS record chuẩn trong RFC. Về mặt kỹ thuật, nó hoạt động như một CNAME nội bộ được Rout...
Đọc thêm