Amazon SQS visibility timeout crawler: task dài và giao lại
Amazon SQS visibility timeout crawler là cách đặt và điều chỉnh khoảng thời gian một thông điệp bị ẩn khỏi các worker khác sau khi đã được một worker nhận. Mục đích là để task tải trang dài không bị giao cho người khác giữa chừng. Đặt quá ngắn, trang chậm bị tải hai lần. Đặt quá dài, worker chết thì task nằm im rất lâu mới được giao lại. ProxyVN chạy thử ngày 03/11/2026 với boto3 trên SQS giả lập bằng moto 5.2.5, cho task vượt thời hạn, gia hạn định kỳ, lỗi liên tục cho tới hàng đợi lỗi, và trả thông điệp về sớm. Bài ghi rõ đây là giả lập, không phải SQS thật.
Amazon SQS visibility timeout crawler: mục tiêu và phạm vi không lặp
Phần này chốt bài toán, đầu ra và giới hạn.
Bài toán
Một crawler đưa URL vào hàng đợi SQS, nhiều worker nhận và tải. Phần lớn trang tải trong vài giây, một số trang chậm mất cả phút. Nhóm thấy cùng một URL bị tải hai, ba lần, dữ liệu trùng trong kho. Họ cần biết visibility timeout hoạt động thế nào, phát hiện task bị giao lại ra sao, và chỉnh thế nào cho task dài.
Đầu ra nghiệm thu
Đầu ra là nhật ký các ca. Task dài hơn timeout bị giao cho worker khác, số lần nhận tăng lên. Gia hạn bằng ChangeMessageVisibility giữ được task, thông điệp lỗi liên tục chuyển sang hàng đợi lỗi sau đúng số lần cấu hình. Kèm theo là quy tắc chọn timeout và cách viết worker không xử lý trùng.
Không coi hàng đợi là exactly once
Hàng đợi SQS chuẩn giao mỗi thông điệp ít nhất một lần, không bảo đảm đúng một lần. Ngay cả khi cấu hình visibility đúng, worker vẫn có thể nhận cùng thông điệp hai lần. Bài không hứa loại bỏ được trùng lặp bằng cấu hình. Worker phải tự chịu được trùng.
Giới hạn của lab
Lab không gọi SQS thật trên AWS. Mọi lệnh chạy trên moto 5.2.5, thư viện giả lập dịch vụ AWS trong bộ nhớ, với boto3 1.43. Moto mô phỏng các thuộc tính chính như VisibilityTimeout, ApproximateReceiveCount, RedrivePolicy, nhưng có thể khác SQS thật ở chi tiết. Chỗ nào nghi khác, bài ghi rõ.
Ai nên đọc
Người chạy crawler phân tán dùng SQS làm hàng đợi URL. Người thấy dữ liệu trùng và nghi hàng đợi giao lại. Người cần chọn visibility timeout cho task có thời gian chạy dao động lớn.
Vì sao dùng hàng đợi cho crawler
Hàng đợi tách việc phát hiện URL khỏi việc tải. Một tiến trình đưa URL vào, nhiều worker trên nhiều máy lấy ra. Thêm worker là tăng tốc độ tải mà không sửa gì ở phía đưa URL. Worker chết không làm mất URL, vì URL chưa bị xóa sẽ hiện lại sau visibility timeout.
Vì sao dùng moto
Moto cho phép chạy cùng mã boto3 không cần tài khoản AWS, không tốn tiền, kết quả lặp lại được. Thời gian chạy thật vẫn trôi, nên có thể đo visibility timeout bằng giây. Đổi lại, mọi kết luận cần được kiểm lại trên SQS thật trước khi dựa vào chúng ở môi trường chạy.
Điều chỉnh visibility timeout cho task tải web dài và phát hiện task được giao lại với Amazon SQS visibility timeout crawler
Phần này tóm tắt tài liệu của AWS.
Visibility timeout là gì
Theo trang Amazon SQS visibility timeout trong tài liệu dành cho nhà phát triển, khi một consumer nhận thông điệp, thông điệp vẫn nằm trong hàng đợi nhưng bị ẩn khỏi các consumer khác trong một khoảng thời gian. Nếu consumer xử lý xong và xóa thông điệp trong khoảng đó, thông điệp biến mất. Nếu không, thông điệp hiện lại và có thể được giao cho consumer khác.
Giá trị mặc định và giới hạn
Tài liệu ghi visibility timeout mặc định 30 giây, tối thiểu 0, tối đa 12 giờ. Có thể đặt ở mức hàng đợi, và đổi cho từng thông điệp bằng ChangeMessageVisibility. Lab thử đặt 43.201 giây, vượt 12 giờ một giây, moto báo InvalidParameterValue.
Đặt theo thời gian xử lý
Tài liệu khuyên đặt timeout dài hơn thời gian consumer cần để xử lý và xóa thông điệp. Nếu không chắc thời gian xử lý, dùng cơ chế gia hạn: consumer định kỳ gọi ChangeMessageVisibility để kéo dài thời gian ẩn khi còn đang làm.
Ít nhất một lần
Tài liệu cũng nêu hàng đợi chuẩn có thể giao một thông điệp nhiều lần, và ứng dụng nên được thiết kế để xử lý trùng không gây hại. Visibility timeout giảm khả năng trùng, không loại bỏ nó.
Receipt handle
Mỗi lần nhận, SQS trả một receipt handle, là chìa khóa để xóa hay gia hạn thông điệp đó. Handle gắn với lần nhận, không gắn với thông điệp. Worker phải giữ handle của lần nhận của mình suốt thời gian xử lý, và dùng nó cho mọi lệnh tiếp theo trên thông điệp.
ApproximateReceiveCount
Mỗi thông điệp có thuộc tính ApproximateReceiveCount, đếm số lần đã được nhận. Worker yêu cầu thuộc tính này khi nhận. Giá trị lớn hơn 1 nghĩa là thông điệp đã từng được giao mà chưa bị xóa, tức có worker trước đã không làm xong hoặc làm quá lâu.
Thời gian lưu thông điệp
Ngoài visibility timeout, hàng đợi có thời gian lưu thông điệp, mặc định bốn ngày theo tài liệu SQS. Thông điệp không ai xử lý quá thời gian này sẽ bị xóa. Với crawler chạy liên tục, thông điệp hiếm khi nằm lâu như vậy, trừ khi mọi worker đều ngừng. Hàng đợi lỗi nên có thời gian lưu dài hơn hàng đợi chính để kịp điều tra.
Hàng đợi lỗi
RedrivePolicy chỉ định một hàng đợi lỗi và maxReceiveCount. Khi một thông điệp bị nhận quá số lần này mà không bị xóa, SQS chuyển nó sang hàng đợi lỗi. Nhờ vậy, URL luôn làm worker lỗi không xoay vòng mãi trong hàng đợi chính.
Dựng hàng đợi crawl với timeout ngắn để đo trong Amazon SQS visibility timeout crawler
Phần này tạo hàng đợi và mô tả cách đo.
Hai hàng đợi
Hai hàng đợi
dlq = sqs.create_queue(QueueName="crawl-dlq")["QueueUrl"]
q = sqs.create_queue(QueueName="crawl", Attributes={
"VisibilityTimeout": "2",
"RedrivePolicy": json.dumps({"deadLetterTargetArn": dlq_arn,
"maxReceiveCount": "3"})})["QueueUrl"]Hàng đợi chính crawl có visibility timeout 2 giây để đo nhanh, và chuyển thông điệp sang crawl-dlq sau 3 lần nhận. Ngoài thực tế, 2 giây là quá ngắn cho tải trang. Lab dùng con số nhỏ để mỗi ca chạy trong vài giây.
Hàm nhận
Hàm recv gọi receive_message lấy tối đa 1 thông điệp, yêu cầu thuộc tính ApproximateReceiveCount, không chờ lâu. In ra thời điểm, tên worker, URL và số lần nhận. Nếu không có thông điệp, in không nhận được.
Đồng hồ thật
Moto dùng đồng hồ hệ thống. time.sleep 2,5 giây trong lab là 2,5 giây thật. Thời điểm in ra là số giây từ khi bắt đầu chương trình, giúp đọc nhật ký theo dòng thời gian.
Hàng đợi chuẩn hay FIFO
Lab dùng hàng đợi chuẩn, giao ít nhất một lần, thứ tự không bảo đảm. Hàng đợi FIFO giữ thứ tự và có khử trùng theo mã trong một khoảng thời gian, nhưng thông lượng thấp hơn. Với crawler, thứ tự URL hiếm khi quan trọng, nên hàng đợi chuẩn cùng worker chịu được trùng thường là lựa chọn đơn giản hơn.
Thông điệp mang URL
Mỗi thông điệp là JSON chứa url. Ngoài thực tế nên kèm mã task, số lần thử và thời điểm tạo để worker và người điều tra dùng. Lab giữ tối giản.
Nhận theo lô
receive_message nhận tối đa 10 thông điệp mỗi lần. Nhận theo lô giảm số lần gọi, nhưng mọi thông điệp trong lô cùng bắt đầu đếm visibility timeout lúc nhận. Nếu worker xử lý tuần tự 10 URL, URL cuối có thể quá hạn trước khi tới lượt. Với task dài, nhận ít thông điệp mỗi lần, hoặc gia hạn cho cả lô.
Long polling
Lab đặt WaitTimeSeconds bằng 0 để nhận trả về ngay. Ngoài thực tế, long polling với vài giây giúp giảm số lần gọi rỗng và giảm chi phí. Visibility timeout không phụ thuộc long polling, nên lab bỏ qua để nhật ký gọn.
Đo trong vài giây thay vì vài phút
Timeout 2 giây cho phép mỗi ca chạy trong vài giây. Logic không phụ thuộc độ lớn của con số: task 2,5 giây với timeout 2 giây hành xử giống task 6 phút với timeout 5 phút. Lab thu nhỏ thời gian để quan sát được cả chu kỳ trong một lần chạy ngắn.
Chế độ giả lập
Mọi lệnh nằm trong hàm có decorator mock_aws của moto. boto3 không gọi mạng, mọi yêu cầu được moto trả lời trong bộ nhớ. Biến môi trường khóa AWS được đặt giá trị testing để boto3 không đi tìm khóa thật.
Task dài hơn timeout và thông điệp được giao lại trong Amazon SQS visibility timeout crawler
Phần này chạy ca chính: worker làm quá lâu.
Đọc nhật ký theo thời điểm
Mỗi dòng nhật ký bắt đầu bằng số giây từ đầu chương trình. Đọc theo cột thời điểm giúp thấy khoảng cách giữa lần nhận và lần nhận lại, giữa lần gia hạn và lần thử chen. Những khoảng cách này chính là visibility timeout đang hoạt động.
Worker A nhận
Gửi một thông điệp URL p/1. Ở giây 0,9, worker A nhận, số lần nhận là 1. Ngay sau đó, worker B thử nhận: không nhận được gì. Thông điệp đang ẩn.
Worker A quá hạn, worker B nhận
Giao lại khi quá hạn
Worker A giả vờ tải trang mất lâu. Sau 2,5 giây, quá timeout 2 giây, worker B thử lại và nhận được p/1 ở giây 3,4, số lần nhận là 2. Cùng một URL giờ nằm trong tay hai worker.
Đây chính là nguồn gốc của dữ liệu trùng. Worker A không lỗi, chỉ chậm. Hàng đợi không biết A còn sống, chỉ biết thời gian ẩn đã hết.
Worker A xóa bằng receipt handle cũ
Worker A làm xong và gọi delete_message với receipt handle nhận được ở lần nhận đầu. Trên moto, lệnh không báo lỗi, và thông điệp biến mất khỏi hàng đợi: cả số thông điệp hiện và số đang ẩn đều là 0.
Lab không chắc SQS thật hành xử giống vậy. Tài liệu SQS về receipt handle nói mỗi lần nhận cho một handle khác và khuyên dùng handle của lần nhận gần nhất khi xóa. Đây là chỗ nên kiểm trên SQS thật trước khi dựa vào.
Kết quả trên moto cần kiểm lại
Hành vi xóa bằng handle cũ là chỗ lab tin moto ít nhất. Nếu SQS thật không xóa thông điệp khi dùng handle cũ, thông điệp sẽ ở lại với worker B, và B xóa khi xong. Kết quả cuối vẫn là trùng một lần tải, nhưng không có ca thông điệp bị xóa khỏi tay worker đang làm. Với cả hai hành vi, quy tắc ghi kết quả chịu được trùng vẫn đúng.
Worker B làm thừa
Worker B vẫn đang tải p/1, không biết A đã xong và đã xóa. Khi B xong, kết quả của B là bản trùng. Ở giây 5,6, worker C thử nhận: không còn gì. Thông điệp không quay lại nữa vì đã bị xóa.
Trùng là hệ quả, không phải lỗi cấu hình
Ca này cho thấy với timeout ngắn hơn thời gian xử lý, trùng là hệ quả tất yếu. Nhưng kể cả timeout đủ dài, một worker có thể bị treo mạng đúng lúc, vượt hạn, và tạo trùng. Worker phải ghi kết quả theo cách không gây hại khi chạy hai lần, ví dụ upsert theo URL thay vì chèn dòng mới.
Ghi kết quả chịu được trùng
Upsert theo URL kèm thời điểm tải là cách đơn giản nhất. Hai worker cùng tải một URL sẽ ghi hai lần vào cùng dòng, dòng cuối thắng. Nếu kết quả là tệp, đặt tên tệp theo URL băm, ghi đè thay vì tạo tệp mới. Lượng tải thừa vẫn còn, nhưng dữ liệu không trùng.
Dùng số lần nhận để phát hiện
Khi worker nhận thông điệp với ApproximateReceiveCount lớn hơn 1, nó biết thông điệp đã từng được giao. Có thể ghi log, kiểm kho xem URL đã có kết quả gần đây chưa, và bỏ qua nếu đã có. Đây là cách rẻ để giảm làm thừa.
Gia hạn bằng ChangeMessageVisibility và giới hạn thời gian của Amazon SQS visibility timeout crawler
Phần này thử cơ chế gia hạn.
Worker D gia hạn
Gửi p/2. Worker D nhận ở giây 5,6. Mỗi 1,5 giây, D gọi change_message_visibility đặt lại thời gian ẩn 2 giây tính từ lúc gọi. D làm như vậy ba lần.
Worker E không chen được
Gia hạn giữ thông điệp
Sau mỗi lần D gia hạn, worker E thử nhận: không nhận được, cả ba lần. Tổng thời gian D giữ thông điệp là 4,5 giây, hơn gấp đôi timeout 2 giây, mà không ai khác nhận được.
Xóa sau khi xong
Ở giây 10,1, D xóa thông điệp. 2,2 giây sau, E thử lần nữa: không còn gì. p/2 được xử lý đúng một lần dù mất lâu hơn timeout.
Nhịp gia hạn
D gia hạn mỗi 1,5 giây với timeout 2 giây, tức gia hạn trước khi hết hạn 0,5 giây. Nhịp quá sát hạn thì một lần chậm mạng là quá hạn. Ngoài thực tế, với timeout 5 phút, gia hạn mỗi 2 tới 3 phút là khoảng an toàn.
Worker chết khi đang gia hạn
Nếu worker chết, tác vụ gia hạn chết theo. Thông điệp hết hạn sau lần gia hạn cuối và hiện lại cho worker khác. Đây là hành vi mong muốn: gia hạn chỉ giữ thông điệp khi worker còn sống. Không cần cơ chế dọn dẹp riêng như với hàng đợi tự dựng trên cơ sở dữ liệu.
Gia hạn chạy song song với tải
Worker cần một luồng hoặc tác vụ riêng gọi gia hạn trong lúc luồng chính đang tải. Nếu tải và gia hạn nằm cùng một luồng tuần tự, một lần tải treo sẽ chặn luôn việc gia hạn. Lab gọi gia hạn tuần tự cho đơn giản vì không có tải thật.
Giới hạn 12 giờ
Theo tài liệu, tổng thời gian ẩn không vượt 12 giờ tính từ lần nhận. Lab đặt thử 43.201 giây cho một thông điệp, moto từ chối với InvalidParameterValue. Task tải trang không nên gần giới hạn này. Nếu một URL cần nhiều giờ, đó là dấu hiệu task cần chia nhỏ.
Tắt worker đúng cách
Khi cần dừng worker để cập nhật, worker nên ngừng nhận thông điệp mới, làm xong thông điệp đang có, hoặc đặt visibility 0 cho thông điệp chưa kịp làm. Tắt đột ngột cũng không mất URL, nhưng URL đang làm phải chờ hết visibility timeout mới được giao lại.
Trả thông điệp về sớm
Gửi p/3, worker G nhận rồi đặt visibility bằng 0. Worker H nhận ngay lập tức, số lần nhận là 2. Đặt visibility 0 là cách trả task về hàng đợi khi worker biết mình không làm được, ví dụ đang tắt máy, thay vì để nó chờ hết hạn.
Lỗi liên tục, hàng đợi lỗi và maxReceiveCount trong Amazon SQS visibility timeout crawler
Phần này cho một URL luôn làm worker thất bại.
Worker F không bao giờ xóa
Gửi p/loi. Worker F nhận, không xóa, chờ hết hạn, nhận lại. Lần 1 ở giây 12,3 với số lần nhận 1. Lần 2 ở giây 14,5 với số lần nhận 2. Lần 3 ở giây 16,7 với số lần nhận 3.
Lần thứ tư không còn
Lần nhận thứ tư ở giây 18,9: không nhận được. Thông điệp đã bị nhận 3 lần, bằng maxReceiveCount, và lần quá hạn tiếp theo chuyển nó sang hàng đợi lỗi.
Cảnh báo khi hàng đợi lỗi có thông điệp
Hàng đợi lỗi thường trống. Khi có thông điệp, đó là tín hiệu cần người xem. Đặt cảnh báo theo số thông điệp trong hàng đợi lỗi lớn hơn 0 là cách đơn giản để không bỏ sót URL hỏng. Lab chỉ đọc hàng đợi lỗi bằng tay.
Kiểm hàng đợi lỗi
Nhận từ crawl-dlq ở giây 21,1: có đúng URL p/loi. URL không biến mất, chỉ chuyển chỗ. Người vận hành có thể xem các URL trong hàng đợi lỗi, tìm nguyên nhân, rồi đưa lại hàng đợi chính khi đã sửa.
Ghi lý do lỗi
Hàng đợi lỗi chỉ giữ thông điệp gốc, không giữ lý do worker thất bại. Worker nên ghi log lỗi kèm URL và số lần nhận mỗi khi thất bại. Khi xem hàng đợi lỗi, người vận hành đối chiếu URL với log để biết nguyên nhân: trang 404, parser lỗi, hay chỉ là quá hạn liên tục.
Đưa lại từ hàng đợi lỗi
Sau khi sửa nguyên nhân, đưa thông điệp từ hàng đợi lỗi về hàng đợi chính. SQS có tính năng chuyển lại thông điệp từ hàng đợi lỗi. Lab không thử. Đưa lại mà chưa sửa nguyên nhân sẽ làm thông điệp quay vòng lần nữa rồi lại vào hàng đợi lỗi.
Chọn maxReceiveCount
maxReceiveCount quá nhỏ làm URL chỉ bị chậm một lần đã vào hàng đợi lỗi. Quá lớn làm URL hỏng xoay vòng nhiều lần, tốn tài nguyên. Với crawler, 3 tới 5 là khoảng hợp lý. Nhớ rằng mỗi lần quá hạn do worker chậm cũng tính một lần nhận, không chỉ lỗi thật.
Số lần nhận khi trả về sớm
Ca trả về bằng visibility 0 làm số lần nhận tăng lên 2. Mỗi lần trả về sớm cũng tính vào maxReceiveCount. Worker hay trả về sớm vì lý do vận hành có thể vô tình đẩy URL sang hàng đợi lỗi. Nên đặt maxReceiveCount có dư cho những lần trả về như vậy.
Gia hạn và maxReceiveCount
Worker gia hạn đúng cách không làm tăng số lần nhận, vì thông điệp không hiện lại. Chỉ những lần thông điệp hết hạn và được giao lại mới tăng. Vì vậy, gia hạn không chỉ chống trùng mà còn chống việc URL chậm bị đẩy nhầm sang hàng đợi lỗi.
Bảng các ca
Ca |
Cấu hình |
Kết quả |
Lần nhận |
|---|---|---|---|
Task dài hơn timeout |
timeout 2 s, xử lý 2,5 s |
worker B nhận lại |
2 |
Gia hạn |
gia hạn 2 s mỗi 1,5 s, ba lần |
không ai chen |
1 |
Lỗi liên tục |
maxReceiveCount 3 |
sang hàng đợi lỗi |
3 rồi chuyển |
Trả về sớm |
visibility 0 |
worker khác nhận ngay |
2 |
Vượt giới hạn |
visibility 43.201 s |
InvalidParameterValue |
không áp dụng |
Đầu ra nghiệm thu: visibility timeout, gia hạn và chống xử lý trùng của Amazon SQS visibility timeout crawler
Phần cuối gom kết quả thành bộ bàn giao.
Bộ bàn giao
Bộ bàn giao gồm lab.py chạy bốn ca trên moto, nhật ký thời gian ở trên, và bảng các ca. Người nhận chạy lại, phải thấy worker B nhận lại sau khi A quá hạn, gia hạn giữ được thông điệp 4,5 giây, URL lỗi vào hàng đợi lỗi sau 3 lần nhận.
Tiêu chí đạt
Visibility timeout lớn hơn thời gian xử lý thông thường. Worker gia hạn khi xử lý lâu. Worker ghi kết quả chịu được trùng. Thông điệp lỗi liên tục đi vào hàng đợi lỗi. Mọi kết luận được kiểm lại trên SQS thật trước khi dùng.
Chọn timeout bằng số đo
Đo thời gian tải trang thật trong một tuần, lấy phân vị 99. Đặt visibility timeout gấp đôi con số đó, và gia hạn cho những task vượt ngưỡng. Timeout dựa trên số đo hợp lý hơn đoán, và nên xem lại khi thêm nguồn crawl mới có tốc độ khác.
Quy tắc cho worker crawl
Đọc ApproximateReceiveCount mỗi lần nhận. Bắt đầu một tác vụ gia hạn song song ngay khi nhận. Ghi kết quả bằng upsert theo URL. Xóa bằng receipt handle của lần nhận hiện tại. Trả thông điệp về bằng visibility 0 khi dừng. Theo dõi hàng đợi lỗi.
Khi nào cần proxy với Amazon SQS visibility timeout crawler
Worker gọi SQS qua HTTPS tới điểm cuối của AWS. Nếu mạng công ty bắt đi qua proxy, boto3 đọc biến môi trường proxy như các thư viện Python khác. Đó là kết nối tới hàng đợi, khác với kết nối tải trang.
Trang chậm là nguyên nhân phổ biến làm task vượt visibility timeout. Với website được phép thu thập, mạng không ổn định tới máy chủ nguồn làm thời gian tải dao động. Khi cần IP ổn định tại Việt Nam, anh em có thể mua proxy tĩnh Việt Nam tại trang chủ ProxyVN. Proxy không thay gia hạn và không làm hàng đợi giao đúng một lần. Vai trò hợp lệ của proxy được giải thích ở bài Web Scraping proxy là gì.
Tách proxy của tải trang khỏi kết nối SQS
Nếu worker đặt proxy cho việc tải trang bằng biến môi trường chung, boto3 cũng đi qua proxy đó để gọi SQS. Nên cấu hình proxy riêng cho thư viện tải trang, hoặc thêm điểm cuối SQS vào NO_PROXY. Cách viết chuỗi proxy và cấu hình loại trừ có trong bài định dạng proxy.
Chi phí theo số lần gọi
SQS tính phí theo số yêu cầu. Gia hạn thường xuyên, nhận rỗng liên tục không có long polling đều làm tăng số yêu cầu. Với crawler nhỏ, chi phí này không đáng kể. Với hàng triệu URL mỗi ngày, nên tính trước số lần gọi mỗi URL: một lần nhận, vài lần gia hạn, một lần xóa.
Những gì lab chưa thử
Lab chưa chạy trên SQS thật, chưa thử hàng đợi FIFO với khử trùng theo mã, chưa thử nhận theo lô 10 thông điệp, chưa thử long polling. Hành vi xóa bằng receipt handle cũ trên moto có thể khác SQS thật. Thời gian trong lab dùng timeout 2 giây, không đại diện cho tải trang thật.
Checklist Amazon SQS visibility timeout crawler
Checklist
- Visibility timeout lớn hơn thời gian tải thông thường.
- Gia hạn bằng ChangeMessageVisibility trong tác vụ song song.
- Đọc ApproximateReceiveCount để phát hiện giao lại.
- Ghi kết quả bằng upsert, chịu được trùng.
- Xóa bằng receipt handle của lần nhận hiện tại.
- RedrivePolicy với maxReceiveCount 3 tới 5.
- Visibility 0 khi worker dừng giữa chừng.
- Kiểm lại trên SQS thật mọi điều thử trên moto.
Câu hỏi thường gặp về Amazon SQS visibility timeout crawler
Visibility timeout mặc định là bao nhiêu?
Theo tài liệu AWS, 30 giây, tối thiểu 0, tối đa 12 giờ.
Vì sao cùng URL bị tải hai lần?
Vì worker xử lý lâu hơn visibility timeout. Lab thấy worker B nhận lại thông điệp với số lần nhận 2 sau khi A quá hạn.
Làm sao giữ thông điệp lâu hơn timeout?
Gọi ChangeMessageVisibility định kỳ. Lab gia hạn ba lần, giữ được 4,5 giây với timeout 2 giây.
Bao giờ thông điệp vào hàng đợi lỗi?
Khi bị nhận quá maxReceiveCount mà không bị xóa. Lab đặt 3, lần quá hạn tiếp theo thông điệp chuyển sang hàng đợi lỗi.
SQS có giao đúng một lần không?
Hàng đợi chuẩn giao ít nhất một lần. Worker phải chịu được trùng.
Worker cần proxy để gọi SQS không?
Chỉ khi mạng công ty bắt buộc. Proxy tải trang nên tách khỏi kết nối SQS.
Amazon SQS visibility timeout crawler và những điều cần nhớ
Amazon SQS visibility timeout crawler quyết định task tải trang có bị giao cho worker khác giữa chừng hay không. Lab trên moto cho thấy task dài hơn timeout bị nhận lại với số lần nhận tăng, gia hạn định kỳ giữ được thông điệp, và URL lỗi liên tục vào hàng đợi lỗi sau đúng ba lần. Không cấu hình nào biến hàng đợi thành đúng một lần, nên worker phải ghi kết quả chịu được trùng. Cần IP tĩnh ổn định cho bước tải trang của Amazon SQS visibility timeout crawler, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.
